Kent Beck – äärmuslik programmeerimine. Testipõhine arendus

Žanr: ,

Seeria:
Vanusepiirangud: +
Keel:
Algkeel:
Tõlkija(d):
Väljaandja:
Väljaandmislinn: Peterburi
Ilmumisaasta:
ISBN: 978-5-496-02570-6 Suurus: 382 KB

Autoriõiguse omanikud!

Esitatud teose fragment postitatakse kokkuleppel legaalse sisu turustaja Liters LLC-ga (mitte rohkem kui 20% originaaltekstist). Kui arvate, et materjali postitamine rikub kellegi teise õigusi, siis.

Lugejad!

Makssite, kuid ei tea, mida edasi teha?

Tähelepanu! Laadite alla seaduse ja autoriõiguse omaniku poolt lubatud väljavõtte (mitte rohkem kui 20% tekstist).
Pärast ülevaatamist palutakse teil minna autoriõiguste omaniku veebisaidile ja osta täisversioon töötab.

Raamatu kirjeldus

Kuulsa bestselleri tagasitulek. Elegantne, paindlik ja arusaadav kood, mida on lihtne muuta, mis töötab korrektselt ja mis ei valmista selle loojatele ebameeldivaid üllatusi. Kas see on tõesti võimalik? Eesmärgi saavutamiseks proovige programmi enne selle kirjutamist testida. Just see paradoksaalne idee on TDD (Test-Driven-Development) metoodika aluseks. Jama? Ärge kiirustage ennatlikke järeldusi tegema. Arvestades TDD kasutamist reaalse programmikoodi väljatöötamise näitel, demonstreerib autor selle tehnika lihtsust ja võimsust. Raamat sisaldab kahte tarkvaraprojekti, mis viidi täielikult ellu TDD abil. Näidetele järgneb ulatuslik TDD-stiilis tehnikate, mustrite ja TDD-ga seotud refaktoringute kataloog. Raamat on kasulik igale programmeerijale, kes soovib tõsta oma tootlikkust ja nautida programmeerimist.

Viimane mulje raamatust

SharerSharpened:
16-12-2018, 02:17

Enne selle raamatu lugemist proovisin lugeda loetud artiklite põhjal teste, kuid alles selle raamatuga hakkasin sellega hästi hakkama saama.

Lugesin seda kaks korda. Esimest korda just lugesin.

Ei saanud midagi aru. Teisel korral kirjutasin koodi raamatut lugedes ja siis jõudis lõpuks kohale, mis on mis ja mis kõige tähtsam, tundsin sammu suurust, mille võrra saan koodi muuta ilma selle üle kontrolli kaotamata. Mul oli hea meel teise peatüki üle, kus koos autoriga kirjutasin Pythonis oma ühikutestisüsteemi, tekkis tunne, et teete oma ajule operatsiooni (tegelikult on autor ise täpselt sellise võrdluse teinud) - üks hooletu liigutus ja miski ei tööta, tuleb liikuda väga väikeste sammudega. Kolmanda peatüki lugesin valikuliselt, võib-olla lõpetan kunagi.

Ahenda

⬇ Muud kommentaarid

See on raamat ekstreemsest programmeerimisest. Extreme Programming, sageli lühendatult "XP", on lihtsustatud tootmismetoodika väikeste ja keskmise suurusega arendusmeeskondade jaoks tarkvaratoode ebaselgete või kiiresti muutuvate nõuete ees. See raamat on loodud selleks, et aidata teil otsustada, kas XP on teie olukorra jaoks õige...

XP seeria kohta

Extreme Programming, sageli lühendatult XP, on arendusdistsipliin tarkvara ja äritegevus tarkvaratoodete loomise vallas, mis suunab mõlema poole (programmeerijad ja ärimehed) jõupingutused ühistele, täiesti saavutatavatele eesmärkidele. XP-d kasutavad meeskonnad toodavad kvaliteetset tarkvara väga kiiresti. Selles raamatus kirjeldatud personalijuhtimise distsipliini hõlmavad tehnikad valiti seetõttu, et need põhinevad inimese loovusel ja aktsepteerimisel, et inimesed on muutlikud ja ekslikud olendid.

XP-d esitatakse sageli tehnikate kogumina, kuid XP ise ei ole finišijoon. Sa ei pea HR-i praktiseerimisel ja arendamisel aina paremaks minema, et protsessi lõpus saada see kauaoodatud kuldtäht. Vastupidi, XP on stardijoon. XP esitab küsimuse: "Kui minimaalsed saavad olla meie jõupingutused, et saaksime jätkata kvaliteetse tarkvara tootmist?"

Vastuse algus küsimusele on järgmine: kui tahame töötada välja kvaliteetseid programme ilma segaduse ja segaduseta, peame olema valmis oma meeskonnas täielikult rakendama mitmeid tehnikaid, mida kavatseme täiel määral kasutada. Kui kasutame neid võtteid pooleldi, jäävad probleemid alles ja nende lahendamiseks on vaja üle minna tehnikate täiemahulise kasutamise juurde. Kui piirduda poolte mõõtudega, läheme aja jooksul neis nii segadusse, et ei saa arugi, et põhiline, mis programmeerijate tööga luuakse, tekib tänu programmeerimisele.

Ütlesin "vastuse algus", sest jätk pole tegelikult olemas. XP loonud ja juurutanud inimesed mõtlesid ka selle probleemi lahendamisele. Proovinud XP-d kasutada, ületasid nad läve ja sisenesid tundmatusse. Tagasi tulles rääkisid nad oma loo. Nende mõtted on tee äärde paigutatud sildid: “Siin elavad draakonid”, “Avatakse 15 km pärast hea vaade", "See piirkond on vihma korral ohtlik."

Vabandust, aga mul on aeg programmeerida.

Eessõna

äärmuslik programmeerimine (

äärmuslik programmeerimine

XP) määratleb kodeerimise kui võtme- ja põhitegevuse tarkvaraprojektiga töötamisel. See võib olla vale!

Arvan, et tasub mõtiskleda minu enda kogemuste üle tarkvaraarenduse vallas. Töötan keskkonnas, kus arendatav toode on pidevalt sees töökorras, ja samal ajal tehakse selles pidevalt muudatusi. Järgmise tööversiooni avaldamise tähtaeg on koletult kokku surutud ja samas ripub selle kõige üle tohutu tehniline risk. Sellises keskkonnas on oskus kolleegi korrigeerida kunst, ilma milleta ei saa hakkama. Teabevahetus nii meeskonna sees kui ka mitme meeskonna vahel, mis on sageli geograafiliselt eraldatud, toimub koodi abil. Loeme koodi selleks, et mõista uute või muudetud süsteemitarkvara liideste disaini. Eluring ja käitumine keerulised objektid määratletakse testjuhtumite abil, see tähendab jällegi koodi abil. Probleemiaruannetele on lisatud testjuhtumid, mis näitavad probleemi, kasutades jällegi koodi. Lõpuks oleme pidevalt hõivatud olemasoleva koodi täiustamisega, muutes selle toimivamaks, paindlikumaks ja arusaadavamaks. Ilmselgelt põhineb tarkvaraarendus sellises keskkonnas peaaegu täielikult kodeerimisel, kuid samas suudame projekte edukalt õigeks ajaks valmis teha, seega see lähenemineüsna elujõuline.

Ärge eeldage, et tarkvaraprojekti edukaks elluviimiseks on vaja ainult hoolimatut ja ägedat programmeerimist. Tarkvara arendamine on väga keeruline ning kvaliteetse tarkvara arendamine ja tööde õigeaegne lõpetamine veelgi keerulisem. Et minu kirjeldatud lähenemine toimiks, on see vajalik järjepidev rakendamine olulised lisareeglid ja tehnikad. Siin alustab Kent Beck oma mõtlemapanevat raamatut personali kohta.

Tegin koostööd Kentiga ja kasutasin XP-s kirjeldatud episoode, töötades väikese, kuid tuntud projektiga JUnit

Sissejuhatus

See raamat räägib ekstreemsest programmeerimisest (

äärmuslik programmeerimine

XP). Extreme Programming on lihtsustatud tootmismetoodika väikestele ja keskmise suurusega spetsialistide meeskondadele, kes arendavad tarkvaratoodet ebaselgete või kiiresti muutuvate nõuete tingimustes. See raamat on loodud selleks, et aidata teil kindlaks teha, kas XP on teie olukorra jaoks sobiv.

HR näib paljude jaoks terve mõistuse töökorraldusmeetodite seisukohalt täiesti vastuvõetavate ja põhjendatud kogumina. Miks siis XP meetoditele vastavat programmeerimist äärmuslikuks nimetatakse? Asi on selles, et XP viib paljud levinud ja laialdaselt kasutatavad programmeerimispõhimõtted äärmuslikule tasemele.

Kui koodi ülevaatamine on hea, siis vaatame koodi pidevalt üle (paarprogramming);

Kui testimine on hea, testib iga projektis osaleja programmi koodi pidevalt (ühiktestimine), isegi kliendid ( funktsionaalne testimine);

Kui disain on hea, tuleks disain muuta iga projektis osaleja igapäevatöö lahutamatuks osaks (koodi ümbertöötamine);

Ekstreemne programmeerimine

Pühendatud oma isale ja ka tänu Cindee Andresele, minu naisele ja elukaaslasele, et ta nõudis, et ma teda ignoreeriksin ja kirjutaksin. Aitäh Bethanyle, Lincolnile, Forrestile, et nad mind ei seganud ja kirjutasid.

XP seeria kohta

Extreme Programming, sageli lühendatult XP, on tarkvaraarenduse ja tarkvaraäri distsipliin, mis koondab mõlema poole (programmeerijad ja ärimehed) jõupingutused ühistele saavutatavatele eesmärkidele. XP-d kasutavad meeskonnad toodavad kvaliteetset tarkvara väga kiiresti. Selles raamatus kirjeldatud personalijuhtimise distsipliini hõlmavad tehnikad valiti seetõttu, et need põhinevad inimese loovusel ja aktsepteerimisel, et inimesed on muutlikud ja ekslikud olendid.

Ütlesin "vastuse algus", sest jätk pole tegelikult olemas. XP loonud ja juurutanud inimesed mõtlesid ka selle probleemi lahendamisele. Proovinud XP-d kasutada, ületasid nad läve ja sisenesid tundmatusse. Tagasi tulles rääkisid nad oma loo. Nende mõtted on tee äärde paigutatud sildid: "Siin elavad draakonid", "15 km pärast on hea vaade", "See lõik on vihma korral ohtlik."

Vabandust, aga mul on aeg programmeerida.

Kent Beck, sarja konsultant

Eessõna

äärmuslik programmeerimine ( äärmuslik programmeerimine,XP) määratleb kodeerimise võtme- ja põhitegevusena tarkvaraprojektiga töötamisel. See võib olla vale!

Arvan, et tasub mõtiskleda minu enda kogemuste üle tarkvaraarenduse vallas. Töötan keskkonnas, kus arendatav toode on pidevalt töökorras ning samas tehakse selles pidevalt muudatusi. Järgmise tööversiooni avaldamise tähtaeg on koletult kokku surutud ja samas ripub selle kõige üle tohutu tehniline risk. Sellises keskkonnas on oskus kolleegi korrigeerida kunst, ilma milleta ei saa hakkama. Teabevahetus nii meeskonna sees kui ka mitme meeskonna vahel, mis on sageli geograafiliselt eraldatud, toimub koodi abil. Loeme koodi selleks, et mõista uute või muudetud süsteemitarkvara liideste disaini. Keeruliste objektide elutsükkel ja käitumine määratakse testjuhtumite abil, see tähendab jällegi koodi abil. Probleemiaruannetele on lisatud testjuhtumid, mis näitavad probleemi, kasutades jällegi koodi. Lõpuks oleme pidevalt hõivatud olemasoleva koodi täiustamisega, muutes selle toimivamaks, paindlikumaks ja arusaadavamaks. Ilmselgelt põhineb sellises keskkonnas tarkvaraarendus peaaegu täielikult kodeerimisel, kuid samas suudame projekte edukalt õigeks ajaks valmis teha, seega on selline lähenemine igati elujõuline.

Ärge eeldage, et tarkvaraprojekti edukaks elluviimiseks on vaja ainult hoolimatut ja ägedat programmeerimist. Tarkvara arendamine on väga keeruline ning kvaliteetse tarkvara arendamine ja tööde õigeaegne lõpetamine veelgi keerulisem. Et minu kirjeldatud lähenemine toimiks, tuleb järjepidevalt rakendada olulisi lisareegleid ja -võtteid. Siin alustab Kent Beck oma mõtlemapanevat raamatut personali kohta.

Kent kuulus Tektronixi juhtide hulka, kes mõistsid ühendatud programmeerimistehnikate tohutut potentsiaali keeruliste insenerirakenduste arendamiseks Smalltalki keskkonnas. Koos Ward Cunninghamiga inspireeris Kent välja töötama mustrite programmeerimise (nimetatakse ka mustrite programmeerimiseks - mustrite programmeerimine, mis mõjutas suuresti minu enda karjääri. XP kirjeldab lähenemist tarkvaraarendusele, mis ühendab endas tehnikaid, mida kasutavad arvukad edukad arendajad, kes on uurinud ohtralt kirjandust programmeerijate töökorralduse kohta ning testinud praktikas paljusid tarkvaratoote arendamise meetodeid ja protseduure. Nagu mustrite programmeerimine, loob XP kõige tõhusamate tehnikate komplekti, näiteks testimise tarkvara moodulid, paari programmeerimine ja koodide taaskasutus. XP-s on need tehnikad kombineeritud nii, et üksteist täiendavad ja sageli kontrollivad. Selle raamatu põhieesmärk on rääkida erinevate tehnikate koosmõjust ja ühiskasutusest. Kõikidel programmeerimistehnikatel on üks eesmärk – luua etteantud funktsionaalsusega tarkvaratoode etteantud tähtajaks. OTI väga edukas Just In Time tarkvaraprotsess ei ole XP-s puhtal kujul kuid nende kahe lähenemisviisi vahel on palju ühist.

Tegin koostööd Kentiga ja kasutasin XP-s kirjeldatud episoode, töötades väikese, kuid tuntud projektiga nimega JUnit. Tema vaated ja lähenemised tarkvaraarendusele panid mind alati mõtlema, kuidas ma isiklikult tarkvaraprojekti kallal töötasin. Kahtlemata esitab XP väljakutse paljudele traditsioonilistele programmeerimistööstuses kasutatavatele lähenemisviisidele. Pärast selle raamatu lugemist saate ise otsustada, kas peate oma töös XP-d kasutama või mitte.

Ekstreemne programmeerimine

XP seeria kohta

Ütlesin "vastuse algus", sest jätk pole tegelikult olemas. XP loonud ja juurutanud inimesed mõtlesid ka selle probleemi lahendamisele. Proovinud XP-d kasutada, ületasid nad läve ja sisenesid tundmatusse. Tagasi tulles rääkisid nad oma loo. Nende mõtted on tee äärde paigutatud sildid: "Siin elavad draakonid", "15 km pärast on hea vaade", "See lõik on vihma korral ohtlik."

Vabandust, aga mul on aeg programmeerida.

Kent Beck, sarja konsultant

Eessõna

äärmuslik programmeerimine ( äärmuslik programmeerimine,XP) määratleb kodeerimise võtme- ja põhitegevusena tarkvaraprojektiga töötamisel. See võib olla vale!

Ärge eeldage, et tarkvaraprojekti edukaks elluviimiseks on vaja ainult hoolimatut ja ägedat programmeerimist. Tarkvara arendamine on väga keeruline ning kvaliteetse tarkvara arendamine ja tööde õigeaegne lõpetamine veelgi keerulisem. Et minu kirjeldatud lähenemine toimiks, tuleb järjepidevalt rakendada olulisi lisareegleid ja -võtteid. Siin alustab Kent Beck oma mõtlemapanevat raamatut personali kohta.

Kent kuulus Tektronixi juhtide hulka, kes mõistsid ühendatud programmeerimistehnikate tohutut potentsiaali keeruliste insenerirakenduste arendamiseks Smalltalki keskkonnas. Koos Ward Cunninghamiga inspireeris Kent välja töötama mustrite programmeerimise (nimetatakse ka mustrite programmeerimiseks - mustrite programmeerimine, mis mõjutas suuresti minu enda karjääri. XP kirjeldab lähenemist tarkvaraarendusele, mis ühendab endas tehnikaid, mida kasutavad arvukad edukad arendajad, kes on uurinud ohtralt kirjandust programmeerijate töökorralduse kohta ning testinud praktikas paljusid tarkvaratoote arendamise meetodeid ja protseduure. Sarnaselt mustri programmeerimisega loob XP parimate tavade komplekti, nagu tarkvaramoodulite testimine, paarisprogrammeerimine ja koodi ümbertöötamine. XP-s on need tehnikad kombineeritud nii, et üksteist täiendavad ja sageli kontrollivad. Selle raamatu põhieesmärk on rääkida erinevate tehnikate koosmõjust ja ühiskasutusest. Kõikidel programmeerimistehnikatel on üks eesmärk – luua etteantud funktsionaalsusega tarkvaratoode etteantud tähtajaks. OTI üliedukas Just In Time tarkvaraprotsess ei ole puhas XP, kuid nende kahe lähenemisviisi vahel on palju sarnasusi.

Tegin koostööd Kentiga ja kasutasin XP episoode väikeses, kuid tuntud projektis nimega JUnit. Tema vaated ja lähenemised tarkvaraarendusele panid mind alati mõtlema, kuidas ma isiklikult tarkvaraprojekti kallal töötasin. Kahtlemata esitab XP väljakutse paljudele traditsioonilistele programmeerimistööstuses kasutatavatele lähenemisviisidele. Pärast selle raamatu lugemist saate ise otsustada, kas peate oma töös XP-d kasutama või mitte.

Erich Gamma

Sissejuhatus

See raamat räägib ekstreemsest programmeerimisest ( äärmuslik programmeerimine, XP). Extreme Programming on lihtsustatud tootmismetoodika väikestele ja keskmise suurusega spetsialistide meeskondadele, kes arendavad tarkvaratoodet ebaselgete või kiiresti muutuvate nõuete tingimustes. See raamat on loodud selleks, et aidata teil kindlaks teha, kas XP on teie olukorra jaoks sobiv.

Kui koodi ülevaatamine on hea, siis vaatame koodi pidevalt üle (paarprogramming);

Kui testimine on hea, testib iga projektis osaleja programmi koodi pidevalt (ühiktestimine), isegi kliendid (funktsionaalne testimine);

Kui disain on hea, tuleks disain muuta iga projektis osaleja igapäevatöö lahutamatuks osaks (koodi ümbertöötamine);

Kui lihtsus on hea, siis peaksime hoidma süsteemi kõige lihtsamas disainis, mis tagab praeguse vajaliku funktsionaalsuse taseme (lihtsaim asi, mis kõige tõenäolisemalt töötab); kui arhitektuur on oluline, töötab iga projektis osaleja pidevalt arhitektuuri määratlemise ja ülevaatamise nimel (metafoor);

Kui integratsiooni testimine on oluline, siis on vaja arendatavat süsteemi mitu korda päevas kokku panna ja testida (jooksev integratsioon);

Kui väikesed iteratsioonid on head, peate tegema iteratsioonid väga-väga väikesteks - sekunditeks, minutiteks, võib-olla tundideks, kuid mitte nädalateks ja kuudeks ja mitte mingil juhul aastateks (planeerimismäng).

Kui ma esimest korda otsustasin XP olemuse enda jaoks sõnastada, kujutasin ette juhtpaneeli nuppude komplekti. Iga käepide vastas teatud tehnikale, mille kohta oma isiklik kogemus Ma teadsin, et see on üsna tõhus. Iga nupp võimaldas teatud määral kasutada konkreetset tehnikat: 1 kuni 10. Proovisin seada kõik nupud maksimaalsesse võimalikku asendisse (10) ja avastasin üllatusega, et kogu tehnikate komplekt, mida ma pidasin, jäi stabiilseks ja etteaimatavaks. ja paindlik.

XP loob kaks lubaduste komplekti:

XP lubab programmeerijatele, et igaüks neist tegeleb tõeliselt oluliste probleemide lahendamisega igal tööpäeval. Igaüks neist ei satu kunagi üksi raskesse olukorda. Igaüks neist saab teha kõik endast oleneva, et arendatav süsteem oleks edukas. Igaüks neist saab teha otsuse just selles valdkonnas, milles ta on pädev, ja kui ta pole mõnes valdkonnas piisavalt pädev, ei osale ta otsustamises.

XP lubab klientidele ja juhtidele, et nad saavad iga projektiga töötamise nädala eest maksimaalset võimalikku tulu. Iga paari nädala tagant saavad nad näha edusamme seatud eesmärkide suunas. Neil avaneb võimalus muuta projekti keskarengu suunda, kartmata täiendavaid erakorralisi kulutusi.

Lühidalt öeldes lubab XP vähendada projektiriske, parandada reageerimisvõimet ärimuutustele, parandada projekti tootlikkust ja muuta tarkvaraarendusprotsess nauditavamaks – kõike seda samal ajal. Ma ei tee nalja, lõpetage naermine. Lihtsalt lugege seda raamatut ja näete ise, kas ma olen hull.

See raamat

See raamat räägib XP tehnikaga seotud asjadest – selle juurtest, filosoofiast, erinevatest lugudest ja müütidest. Raamat on loodud selleks, et aidata teil teha teadlikku otsust selle kohta, kas kasutada XP-d enda projekt. Kui otsustate pärast selle raamatu lugemist XP-d oma projektis mitte kasutada, käsitlen peamist eesmärki samamoodi, nagu oleksite pärast selle raamatu lugemist otsustanud, et XP on see, mida vajate. Raamatu teine eesmärk on aidata neid, kes juba XP-d kasutavad. Pärast raamatu lugemist saavad sellised lugejad seda tehnikat paremini mõista.

See raamat ei anna täpseid juhiseid selle kohta, kuidas Extreme Programming protsessi täpselt läbi viia. Te ei näe selles palju näiteid, algoritme ega programmeerimislugusid. Selle kõige saamiseks võite otsida Internetist, rääkida mõne projektis osalejaga, oodata sellele pühendatud raamatute ilmumist või luua ise sellist materjali.

Minu kirjeldatud XP tarkvaraarenduse distsipliini edasine saatus on inimeste grupi kätes (võib-olla olete teie üks neist), kes pole rahul olemasolevaga. Sel hetkel traditsioonilised meetodid programmeerijate töö korraldamiseks. sa vajad parim viis tarkvaraarendust, soovite arendada oma klientidega produktiivsemaid ja sõbralikumaid suhteid, soovite muuta teie juhitavad programmeerijad õnnelikumaks, lojaalsemaks ja produktiivsemaks. Lühidalt öeldes tahad saada märkimisväärset eelist ja sa ei karda selle eelise saavutamiseks uusi ideid kasutada. Enne riski võtmist tahad aga veenduda, et sa pole vähemalt täielik loll.

XP juhendab sind tegema tööd hoopis teistmoodi, kui oled harjunud. Mõnel juhul on XP soovitused üldtunnustatud normidega täielikult vastuolus. Peal Sel hetkel Usun, et XP-d saavad kasutada vaid need, kellel on mõjuvad põhjused olemasolevat asjade järjekorda muuta. Kui aga sellised põhjused on olemas, võite kohe hakata XP kasutama. Kirjutasin selle raamatu, et saaksite nende põhjuste kohta rohkem teada.

Mis on XP?

Mis on XP? XP on lihtsustatud, tõhus, paindlik, prognoositav, teaduspõhine ja väga nauditav viis tarkvara arendamiseks, mis sisaldab madal tase risk. XP erineb teistest meetoditest järgmistel viisidel.

Äärmiselt lühikesi arendustsükleid kasutades pakub XP kiiret, tõelist ja alati sisse lülitatavat tagasisidet.

XP kasutab järkjärgulist planeerimist, mille tulemuseks on projekti üldine plaan üsna kiiresti, kuid on arusaadav, et see plaan areneb kogu projekti eluea jooksul.

XP kasutab selle või teise funktsionaalsuse juurutamiseks paindlikku ajakava, mis parandab reageerimist äri muutuvale olemusele ja sellega seoses muutuvatele klientide nõudmistele.

XP põhineb automatiseeritud testidel, mille on välja töötanud nii programmeerijad kui ka kliendid. Tänu nendele testidele on võimalik jälgida arendusprotsessi, tagada süsteemi korrektne areng ning koheselt tuvastada süsteemis esinevad defektid.

XP põhineb suulisel suhtlusel, testidel ja lähtekoodil. Neid kolme tööriista kasutatakse teabe vahetamiseks süsteemi struktuuri ja käitumise kohta.

XP põhineb areneval disainiprotsessil, mis kestab seni, kuni süsteem ise eksisteerib.

XP põhineb tihedal suhtlusel kõige levinumate oskuste ja võimalustega programmeerijate vahel.

XP põhineb tehnikatel, mis rahuldavad nii üksikute programmeerijate lühiajalisi instinkte kui ka kogu projekti pikaajalisi huve.

XP on tarkvaraarenduse distsipliin. See on distsipliin, sest XP-s on teatud asju, mida peate tegema, kui kavatsete XP-d kasutada. Te ei peaks valima, kas kirjutada teste või mitte, sest kui te seda ei tee, pole programmeerimine äärmuslik: arutelu lõpp.

XP metoodika on loodud töötama projektidega, mille kallal saavad töötada kaks kuni kümme programmeerijat, mida ei piira olemasoleva arvutikeskkonna jäigad piirangud ja milles kõik vajalikud testimistööd on ühe päeva jooksul tehtud.

XP hirmutab või ärritab mõnda inimest, kes selle tehnikaga esimest korda kokku puutub. Ükski XP aluseks olev idee pole aga uus. HR-metoodika on teatud mõttes konservatiivne – kõik selle raames kasutatavad võtted on läbi aastakümnete (rakendusstrateegia osas) ja isegi sajandite (juhtimisstrateegia osas) praktikas testitud.

XP uuendused hõlmavad järgmisi funktsioone:

Kõik need ammu tuntud tehnikad on kogutud ühe katuse alla;

Intensiivsus, millega neid võtteid igapäevatöösse juurutatakse, on viidud äärmuseni;

Kasutatavad tehnikad toetavad üksteist võimalikult suurel määral.

Adekvaatsus

Tema töödes Metsarahvas ja mägi (People Mountain Peoples) Antropoloog Colin Turnbull kirjeldab kahte väga erinevat ühiskonda. Mägedes napib eluks vajalikke ressursse ja inimesed on kogu aeg näljahäda äärel. Sellistes tingimustes tekkinud kultuur tundub hirmutav. Emad hülgavad oma lapsed, et ise ellu jääda. Toit võib põhjustada surma. Julmus, loomalikkus ja reetmine on tavalised ja igapäevased.

Erinevalt mägedest on mets ressursside poolest rikas. Et end terveks päevaks toiduga varustada, peab inimene kulutama vaid umbes pool tundi. Metsakultuur on mägikultuuri peegeldus. Täiskasvanud osalevad ühiste laste kasvatamises ja kasvatamises, kes kasvavad armastuses ja hoolimises, kuni saavad piisavalt pädevaks enda eest hoolitsemiseks. Kui üks inimene tapab kogemata teise (tahtlik mõrv on neile inimestele teadmata), heidetakse ta ühiskonnast välja. Kuid sel juhul peab pagulane lihtsalt metsa taanduma ja seal mitu kuud veetma ning isegi siis toovad mõned hõimu liikmed talle süüa ja kingitusi.

XP on katse vastata küsimusele: kuidas te isiklikult programmeeriksite, kui teil oleks piisavalt aega? Tegelikult pole teil lisaaega, sest lõppude lõpuks on programmeerimine äri. Igas äris võidab see, kes teeb töö kiiremini. Siiski, kui teil oleks aega, pööraksite tõenäoliselt tähelepanu testide arendamisele; tõenäoliselt kujundaksite süsteemi arhitektuuri uuesti ümber, kui jõuaksite järeldusele, et see on vajalik; tõenäoliselt suhtleksite rohkem oma kaasprogrammeerijatega ja ka kliendiga.

Selline piisavuse tunne tundub inimlikum, erinevalt olukordadest, kus programmeerijad püüavad jõudumööda jääda etteantud ajaraami sisse, jäävad graafikust maha ega suuda teha suurt hulka ülitähtsaid töid vaid selleks, et projekt õigeks ajaks ellu viia. Kiirustamine takistab programmeerijatel oma annet täielikult väljendada ja oma tööd nautida. XP-d õppima asudes peaksite aga mõistma, et piisav tunne on samuti hea äri. Piisavustundest saab efektiivsuse allikas, nii nagu puudustunne tekitab töös tõrkeid, mis toob kaasa defekte ja madalama kvaliteedi ning lõppkokkuvõttes madalama tootlikkuse.

Raamatu ülevaade

Raamat on kirjutatud nii, nagu oleksime sina ja mina koos uut tarkvaraarenduse distsipliini looma. Alustuseks uurime oma põhiteadmisi tarkvaraarendusest. Pärast seda loome tegelikult uue distsipliini. Seejärel uurime oma loodu mõju – kuidas seda praktikas rakendada ja kasutada, millal seda kasutada ei tohiks ja milliseid võimalusi see ettevõtetele pakub.

Raamat on jagatud kolme ossa.

Probleem: peatükkides alates Risk: peamine probleem ja lõpp Tagasi põhitõdede juurde, määratletakse probleem, mida äärmuslik programmeerimine püüab lahendada, ning kehtestatakse kriteeriumid, mille järgi saab hinnata lahenduse kvaliteeti. Selles osas saate üldise ettekujutuse Extreme Programming metoodikast.

Lahendus: peatükkides alates Lühiülevaade ja lõpp Testimisstrateegia, teisendatakse raamatu esimeses osas esitatud abstraktsed ideed distsipliinispetsiifiliste tehnikate kogumiks. See peatükk ei sisalda teavet selle kohta, kuidas täpselt kirjeldatud tehnikaid praktikas rakendada. Selle asemel on tegemist iga tehnika üldise vormiga. Iga tehnikat käsitledes seostan seda raamatu esimeses osas käsitletud küsimuste ja põhimõtetega.

XP juurutamine: peatükkides alates XP juurutamine ja lõpp XP tööl, räägitakse paljudest XP juurutamisega seotud küsimustest - kuidas XP-d peaks rakendama, mida peaks ootama erinevatelt XP projektiga seotud inimestelt, milline ettekujutus XP-st on ärimaailma inimestel.

Tänuavaldused

Ma räägin lugejatega esimeses isikus, mitte sellepärast, et raamat esitab minu enda ideid, vaid sellepärast, et ma räägin teile oma arusaamadest nendest ideedest. Enamik XP-s kasutatavaid tehnikaid on sama vanad kui kogu programmeerimine.

Ward Cunningham on selle raamatu materjalide peamine allikas. Igatahes olen viimased viisteist aastat lihtsalt püüdnud teistele inimestele selgitada, millega Ward on praktiliselt pikka aega tegelenud. Täname ka Ron Jeffriesit, et ta ka seda proovis ja selle palju paremaks muutis. Aitäh Martin Fowlerile, et ta selgitas kõike seda lihtsas, õrnas keeles ja panka rikkumata. Aitäh Erich Gammale pikkade vestluste eest, mis on ühendatud Lymmis luikede üle mõtisklemisega, ja ka selle eest, et ei lubanud mul enda juurest halbade mõtetega peas lahkuda. Ja loomulikult poleks seda minu elus juhtunud, kui mul poleks olnud eeskuju nagu mu isa Doug Beck, kes lihvis oma programmeerimisoskusi aastaid.

Täname Chrysleri C3 meeskonda, kes juhendasid mind uurimistöös. Ja eriline tänu meie mänedžeridele Sue Ungerile ja Ron Savage’ile, et nad julgesid meid proovida.

Täname Daedalos Consultingi abi eest selle raamatu kirjutamisel.

Vaatamismaterjalide tšempioni auhind läheb Paul Chisholmile rohkete, napisõnaliste, täpsete ja sageli lausa tüütute kommentaaride eest. Ilma tema abita see raamat poleks pooltki nii populaarne.

Mulle meeldis väga suhelda kõigi läbiviijatega eelvaade mida ma kirjutasin.

Nende töö on mulle suureks abiks olnud. Ma ei leia tänusõnu selle eest, et neil jätkus kannatust kogu see proosa lõpuni lugeda, sest paljud neist on kirjutatud võõrkeeles.

Tänud (loetlemata konkreetses järjekorras, milles ma neilt kommentaare sain) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Josha Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dierk Koenig, Miroslav Miroslav Novak, Rodney Rayan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen, Thomas Ernst, Guido Guido Haechler, Dieter Holz, Martin Knecht, Dierk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno (Alexio Moreno), Rolf Pfenninger ja Matthias Ressel.

Väljaandjalt

Saatke oma kommentaarid, ettepanekud, küsimused aadressile: Meil [e-postiga kaitstud](Peetri kirjastus, arvutiväljaanne).

Meil oleks hea meel kuulda teie arvamust!

Kõik raamatus toodud lähtetekstid on leitavad aadressil http://www.piter.com/download.

Kirjastuse veebisaidilt http://www.piter.com leiate üksikasjalikku teavet meie raamatute kohta.

Probleem

See osa raamatust seab aluse äärmusliku programmeerimise kujunemisele. See kirjeldab probleemi erinevaid aspekte, mis tuleb lahendada, moodustades uue tarkvaratehnika distsipliini.

Selles osas käsitletakse põhieeldusi, mida peame tarkvaraarenduse praktikate valikul arvestama – autojuhtimise metafoor, neli tähendust, nendest tähendustest moodustatud põhimõtted ja tegevused, mida on vaja uue tarkvaraarenduse distsipliini raames struktureerida.

Risk: peamine probleem

Olemasolevad tarkvaraarenduse distsipliinid ei tööta ega anna soovitud majanduslikku mõju. Sellel probleemil on tohutu majanduslik ja humanitaarne tähtsus. Vajame uut viisi tarkvara arendamiseks.

Tarkvaraarenduse peamine probleem on risk.

Siin on mõned näited riskidest.

Graafiku nihe– saabub tööde tähtaeg ja olete sunnitud klienti teavitama, et arendatav süsteem ei ole valmis veel poole aasta pärast.

Projekti sulgemine– pärast mitmeid graafiku nihkeid ja tarnekuupäeva edasilükkamist suletakse projekt, ilma et seda oleks viidud isegi töötingimustes testimise staadiumisse.

Süsteem kaotab oma kasulikkuse– väljatöötatud tarkvara installeerub edukalt reaalses tootmistöökeskkonnas, kuid peale paariaastast kasutamist suureneb selles muudatuste tegemise hind ja/või defektide arv nii palju, et süsteemi uue vastu vahetamine muutub odavamaks. arengut.

– tarkvarasüsteem on paigaldatud reaalsesse tootmistöökeskkonda, kuid defektide ja puuduste hulk on nii suur, et süsteemi ei kasutata.

– Tarkvarasüsteem on installitud reaalsesse tootmistöökeskkonda, kuid selgub, et see ei lahenda tegelikult seda äriprobleemi, mille lahendamiseks see algselt oli mõeldud.

Ettevõtluse olemuse muutumine– Tarkvarasüsteemi paigaldatakse reaalsesse tootmistöökeskkonda, kuid viimase poole aasta jooksul on probleem, mille lahendamiseks süsteem loodud on, muutunud ebaoluliseks ja äri seisab silmitsi uue, veelgi tõsisema probleemiga.

Võimaluste puudumine– Tarkvarasüsteemil on palju potentsiaalselt huvitavaid funktsioone, millest igaühe programmeerimine oli meeldiv, kuid selgub, et ükski neist funktsioonidest ei too kliendile erilist kasu.

Personali voolavus– kahe tööaasta jooksul kõik head programmeerijad, kes projekti kallal töötas, vihkas arendust üksteise järel tarkvarasüsteem ja läks teisele tööle.

Selle raamatu lehekülgedelt saate lugeda ekstreemse programmeerimise kohta ( äärmuslik programmeerimine, XP) on tarkvaraarenduse distsipliin, mis on keskendunud riskide vähendamisele arendusprotsessi kõigil tasanditel. XP aitab oluliselt tõsta tootlikkust ja parandada arendatud programmide kvaliteeti, lisaks on see väga meelelahutuslik praktika, mis pakub kõigile osalejatele palju rõõmu.

Kuidas XP vähendab varem loetletud riske?

Graafiku nihe– XP soovitab kasutada väga lühike aeg iga järgneva versiooni väljaandmine. Eeldatakse, et süsteemi iga järjestikune kasutusvalmis versioon töötatakse välja maksimaalselt mitme kuu jooksul. Seega on iga versiooni sees töömaht piiratud, mis tähendab, et nihke korral on see vähem oluline. Iga väljalase sisaldab mitut iteratsiooni kliendi nõutud funktsioonidest, iga iteratsiooni arendamiseks kulub üks kuni neli nädalat. See tagab kliendile paindliku ja vastutuleliku tagasiside, tänu millele saab ta aimu töö hetkeseisust. Igas iteratsioonis viiakse XP-ga kooskõlas olev planeerimine läbi mitme ülesande osas, mis tuleb järgmise iteratsiooni saamiseks lahendada. Igale ülesandele eraldatakse üks kuni kolm päeva. Selle tulemusel saab meeskond probleeme tuvastada ja parandada isegi itereerimise ajal. Lõpuks tähendab XP, et võimalused koos kõrgeim prioriteet rakendatakse esmalt. Seega on kõik funktsioonid, mida ei saa tarkvaratoote järgmises versioonis rakendada, madalama prioriteediga.

Projekti sulgemine– XP raames peab klient määrama väikseima vastuvõetava võimaluste komplekti, mis peaks olema programmi minimaalsel toimival versioonil, mis on äriprobleemide lahendamise seisukohalt mõttekas. Seega peavad programmeerijad tegema minimaalselt jõupingutusi, et klient saaks aru, kas tal on seda projekti vaja või mitte.

Süsteem kaotab oma kasulikkuse– XP sees luuakse ja hooldatakse tohutul hulgal teste, mis käivitatakse ja taaskäivitatakse peale igasuguste muudatuste tegemist süsteemis (mitu korda päevas), tänu sellele on võimalik hoolikalt jälgida arendatud programmi kvaliteeti. XP hoiab süsteemi alati suurepärases seisukorras. Defektidel lihtsalt ei lasta koguneda.

Defektide ja puuduste arv– XP sees testivad arendatavat süsteemi nii programmeerijad, kes loovad teste iga üksiku arendatava funktsiooni jaoks, kui ka kliendid, kes loovad testid süsteemi iga üksiku juurutatud funktsiooni jaoks.

Vastuolu lahendatava probleemiga– XP-s on klient projektiga tegeleva meeskonna lahutamatu osa. Projekti spetsifikatsiooni uuendatakse pidevalt kogu projekti kestuse jooksul, tänu millele kajastuvad kõik täpsustused ja avastused, mida klient arendusmeeskonnale edastab, kohe ka arendatud programmis.

Äärmuslik programmeerimine: testipõhine arendus

Pühendatud Cindyle: minu hinge tiivad

Kirjastamisõigused saadi Addison-Wesley Longmaniga sõlmitud lepingu alusel. Kõik õigused kaitstud. Ühtegi selle raamatu osa ei tohi mingil kujul reprodutseerida ilma autoriõiguste valdajate kirjaliku loata.

Selles raamatus sisalduv teave on saadud allikatest, mida kirjastaja peab usaldusväärseks. Arvestades aga võimalikke inimlikke või tehnilisi vigu, ei saa kirjastaja garanteerida esitatud teabe absoluutset täpsust ja täielikkust ega vastuta raamatu kasutamisega seotud võimalike vigade eest.

ISBN 978-0321146533 inglise keel

ISBN 978-5-496-02570-6

Eessõna

Puhas kood, mis töötab"Puhas kood, mis töötab", see lühike, kuid sisukas fraas, mille on välja mõelnud Ron Jeffries, koondab testipõhise arenduse (TDD) kogu tähenduse. Puhas toimiv kood on eesmärk, mille nimel tasub pingutada

See on prognoositav viis programmide arendamiseks. Teate, millal võib töö lõpetatuks lugeda, ilma et peaksite muretsema pika vigade jada pärast;

Annab teile võimaluse õppida õppetunnid, mida kood õpetab. Kui kasutate esimest pähe tulnud ideed, pole teil võimalust teist, paremat ideed ellu viia;

Parandab teie programmide kasutajate elu;

Võimaldab teie kolleegidel teie peale loota ja teil nende peale;

Sellist koodi on mõnusam kirjutada.

Aga kuidas saada puhas kood, mis töötab? Paljud jõud takistavad meil saada puhast koodi ja mõnikord ei saa me isegi koodi, mis lihtsalt töötab. Paljudest probleemidest vabanemiseks töötame välja automatiseeritud testimise põhjal koodi. Seda programmeerimisstiili nimetatakse testipõhiseks arendamiseks. Selle tehnika järgi

Uus kood kirjutatakse alles pärast automaattesti kirjutamist, mis ebaõnnestub;

Igasugune dubleerimine on välistatud.

Kaks lihtsad reeglid, pole see? Kuid need loovad keeruka individuaalse ja rühmakäitumise, millel on palju tehnilisi tagajärgi:

Disainiprotsessi käigus käitame pidevalt koodi ja saame aimu selle toimimisest, see aitab meil teha õigeid otsuseid;

Me kirjutame oma teste ise, sest me ei jõua ära oodata, millal keegi teine meie eest teste kirjutab;

Meie arenduskeskkond peab väikestele koodimuudatustele kiiresti reageerima;

Programmi ülesehitus peaks põhinema paljude iseseisvate, lõdvalt seotud komponentide kasutamisel, et koodi oleks lihtsam testida.

Mainitud kaks TDD reeglit määravad programmeerimisetappide järjekorra.

1. Punane – kirjutage väike test, mis ei tööta ja võib-olla isegi ei kompileeri.

2. Roheline – käivitage test nii kiiresti kui võimalik, muretsemata kujunduse õigsuse ja koodi puhtuse pärast. Kirjutage täpselt nii palju koodi, et test toimiks.

3. Refaktoreerimine – kõrvaldage kirjaliku koodi dubleerimine.

Punane – roheline – refaktoreerimine on TDD mantra.

Kui eeldada, et selline programmeerimisstiil on võimalik, siis võib eeldada, et tänu selle kasutamisele jääb koodile oluliselt vähem defekte, lisaks on töö eesmärk selge kõigile, kes selles osalevad. Kui jah, siis ainult testide läbimiseks vajaliku koodi väljatöötamisel on ka sotsiaalsed tagajärjed:

Kui defektide tihedus on piisavalt madal, saab kvaliteeditagamise (QA) meeskond liikuda vigadele reageerimise asemel nende vältimisele;

Kui ebameeldivaid üllatusi on vähem, saavad projektijuhid tööjõukulusid täpsemalt hinnata ja kliente arendusprotsessi kaasata;

Kui tehniliste arutelude teemad on selgelt määratletud, saavad programmeerijad üksteisega pidevalt suhelda, mitte kord päevas või nädalas;

Taas, piisavalt väikese defektide tihedusega, suudame iga päev toota integreeritud töötoodet, millele lisandub uus funktsionaalsus, mis võimaldab sõlmida klientidega täiesti uut tüüpi ärisuhte.

Nii et idee on lihtne, kuid mis on meie huvi? Miks peaks programmeerija võtma endale täiendava vastutuse automatiseeritud testide kirjutamise eest? Miks peaks programmeerija väikeste sammudega edasi liikuma, kui tema aju on võimeline mõtlema läbi palju keerukama disainistruktuuri? Vaprus.

Vaprus

TDD on viis hirmu juhtimiseks programmeerimisprotsessis. Ma ei pea silmas hirmu toolilt kukkumise ees ega hirmu olla ülemuse ees. Pean silmas hirmu seista silmitsi probleemiga, mis on "nii raske, et mul pole veel aimugi, kuidas seda lahendada". Valu on see, kui loodus ütleb meile: "Stopp!" ja hirm on siis, kui loodus ütleb meile: "Olge ettevaatlik!" Ettevaatlikkus pole sugugi halb, kuid lisaks oma eelistele on hirmul meile mõned negatiivsed mõjud:

Hirm sunnib meid ette ja hoolikalt mõtlema, milleni see või teine tegevus võib viia;

Hirm paneb meid vähem suhtlema;

Hirm paneb meid kartma oma töö arvustusi;

Hirm muudab meid ärrituvaks.

Ükski neist pole programmeerimisprotsessi jaoks kasulik, eriti kui töötate kallal väljakutseid pakkuv ülesanne. Niisiis seisame silmitsi küsimusega, kuidas keerulisest olukorrast välja tulla ja

Ärge püüdke tulevikku ennustada, vaid alustage kohe probleemi praktilist uurimist;

Ära isoleeri end muust maailmast, vaid tõsta suhtlustaset;

Ärge vältige vastuseid, vaid, vastupidi, looge usaldusväärne tagasiside ja jälgige selle abiga hoolikalt oma tegevuse tulemusi;

(ärritustega peate ise toime tulema).

Võrdleme programmeerimist ämbri tõstmisega kaevust. Kopp täidetakse veega, keerate hooba, keerates ketti ümber krae ja tõstes kopa üles. Kui kopp on väike, sobib tavaline, vabalt pöörlev värav. Aga kui kopp on suur ja raske, väsid enne selle tõstmist ära. Kangi pöörete vahel puhata on vaja põrkmehhanismi, mis võimaldab kangi lukustada. Mida raskem on kopp, seda kiiremini peaksid põrkmehhanismi hambad järgima.

TDD testid on nagu põrkmehhanismi hambad. Pärast testi toimimist teame, et test töötab nüüd, nüüd ja igavesti. Oleme lõpule sammu võrra lähemal kui enne testi avaldamist. Pärast seda paneme tööle teise testi, seejärel kolmanda, neljanda jne. Mida keerulisem on programmeerija ees seisev probleem, seda vähem funktsionaalsust peaks hõlmama iga testi.

Raamatulugejad Extreme Programming Selgitage Võib-olla olete märganud erinevust ekstreemse programmeerimise (XP) ja testipõhise arenduse (TDD) vahel. Erinevalt XP-st ei ole TDD metoodika absoluutne. XP ütleb: "Edasi liikumiseks peate valdama seda ja seda." TDD on vähem spetsiifiline tehnika. TDD eeldab, et otsuste tegemise ja tulemuste vahel on intervall, ning pakub tööriistu selle intervalli pikkuse haldamiseks. "Mis siis, kui ma veedaksin nädala paberil algoritmi kujundamiseks ja seejärel koodi kirjutamiseks, kasutades esmalt testi? Kas see on TDD-ga ühilduv? Muidugi saab. Teate otsuse tegemise ja tulemuste hindamise vahelise intervalli suurust ning kontrollite seda intervalli teadlikult.

Enamik inimesi, kes on õppinud TDD-d, ütlevad, et nende programmeerimistavad on paremaks muutunud. Nakatunud testidega(test nakatunud) on määratlus, mille Erich Gamma selle muutuse kirjeldamiseks lõi. Kui olete TDD omandanud, avastate end kirjutamas oluliselt rohkem teste kui varem ja liikudes edasi väikeste sammudega, mis varem tundusid teile mõttetuna. Teisest küljest otsustavad mõned programmeerijad, olles TDD-ga tuttavaks saanud, naasta vanade tavade juurde, reserveerides TDD erijuhtudeks, kui tavaprogrammeerimine ei vii soovitud eduni.

Kindlasti on probleeme, mida ei saa (vähemalt hetkel) ainult testide abil lahendada. Eelkõige ei võimalda TDD mehaaniliselt demonstreerida väljatöötatud koodi adekvaatsust andmeturbe ja paralleelsete toimingute usaldusväärsuse seisukohalt. Loomulikult põhineb turvalisus koodil, mis peab olema defektideta, kuid see põhineb ka inimese osalemisel andmekaitseprotseduurides. Peent samaaegsusprobleeme ei saa lihtsalt mõnda koodi käivitades kindlalt reprodutseerida.