Kent Beck - Extreme programmēšana. Attīstība, izmantojot testēšanu

Žanrs:

Sērija:
Vecuma ierobežojumi: +
Valoda:
Oriģinālā valoda:
Tulkotājs (-i):
Izdevējs:
Publicēšanas pilsēta: Sanktpēterburga
Izdevējdarbības gads:
ISBN: 978-5-496-02570-6 Izmērs: 382 KB

Tiesības turētāji!

Prezentētais darba fragments ir ievietots koordinācijā ar izplatītāju juridiskā satura LLC "litriem" (ne vairāk kā 20% no avota teksta). Ja jūs domājat, ka materiāla izvietošana pārkāpj kādas personas tiesības.

Lasītāji!

Maksā, bet nezinu, ko darīt tālāk?

Uzmanību! Jūs lejupielādējat izvilkumu, ko pieļauj likums un pareizais turētājs (ne vairāk kā 20% no teksta).
Pēc lasīšanas jums tiks lūgts doties uz pareizā turētāja vietni un iegādāties pilnu darba versiju.

Grāmatas apraksts

Slavenā vairāk pārdotās atgriešanās. Elegants, elastīgs un skaidrs kods, kas ir viegli modificējams, kas darbojas pareizi un kas nepalielina savus nepatīkamos pārsteigumu veidotājus. Vai tas tiešām ir iespējams? Lai sasniegtu mērķi, mēģiniet pārbaudīt programmu pat pirms tā rakstīšanas. Tā ir tik paradoksāla ideja, kas balstīta uz TDD tehniku \u200b\u200b(testēšanas balstīta attīstība - izstrāde, kas balstīta uz testēšanu). Muļķības? Nelietojiet skriešanās, lai izdarītu agrīnus secinājumus. Ņemot vērā TDD izmantošanu par īstas programmas koda attīstības piemēru, autors parāda šīs tehnikas vienkāršību un spēku. Grāmatā ir divi programmas projekti, pilnībā un pilnībā īstenoti, izmantojot TDD. Piemēru izskatīšanai, plašs TDD stila metožu katalogs, kā arī modeļi un refaktori, kas saistīti ar TDD. Grāmata būs noderīga jebkurai programmētājam, kas vēlas uzlabot jūsu darba veiktspēju un baudīt programmēšanu.

Pēdējais iespaids par grāmatu

Sharersharbened:
16-12-2018, 02:17

Pirms šīs grāmatas lasīšanas es centos rakstīt testus par rakstiem, kurus es lasīju, bet tikai ar viņu sāka labi nokļūt.

Es izlasīju divreiz. Pirmo reizi lasīja tikai.

Neko nesaprata. Otro reizi es rakstīju kodu grāmatas lasīšanas gaitā, un pēc tam beidzot tas nāca pie manis, ko darīt, kas un vissvarīgākais - es jutu savu soli, uz kuru es varu mainīt kodu un tajā pašā laikā es nevaru mainīt kodu un tajā pašā laikā es nebūtu zaudēt to kontroli. Es biju apmierināts ar otro nodaļu, kur kopā ar autoru rakstīja manu moduļu testēšanas sistēmu Python, sajūta bija tā, it kā jūs veicāt darbību uz savām smadzenēm (patiesībā, šis salīdzinājums bija pats autors, un pats autors pats) - viena bezrūpīga kustība pati un nedarbojas, jums ir jāpārvieto ļoti mazi soļi. Es izlasīju trešo nodaļu selektīvi, varbūt kādu dienu es izlasīju.

Pārvērsties

⬇ Citi komentāri

Šī grāmata ir par ārkārtēju programmēšanu. Ekstrēmā programmēšana, ko bieži apzīmē saīsinājums "XP" - tas ir vienkāršota metode, lai organizētu mazo un vidējo attīstītāju komandas programmatūras produkts Apstākļos neskaidras vai strauji mainīgas prasības. Šī grāmata ir izstrādāta, lai palīdzētu jums noteikt, vai XP lietošana ir pamatota jūsu situācijā ...

Par XP sēriju

Ekstrēmā programmēšana (galējā programmēšana), ko bieži apzīmē ar saīsinājumu XP, ir attīstības disciplīna programmatūra un veicot uzņēmējdarbību programmatūras izveides jomā, kas koncentrējas uz abu pušu (programmētāju un uzņēmēju) centieniem uz kopīgiem, pilnībā sasniedzamiem mērķiem. Komandas, kas izmanto XP ražot augstas kvalitātes programmatūru ar ļoti lielu ātrumu. Metodes, kas ir daļa no šīs grāmatas aprakstītās XP disciplīnas tiek izvēlētas, jo tie ir balstīti uz cilvēka radošumu un pieņemot faktu, ka persona ir radījums nestabila un kļūdas.

XP bieži ir pārstāvēta kā paņēmienu kopums, bet pats HP nav finiša līnija. Jums nav jābūt labākam un labāk praktizēt un attīstīt XP, lai šī procesa beigās iegūtu ilgstošu zelta zvaigzni. Gluži pretēji, XP ir starta līnija. XR paaugstina jautājumu: "Cik minimāls var mūsu centieni būt, lai mēs varētu turpināt ražot augstas kvalitātes programmatūru?"

Atbildes uz jautājumu sākums izklausās šādi: ja mēs vēlamies izstrādāt augstas kvalitātes programmas bez satricinājuma un neskaidrības, mums ir jābūt pabeigtai pilnībā un pilnībā īstenot mūsu komandā vairākas metodes, ko mēs gatavojamies pilnībā izmantot. Ja mēs izmantojam šīs metodes uz pusēm, problēmas paliks un izlemt, būs nepieciešams, lai pārietu uz izmantošanu paņēmieniem, lai pilnībā. Ja mēs ierobežojam sevi ar daļēji dimensijām, laika gaitā mēs sajaukt tik daudz, ka mēs nevaram saprast, ka ir galvenais, kas ir izveidots ar darbaspēka darbu, rodas programmēšanai.

Es teicu "atbildes sākums uz", jo turpinājums nav īsti. Cilvēki, kas izveidoja un ieviesa XP arī domāja par šī jautājuma lēmumu. Mēģināja izmantot XP, viņi pārgāja pāri slieksnim un apmeklēja noķeršanas. Atgriežas, viņi stāstīja savu stāstu. Viņās norādītās domas ir norādes, kas atrodas gar ceļu: "Dragons Live šeit," "15 km attālumā labs skats"," Šis gabals ir bīstams lietū. "

Es atvainojos, bet man ir pienācis laiks programmēt.

Priekšvārds

Extreme programmēšana (

extreme programmēšana

XP) definē kodēšanu kā galvenās un pamatdarbības, strādājot ar programmatūras projektu. Ir iespējams, ka tas ir nepareizi!

Es domāju, ka ir vērts atcerēties savu pieredzi programmatūras izstrādē. Es strādāju vidē, kurā izstrādāts produkts ir pastāvīgi darba stāvoklisUn tajā pašā laikā izmaiņas pastāvīgi tiek ieviestas tajā. Nākamās praktiskās versijas izlaišanas termiņi ir acīmredzami saspiesti, un tajā pašā laikā ir milzīgs tehniskais risks pār to visu. Līdzīgā vidē spēja noteikt savu asociēto ir māksla, bez kura tas nav izdzīvojis. Izmantojot kodu, tiek veikta informācija, kas dalās gan kādā komandā, gan starp vairākām komandām, kas bieži tiek atdalītas ģeogrāfiski. Mēs izlasījām kodu, lai izprastu jaunu vai modificētu sistēmas programmatūras saskarņu ierīci. Dzīves cikls un uzvedība kompleksi objekti Definēts, izmantojot testa gadījumus, tas ir, atkal ar kodiem. Ziņojumi par jauniem jautājumiem ir kopā ar testa gadījumiem, kas rāda problēmu, kods tiek izmantots vēlreiz. Visbeidzot, mēs pastāvīgi nodarbojamies ar esošās koda uzlabošanu, padarot to produktīvāku, elastīgāku, saprotamāku. Acīmredzot šādos apstākļos programmatūras izstrāde ir gandrīz pilnībā balstīta uz kodēšanu, bet tajā pašā laikā mēs varam veiksmīgi papildināt projektus pēc laika, tāpēc Šī pieeja diezgan dzīvotspējīgs.

Mums nevajadzētu secināt, ka viss, kas nepieciešams, lai veiksmīgi īstenotu programmas projektu, ir priecīga sīva programmēšana. Izstrādāt programmatūru ir ļoti grūti, bet, lai attīstītu augstas kvalitātes programmatūru, un tajā pašā laikā pabeigts darbs uz laiku - vēl grūtāk. Lai par man aprakstīto pieeju, ir nepieciešams konsekventi piemērot svarīgus papildu noteikumus un metodes. No tā, ka Kent Beck (Kent Beck) sāk savu pozitīvo grāmatu par XP.

Es sadarbojos ar Kent un izmantoja epizodes, kas aprakstītas XP ietvaros, strādājot pie maza, bet nepieprasīts projekts, ko sauc par JUNIT

Ieviešana

Šī grāmata par ekstrēmo programmēšanu (

extreme programmēšana

XP). Ekstrēmā programmēšana ir vienkāršota metode, lai organizētu ražošanu mazām un vidējām speciālistiem, kas iesaistīti programmatūras izstrādājuma izstrādē, kas nav skaidras vai strauji mainīgas prasības. Šī grāmata ir izstrādāta, lai noteiktu, vai XP lietošana ir pamatota jūsu situācijā.

Daudziem XP izskatās kā diezgan pieņemams un attaisnojams no darba organizācijas metožu saprāta viedokļa. Tad kāpēc programmēšana saskaņā ar XP paņēmieniem sauc ārkārtīgi? Fakts ir tāds, ka XP rada daudzu vispārpieņemto un plaši izmantoto programmēšanas principu izmantošanu ekstremāliem līmeņiem.

Ja kodeksa pārskatīšana ir laba, tas nozīmē, ka mēs pastāvīgi pārskatīsim kodeksu (pāros);

EANS testēšana ir laba, katrs projekta dalībnieks pārbaudīs programmas kodu pastāvīgi (testēšanas moduļus), pat klientiem ( funkcionālā pārbaude);

Ersee dizains ir labs, tas nozīmē, ka dizains ir jāveic katra projekta dalībnieku ikdienas darbs (koda pārstrāde);

Extreme programmēšana

Veltīts manam tēvam, un es pateicos Cindy (Cindee Andres), mana sieva un partneris, lai prasītu, ka man nav pievērst uzmanību tam un rakstīja. Pateicoties Betānijai, Lincoln (Linkolnam), Forrest (Forrest) un nav traucējot mani un sniedza man rakstīt.

Par XP sēriju

Ekstrēmā programmēšana (ekstrēms programmēšana), ko bieži apzīmē ar XP saīsinājumu, ir programmatūras izstrādes un biznesa disciplīna programmatūras produktu izveides jomā, kas koncentrējas abu pušu (programmētāju un uzņēmēju) centienus uz kopīgiem, pilnībā sasniedzamiem mērķiem. Komandas, kas izmanto XP ražot augstas kvalitātes programmatūru ar ļoti lielu ātrumu. Metodes, kas ir daļa no šīs grāmatas aprakstītās XP disciplīnas tiek izvēlētas, jo tie ir balstīti uz cilvēka radošumu un pieņemot faktu, ka persona ir radījums nestabila un kļūdas.

Es teicu "atbildes sākums uz", jo turpinājums nav īsti. Cilvēki, kas izveidoja un ieviesa XP arī domāja par šī jautājuma lēmumu. Mēģināja izmantot XP, viņi pārgāja pāri slieksnim un apmeklēja noķeršanas. Atgriežas, viņi stāstīja savu stāstu. Viņās norādītās domas ir norādes, kas atrodas ceļā: "Dragons Live šeit," "15 km atver labu skatu," Šī vietne ir bīstama lietus laikā. "

Es atvainojos, bet man ir pienācis laiks programmēt.

Kent Beck, konsultantu sērija

Priekšvārds

Extreme programmēšana ( extreme programmēšana, XP) definē kodēšanu kā galvenās un pamatdarbības, strādājot ar programmas projektu. Ir iespējams, ka tas ir nepareizi!

Es domāju, ka ir vērts atcerēties savu pieredzi programmatūras izstrādē. Es strādāju vidē, kurā izstrādāts produkts ir pastāvīgi darba stāvoklī, un tās tiek pastāvīgi ieviestas izmaiņas. Nākamās praktiskās versijas izlaišanas termiņi ir acīmredzami saspiesti, un tajā pašā laikā ir milzīgs tehniskais risks pār to visu. Līdzīgā vidē spēja noteikt savu asociēto ir māksla, bez kura tas nav izdzīvojis. Izmantojot kodu, tiek veikta informācija, kas dalās gan kādā komandā, gan starp vairākām komandām, kas bieži tiek atdalītas ģeogrāfiski. Mēs izlasījām kodu, lai izprastu jaunu vai modificētu sistēmas programmatūras saskarņu ierīci. Dzīves cikls un sarežģītu objektu uzvedība tiek noteikta, izmantojot testa gadījumus, kas ir atkal ar kodiem. Ziņojumi par jauniem jautājumiem ir kopā ar testa gadījumiem, kas rāda problēmu, kods tiek izmantots vēlreiz. Visbeidzot, mēs pastāvīgi nodarbojamies ar esošās koda uzlabošanu, padarot to produktīvāku, elastīgāku, saprotamāku. Acīmredzot tādos apstākļos programmatūras izstrāde ir gandrīz pilnībā balstīta uz kodēšanu, bet tajā pašā laikā mēs varam veiksmīgi papildināt projektus pēc laika, tādējādi šī pieeja ir diezgan dzīvotspējīga.

Kent bija starp tiem vadītājiem Tektronix, kurš realizēja milzīgo potenciālu, kas noteikts programmēšanas metodikā saistīto pāru izstrādājot kompleksu inženiertehnisko lietojumprogrammu Mazajā vidē. Kopā ar Bard Cunningham (Ward Cunningham) Kent kļuva par paraugu plānošanas metožu iedvesmojošu attīstību (to sauc arī par programmēšanu, izmantojot modeļus - modeļu programmēšana.kas ievērojami ietekmēja savu karjeru. Ietvaros XP, pieeju izstrādei programmatūras, kas apvieno metodes, ko daudzi veiksmīgi strādājuši izstrādātāji, kuri pētīja daudz literatūras par organizāciju darbaspēka programmētāju, un ir mēģinājuši praksē daudzas metodes un procedūras programmatūras produkta izstrādei . Tāpat kā paraugu programmēšana, XP veido visefektīvāko metožu kopumu, piemēram, programmatūras moduļus, tvaiku programmēšanu un kodu pārstrādi. Kā daļu no XP, šīs metodes ir apvienotas tā, lai papildinātu un bieži vien kontrolētu viens otru. Šīs grāmatas galvenais mērķis ir runāt par dažādu metožu mijiedarbību un dalīšanu. Visās programmēšanas metodēs viens mērķis ir izveidot programmatūras produktu ar noteiktu funkcionalitāti noteiktā laika posmā. Ierosinātā OTI ir ļoti veiksmīga tikai laika programmatūras procesā nav XP tīra formaTomēr starp šīm divām pieejām ir daudz kopīga.

Es sadarbojos ar Kent un izmantoja epizodes, kas aprakstītas XP ietvaros, strādājot pie neliela, bet nepiemērota projekta, ko sauc par JUnit. Viņa viedokļi un pieejas programmu izstrādei vienmēr ir izveidojusi mani domāt par to, kā personīgi es strādāju pie programmas projekta. Bez šaubām, XP rada jautājumu par daudzām tradicionālajām pieejām, ko izmanto programmēšanas nozarē. Pēc šīs grāmatas lasīšanas jūs varat izlemt par savu, vai jums ir nepieciešams pieteikties XP savā darbā vai nē.

Extreme programmēšana

Par XP sēriju

Es teicu "atbildes sākums uz", jo turpinājums nav īsti. Cilvēki, kas izveidoja un ieviesa XP arī domāja par šī jautājuma lēmumu. Mēģināja izmantot XP, viņi pārgāja pāri slieksnim un apmeklēja noķeršanas. Atgriežas, viņi stāstīja savu stāstu. Viņās norādītās domas ir norādes, kas atrodas ceļā: "Dragons Live šeit," "15 km atver labu skatu," Šī vietne ir bīstama lietus laikā. "

Es atvainojos, bet man ir pienācis laiks programmēt.

Kent Beck, konsultantu sērija

Priekšvārds

Extreme programmēšana ( extreme programmēšana, XP) definē kodēšanu kā galvenās un pamatdarbības, strādājot ar programmas projektu. Ir iespējams, ka tas ir nepareizi!

Kent bija starp tiem vadītājiem Tektronix, kurš realizēja milzīgo potenciālu, kas noteikts programmēšanas metodikā saistīto pāru izstrādājot kompleksu inženiertehnisko lietojumprogrammu Mazajā vidē. Kopā ar Bard Cunningham (Ward Cunningham) Kent kļuva par paraugu plānošanas metožu iedvesmojošu attīstību (to sauc arī par programmēšanu, izmantojot modeļus - modeļu programmēšana.kas ievērojami ietekmēja savu karjeru. Ietvaros XP, pieeju izstrādei programmatūras, kas apvieno metodes, ko daudzi veiksmīgi strādājuši izstrādātāji, kuri pētīja daudz literatūras par organizāciju darbaspēka programmētāju, un ir mēģinājuši praksē daudzas metodes un procedūras programmatūras produkta izstrādei . Tāpat kā paraugu programmēšana, XP veido visefektīvāko metožu kopumu, piemēram, programmatūras moduļus, tvaiku programmēšanu un kodu pārstrādi. Kā daļu no XP, šīs metodes ir apvienotas tā, lai papildinātu un bieži vien kontrolētu viens otru. Šīs grāmatas galvenais mērķis ir runāt par dažādu metožu mijiedarbību un dalīšanu. Visās programmēšanas metodēs viens mērķis ir izveidot programmatūras produktu ar noteiktu funkcionalitāti noteiktā laika posmā. Ierosinātā OTI Veiksmīga tikai laika programmatūras procesā nav XP tīrā veidā, bet starp šīm divām pieejām ir daudz kopīga.

Erich gamma (erich gamma)

Ieviešana

Šī grāmata par ekstrēmo programmēšanu ( extreme programmēšana, XP). Ekstrēmā programmēšana ir vienkāršota metode, lai organizētu ražošanu mazām un vidējām speciālistiem, kas iesaistīti programmatūras izstrādājuma izstrādē, kas nav skaidras vai strauji mainīgas prasības. Šī grāmata ir izstrādāta, lai noteiktu, vai XP lietošana ir pamatota jūsu situācijā.

Ja kodeksa pārskatīšana ir laba, tas nozīmē, ka mēs pastāvīgi pārskatīsim kodeksu (pāros);

EANS testēšana ir laba, katrs projekta dalībnieks pārbaudīs programmas kodu pastāvīgi (testēšanas moduļus), pat klientiem (funkcionālās pārbaudes);

Ersee dizains ir labs, tas nozīmē, ka dizains ir jāveic katra projekta dalībnieku ikdienas darbs (koda pārstrāde);

Esley vienkāršība ir laba, tas nozīmē, ka mums ir jāsaglabā vienkāršākais sistēmas dizains, nodrošinot pašreizējo nepieciešamo funkcionalitātes līmeni (visvienkāršākā lieta, kas visticamāk darbosies); Ja arhitektūra ir svarīga, tas nozīmē, ka katrs no projekta dalībniekiem nepārtraukti strādās pie arhitektūras definīcijas un pārskatīšanas (metafora);

ESLEY integrācijas testēšana ir svarīga, tas nozīmē, ka ir nepieciešams savākt un pārbaudīt sistēmu, kas tiek izstrādāta vairākas reizes dienā (turpināt integrāciju);

Esley mazās iterācijas ir labas, tas ir nepieciešams, lai padarītu iterācijas ļoti, ļoti maza - sekundes, minūtes, varbūt stundas, bet ne nedēļas un mēnešus, un nekādā gadījumā gadījumu gadi (spēle plānošanā).

Kad es pirmo reizi nolēmu formulēt XP būtību sev, es iedomājos rokturu komplektu vadības panelī. Katrs rokturis atbilst kādai metodikai, par kuru no viņa personīgā pieredze Es zināju, ka tas bija diezgan efektīvs. Katrs rokturis ļāva izmantot šo vai šo paņēmienu zināmā mērā: no 1 līdz 10. Es mēģināju instalēt visus rokturus līdz maksimālajam iespējamajam stāvoklim (10), un es biju pārsteigts, ka pilnā metožu kopums, ko es uzskatīju par mani paliek stabila, paredzams un elastīgs.

XP veido divus solījumu kopumus:

Programmētāji XP sola, ka katrs no viņiem strādās pie risinājuma patiesi svarīgiem uzdevumiem katru darba dienu. Katrs no tiem nekad nebūs vienīgais daudzums. Katrs no viņiem varēs darīt visu, kas tajā ir atkarīga, lai padarītu sistēmu veiksmīga. Katrs no viņiem varēs pieņemt lēmumu tieši tajā apgabalā, kurā tā ir kompetenta, un, ja tā nav kompetenta kādā reģionā, tas nepiedalīsies lēmumu pieņemšanā.

Klienti un HR vadītāji sola, ka viņi saņems maksimālo iespējamo atdevi no katras darba nedēļas uz projektu. Ik pēc pāris nedēļām viņi varēs redzēt progresu, lai sasniegtu savus mērķus. Viņiem būs iespēja mainīt projekta attīstības virzienu attīstības vidū, baidoties no papildu ārkārtas izmaksām.

Ja jūs runājat īsi, XP sola samazināt risku saistīto risku, uzlabot reakciju uz uzņēmējdarbības maiņu, uzlabot projekta izpildi un padarīt programmatūras izstrādes procesu ir patīkamāka - un tas viss tajā pašā laikā. Es neesmu kidding, pietiekami smieties. Vienkārši izlasiet šo grāmatu, un jūs pats varat pārbaudīt, vai es esmu traks.

Šī grāmata

Šī grāmata stāsta par lietām, kas saistītas ar XP metodi, saknēm, filozofiju, dažāda veida stāstiem un mītiem. Grāmata ir izstrādāta, lai palīdzētu jums pieņemt svērto lēmumu par to, vai ir nepieciešams izmantot XP savā projektā. Ja pēc šīs grāmatas lasīšanas nolēma neizmantot XP, strādājot pie jūsu projekta, es uzskatu, ka galvenais mērķis ir tāds pats kā tad, ja pēc šīs grāmatas lasīšanas jūs pieņemtu lēmumu, ka XP ir tas, kas jums nepieciešams . Otrais grāmatas mērķis ir palīdzēt tiem no jums, kas jau izmanto XP. Pēc grāmatas lasīšanas šādi lasītāji varēs labāk izprast šo tehniku.

Šajā grāmatā nav precīzu norādījumu par to, kā tieši jāveic ekstrēmās programmēšanas process. Jūs neredzēsiet daudzus piemērus, algoritmus vai programmētāju stāstus tajā. Lai iegūtu to visu, jūs varat meklēt internetā, runāt ar dažiem projekta dalībniekiem, pagaidiet, kamēr parādās grāmatu izskats, kas veltītas šim vai tam, kā izveidot šādu materiālu.

Turpmākais likteņa aprakstītais programmatūras izstrādes disciplīna XP ir cilvēku grupas rokās (varbūt jūs esat viens no tiem), kas ir neapmierināti ar esošo Šis brīdis Tradicionālās programmētāju darbaspēka organizēšanas metodes. Jums ir nepieciešams B. labākais veids Programmatūras izstrāde, jūs vēlaties izveidot produktīvākas un draudzīgas attiecības ar saviem klientiem, jūs vēlaties strādāt zem jūsu vadības programmētājiem laimīgākiem, lojālākiem un produktīvākiem. Īsi sakot, jūs vēlaties, lai iegūtu ievērojamu priekšrocību, un jūs nebaidāties izmantot jaunas idejas, lai iegūtu šo priekšrocību. Tomēr pirms riska jūs vēlaties pārliecināties, ka esat vismaz ne pilnīgs muļķis.

XP nosaka jūs darīt darbu diezgan atšķirīgi, nekā jūs esat pieraduši pie tā. Dažos gadījumos XP ieteikumi pilnīgi pretrunā vispārpieņemtiem standartiem. Uz Šis brīdis Es uzskatu, ka tikai tie, kam ir nozīmīgi iemesli, lai mainītu esošo kārtību, varēs izmantot XP. Tomēr, ja pastāv šādi iemesli, jūs varat sākt izmantot XP tieši tagad. Es uzrakstīju šo grāmatu, lai jūs varētu uzzināt par šiem iemesliem vairāk.

Kas ir XP?

Kas ir XP? XP ir vienkāršots, efektīvs, elastīgs, paredzams, zinātniski pamatots un ļoti patīkams veids, kā izstrādāt programmatūru, kas paredz zems līmenis risks. No citām metodēm XP atšķiras šajās funkcijās.

Pateicoties ļoti īsu ciklu izmantošanai, XP attīstība piedāvā ātru, reālu un pastāvīgi funkcionējošu atgriezenisko saiti.

Ietvaros XP, plānojot pieaugošo, kā rezultātā vispārējais plāns projekta rodas diezgan ātri, bet ir saprotams, ka šis plāns attīstās visu laiku projekta dzīves laikā.

XP ietvaros tiek izmantots elastīgs viena vai citas funkcionalitātes realizācijas grafiks, tādējādi uzlabojot reakciju uz uzņēmuma rakstura maiņu un klienta prasību maiņu.

XP ir balstīta uz automātiskiem testiem, ko izstrādājusi gan programmētāji, gan klienti. Pateicoties šiem testiem, ir iespējams uzraudzīt attīstības procesu, lai nodrošinātu pareizu sistēmas attīstību un nekavējoties atklāt sistēmas defektus sistēmā.

XP ir balstīta uz mutisku informācijas, testu un avota koda apmaiņu. Trīs no šiem instrumentiem tiek izmantoti, lai apmainītos ar informāciju par sistēmas struktūru un tās uzvedību.

XP ir balstīta uz attīstās dizaina procesu, kas turpinās tik ilgi, kamēr sistēma pati pastāv.

XP ir balstīta uz ciešo mijiedarbību programmētājiem, kuriem ir visizplatītākās prasmes un iespējas.

XP ir balstīta uz metodēm, kas atbilst gan īstermiņa instinkiem individuālo programmētāju un ilgtermiņa intereses visa projekta kopumā.

XP ir programmatūras izstrādes disciplīna. Tas ir disciplīna, jo XP ietvaros ir dažas lietas, kas jums jādara, ja plānojat izmantot XP. Jums nav jāizvēlas, tas ir nepieciešams vai nav rakstīt testus, jo, ja jūs to nedarīsiet, programmējot jūs, jūs nevarat saukt ārkārtīgi: beigas diskusiju.

XP tehnika ir paredzēta, lai strādātu pie projektiem, kas var darboties no diviem līdz desmit programmētājiem, kuri nav piestiprināti spēkā esošā datora vides stingrā ietvaros un kurā visu nepieciešamo darbu, kas saistīts ar testēšanu, var veikt vienas dienas laikā.

XP biedē vai kaitina dažiem cilvēkiem, kuri pirmo reizi saskaras ar šo metodi. Tajā pašā laikā, ne jausmas XP nav jauna. Savā ziņā, XP metode ir konservatīva - visas metodes, ko izmanto savā sistēmā tiek pārbaudīti pēc desmitgadēm (kā par īstenošanas stratēģiju) un pat gadsimtiem (kā par vadības stratēģiju) praksē.

Inovācijas XP ir šādas funkcijas:

Visas šīs ilgstošās metodes ir samontētas zem viena jumta;

Intensitāte, ar kuru šīs metodes tiek ieviestas ikdienas darbā, tiek parādīta galējībām;

Izmantotās metodes pēc iespējas vairāk atbalsta viens no otra.

Atbilstība

Viņu darbos Meža iedzīvotāji (meža tautas) un kalns (cilvēki kalnu tautas) Antropologs Colin Turnbull (Colin Turnbull) apraksta divas sabiedrības pilnīgi atšķirīgas viena no otras. Dzīvei nepieciešamajos kalnos trūkst resursi, un cilvēki vienmēr ir bada malā. Kultūra, kas radās šādos apstākļos izskatās drausmīgs. Mātes mest savus bērnus, lai izdzīvotu sevi. Impregnēšana var izraisīt traumas. Nežēlība, nežēlības un nodevība ir parastas un ikdienas.

Atšķirībā no kalniem mežs ir piesātināts ar resursiem. Lai nodrošinātu sev uzņemšanu visai dienai, cilvēks ir pietiekami, lai tērētu apmēram pusstundu. Meža kultūra ir ieguves kultūras atspoguļojums. Pieaugušie piedalās kopīgu bērnu audzēšanā un izglītībā, kas aug mīlestībā un aprūpē, līdz tie kļūst pietiekami spējīgi rūpēties par sevi. Ja viena persona nogalina citu personu (šo cilvēku apzināta slepkavība nav pazīstama), viņš tiek izraidīts no sabiedrības. Tomēr, tajā pašā laikā, trimdā vienkārši jānoņem mežā un pavadīt dažus mēnešus tur, un pat tad daži locekļi cilts celt viņu pārtiku un dāvanas.

XP ir mēģinājums atbildēt uz jautājumu: kā jūs personīgi programmētu, ja jums bija pietiekami daudz laika? Patiesībā, jums nav pārāk daudz laika, jo gala programmās ir bizness. Jebkurā uzņēmumā uzvar vienu, kas padara darbu ātrāk. Tomēr, ja jums bija laiks, jūs, iespējams, pievērsiet uzmanību testu izstrādei; Jūs, iespējams, varētu atjaunot sistēmas arhitektūru, ja būtu nepieciešams secināt, ka tas ir nepieciešams; Jūs noteikti sazināsieties ar mūsu programmētāju biedriem, kā arī ar klientu.

Līdzīga pietiekamības sajūta izskatās vairāk humānas, atšķirībā no situācijām, kad programmētāji no pēdējiem spēkiem cenšas palikt noteiktā pagaidu shēmā, izsist no grafika, nav laika, lai veiktu lielu daudzumu ārkārtīgi svarīga darba tikai kārtībā ir jānokārto projekts savlaicīgi. Pasteidzies novērš programmētājus pilnībā parādīt savu talantu un baudīt darbu. Tomēr, sākot izpētīt XP, jums ir jāsaprot, ka pietiekamības sajūta ir arī labs bizness. Pietiekamības sajūta kļūst par efektivitātes avotu tādā pašā veidā kā trūkuma sajūta rada traucējumus, izraisa trūkumu izskatu un kvalitātes samazināšanos, un, visbeidzot, darba ražīguma samazināšanos.

Plānot grāmatu

Grāmata ir rakstīta tā, it kā jūs arī veicat jaunu programmatūras izstrādes disciplīnas izveidi. Mēs sākam ar pētījumu par mūsu pamatidejām par programmatūras izstrādi. Pēc tam mēs faktiski izveidojam jaunu disciplīnu. Tad mēs pētām sekas, ko mēs esam izveidojuši - kā to var īstenot un izmantot praksē, ja to nedrīkst izmantot, un kādas iespējas tās atveras uz uzņēmējdarbību.

Grāmata ir sadalīta trīs daļās.

Problēma: Nodaļās, sākot ar Risks: galvenā problēma Un apdares Atpakaļ uz izcelsmiProblēma tiek noteikta, ka galējā programmēšana mēģina atrisināt, un kritērijus nosaka, kuru var aprēķināt risinājuma kvalitāti. Šajā daļā jūs saņemsiet vispārēju priekšstatu par galējās programmēšanas metodi.

Lēmums: Nodaļās, sākot ar Īss pārskats Un apdares Testa stratēģijaAbstraktās idejas, kas tika prezentētas grāmatas pirmajā daļā, tiek pārvērstas konkrētu disciplīnu paņēmienu komplektā. Šajā nodaļā nav nekādas informācijas par to, kā jūs varat izmantot aprakstītās metodes praksē. Tā vietā mēs runājam par katras metodes vispārējo formu. Apgalvojot par katru paņēmienu, es to saistīt ar problēmām un principiem, kas aplūkoti grāmatas pirmajā daļā.

XP realizācija: Nodaļās, sākot ar Ievads XP Un apdares XP darbāDaudzi jautājumi, kas saistīti ar XP ieviešanu, tiek apspriesti - kā ieviest XP, kas būtu sagaidāms no dažādiem cilvēkiem, kas piedalās HP projektā, kuru ideja par XP attīstās biznesa pasaules iedzīvotājiem.

Paldies

Es aicinu lasītājus no pirmās personas, nevis tāpēc, ka grāmata iepazīstina ar savām idejām, un tāpēc, ka es jums saku par savu pašu izpratni par šīm idejām. Lielākā daļa no metodēm, ko izmanto XP ietvaros, ir vecas kā visas programmēšanas.

Ward Cunningham (Ward Cunningham) ir mans galvenais avots, no kura es kliedzu grāmatu materiālā. Viens veids vai otrs, es pavadīju pēdējo piecpadsmit gadus, vienkārši mēģinot izskaidrot citiem cilvēkiem, kas ir praktiski iesaistīts gandrīz ilgu laiku. Paldies arī Ron Jeffries par to, ka viņš to arī mēģināja, un pēc tam ievērojami uzlabojās. Pateicoties Martin Fower (Martin Fowler), lai to izskaidrotu ar vienkāršu mīkstu valodu un bez nervu traucējumiem. Pateicoties Erich Gamma (Erich Gamma) ilgu sarunām, apvienojumā ar gulbju kontemplāciju Limme, kā arī neļauj man atstāt viņu ar sliktām domām manā galvā. Un, protams, manā dzīvē nekas nenotiks, ja man nebūtu šāda imitācijas piemērs, piemēram, mans tēvs, Doug Beck, kurš daudzus gadus izturēja savas programmēšanas iemaņas.

Pateicoties komandai C3 uzņēmumā Chrysler par mani pavada manos apsekojumos. Un arī īpašs paldies mūsu vadītājiem iesūdzēt dusmas (Ron Savage) par to, ka viņiem bija pietiekami drosmi, lai sniegtu mums mēģinājumu.

Pateicoties Daedalos Consulting par palīdzību rakstot šo grāmatu.

Čempionāta atlīdzība par materiāla skatīšanu nonāk Paul Chisholm (Paul Chisholm) rokās, lai tās bagātīgajam, ietaupītu, rūpīgus, un bieži atklāti kaitinošas komentārus. Bez viņa palīdzības Šī grāmata Es nebūtu vienīgais kā populārs.

Man tiešām ir liels prieks sazināties ar visiem tiem, kas veica priekšskatījums Ko es rakstīju.

Viņu darbs ir kļuvis par milzīgu palīdzību man. Es nevaru atrast pateicības vārdus par to, ka viņiem bija pietiekami daudz pacietības lasīt visu šo prozu, daudziem no tiem izklāstīti svešvalodā.

Paldies (nejaušā secībā, kādā es saņēmu komentārus no tiem) Greg Hutchinson, Massimo Arnoldi, Dave Kleāls, Sams Schuster, Don Wells, Joshua Kerievsky, Torsten Dittmar (Thorsten Dittmar), Moritz Beker (Daniel Gumland), Christofe Hendric Christoph Henrici), Thomas Zangu (Dierk Koenig), Miroslav Novaka (Mroslav Novak), Rodney Rodney Rodney, Frank Westphal, Paul Trunz, Steve Hayes (Steve Hayes), Kevin Bradtke, Janny de Guzman (Jeanine de Guzman), uz Kubit ( Toms Kubit), Falkmann, Hasko Heinec (Peter Merel), Rob Mc (Rob Mell), McBreen, Tomas ERNSTU (Thomas Ernst), Guido Hchelle (Guido Hachler), Dieter Holz, Martin Knecht, Dirka Krampe ( DIERK KRAMPE), Patrick Lisser (Patrick Lisser), Elisabeth Maier, Thomas Mancini (Thomas Mancini), Aleksio Moro (Alexio Moreno), Rolfa Pfenninger (Rolf Pfenninger) un Matthias Ressel).

No publicēšanas

Jūsu komentāri, ieteikumi, nosūtiet jautājumus e-pasta adrese [E-pasts aizsargāts] (Petter izdevniecība, datoru redakcija).

Mēs priecāsimies uzzināt jūsu viedokli!

Visi avoti teksti grāmatā jūs varat atrast vietnē http://www.piter.com/download.

Uzdevniecības mājas lapā http://www.piter.com atradīsiet detalizētu informāciju par mūsu grāmatām.

Problēma

Šajā grāmatas daļā skatuve ir sagatavota, uz kuras ir jābūt ārkārtīgi programmēšanai. Tajā aprakstīti dažādi problēmu risināmie aspekti, veidojot jaunu programmatūras izstrādes disciplīnu.

Šajā sadaļā aplūkoti galvenie pieņēmumi, kas mums jāņem vērā, izvēloties programmatūras izstrādes metodes, auto vadības metaforu, četras vērtības, principi, kas veidoti, pamatojoties uz šīm vērtībām, kā arī darbības, kas nepieciešamas strukturētām Jaunās programmatūras izstrādes disciplīnas ietvars.

Risks: galvenā problēma

Esošās programmatūras izstrādes disciplīnas netiek izraisītas un nedod vēlamo ekonomisko efektu. Šai problēmai ir milzīga ekonomiskā un humānā nozīme. Mums ir nepieciešams jauns veids, kā attīstīt programmatūru.

Programmatūras izstrādes galvenā problēma ir risks.

Šeit ir daži riska piemēri.

Fotografēšanas diagrammas- Piegādes diena nāk, un jūs esat spiesti informēt klientu, ka sistēma tiek izstrādāta, nebūs gatava vēl sešiem mēnešiem.

Projekta slēgšana- Pēc vairākām piegādes dienas grafika un nodošanas maiņām projekts netiek aizvērts testa posmā darba apstākļos.

Sistēma zaudē savu lietderību - attīstīta programmatūra ir veiksmīgi izveidota reālā ražošanas darba vidē, bet pēc pāris gadu lietošanas, izmaksas par izmaiņām tajā un / vai defektu skaits palielinās tik daudz, ka tas kļūst lētāk aizstāt sistēmu ar jaunu attīstība.

- Programmatūras sistēma ir uzstādīta reālā ražošanas vidē, bet defektu skaits un trūkumi ir tik lieli, ka sistēma netiek izmantota.

- Programmatūras sistēma ir uzstādīta reālā ražošanas darba vidē, tomēr izrādās, ka patiesībā tas neatrisina uzņēmējdarbības problēmu, lai atrisinātu, kas tas sākotnēji bija paredzēts.

Biznesa mainīšana - Programmatūras sistēma ir uzstādīta reālā ražošanas darba vidē, tomēr, sešu pēdējos mēnešos, problēma, par kuru šī sistēma bija paredzēta būt būtiska, un tā vietā uzņēmums saskārās ar jaunu, vēl nopietnāku problēmu.

Iespēju trūkums - Programmatūras sistēmai ir daudzas potenciāli interesantas iezīmes, no kurām katra bija ļoti patīkami programmēt, bet izrādās, ka neviena no šīm iespējām nesniedz diezgan daudz labumu klientam.

Mācību rāmji - divu gadu darba, viss labi programmētājiKas strādāja pie projekta, viens pēc otra izvirzīja programmas sistēmu izstrādāta un devās uz citu darbu.

Šīs grāmatas lapās jūs izlasīsiet par ārkārtēju programmēšanu ( extreme programmēšana, XP) - programmatūras izstrādes disciplīna, kas vērsta uz riska pakāpes samazināšanu visos attīstības procesa līmeņos. XP veicina ievērojamu produktivitātes pieaugumu un uzlabot izstrādāto programmu kvalitāti, turklāt tā ir ļoti aizņemta prakse, kas visiem saviem dalībniekiem dod daudz prieka.

Kā XP samazina iepriekš uzskaitītos riskus?

Pārvietošanās grafika - XP piedāvā izmantot ļoti īsu laiku atbrīvot katru nākamo versiju. Katra regulāra gatavās lietošanas sistēmas versija ir izstrādāta ne vairāk kā vairākus mēnešus. Tādējādi darba apjoms katrā versijā ir ierobežots, un tādēļ, ja notiek pārvietojums, tas ir mazāk nozīmīgs. Katrā versijā ir plānots izdot vairākas iterācijas, ko pieprasa klientu iespējas attīstīt katru no šīm iterācijām no vienas līdz četrām nedēļām. Tas nodrošina elastīgu un jutīgu atgriezenisko saiti ar klientu, lai viņš saņemtu ideju par pašreizējo darbu. Katrā iterācijā plānošana saskaņā ar XP tiek veikta vairākos uzdevumos, kas ir jārisina, lai iegūtu nākamo atkārtojumu. Katra uzdevuma risinājums tiek dots no vienas līdz trim dienām. Tā rezultātā komanda var atklāt un novērst problēmas pat iterācijas procesā. Visbeidzot, XP nozīmē, ka iespējas ar augstāko prioritāti tiks īstenota vispirms. Tādējādi visas iespējas, kas nav īstenojušas šīs regulārās programmatūras produkta versijas ietvaros, ir mazāka prioritāte.

Projekta slēgšana - XP ietvaros Klientam jānosaka vismazākās pieļaujamās iespējas, ka programmas minimālā darba versija ir jēga no viedokļa, lai risinātu uzņēmējdarbības uzdevumus. Tādējādi programmētājiem būs nepieciešams veikt minimālo piepūli, lai klients saprastu, vai tam ir nepieciešams šis projekts vai nē.

Sistēma zaudē savu lietderību - kā daļa no XP, tiek izveidoti un atbalstīti milzīgs testu skaits, kas tiek uzsākti un restartēti pēc jebkādām izmaiņām sistēmā (vairākas reizes dienā), kuru dēļ ir iespējams rūpīgi uzraudzīt programmas kvalitāti tiek izstrādāts. XP pastāvīgi atbalsta sistēmu lieliskā stāvoklī. Defekti vienkārši nedod uzkrāt.

Defektu skaits un trūkumi - XP ietvaros izstrādātā sistēma ir pārbaudīta kā programmētāji, kas veido testus katrai atsevišķai funkcijai, un klienti, kas rada testus katrai atsevišķai sistēmas spējas.

Trūkst problēmu, kas tiek atrisināta - Kā daļa no XP, klients ir neatņemama daļa no komandas, kas darbojas uz projektu. Projekta specifikācija tiek pastāvīgi pārstrādāta visā projektā, pateicoties tam, jebkuram izsmalcinātībai un atklājumiem, kurus Klients ziņo par attīstības komandu, nekavējoties atrodiet savu atspoguļojumu programmā tiek izstrādāta.

Extreme programmēšana: attīstība, izmantojot testēšanu

Veltīts Cindy: manas dvēseles spārnus

Publikācijas tiesības tika iegūtas, vienojoties ar Addison-Wesley Longman. Visas tiesības aizsargātas. Nevienu šīs grāmatas daļu nevar reproducēt jebkurā veidā bez autortiesību īpašnieku rakstiskas atļaujas.

Šajā grāmatā ietvertā informācija tiek iegūta no avotiem, ko izdevējs uzskata par uzticamu. Tomēr, ņemot vērā iespējamās cilvēka vai tehniskās kļūdas, izdevējs nevar garantēt absolūtu precizitāti un pilnīgumu informācijas un nav atbildīga par iespējamām kļūdām, kas saistītas ar grāmatas izmantošanu.

ISBN 978-0321146533 angļu

ISBN 978-5-496-02570-6

Priekšvārds

Tīrs kods, kas darbojas (Tīrais kods, kas darbojas) - šajā īsajā, bet satura frāzē, izgudroja Ron Jefries (Ron Jeffries), ir visa attīstības metodikas nozīme, izmantojot testēšanas (testa virzītu attīstību, TDD). Tīrs kods, kas darbojas, ir mērķis, uz kuru ir vērts tiecoties, jo

Tas ir paredzams veids, kā izstrādāt programmas. Jūs zināt, kad darbu var uzskatīt par pilnīgu un neuztraucieties par ilgu kļūdu sēriju;

Dod iespēju mācīties, ka kodu dāvanas. Ja jūs izmantojat pirmo ideju, kas atnāca prātā, jums nebūs iespēja realizēt otro, labāku ideju;

Uzlabo jūsu programmu lietotāju dzīvi;

Ļauj jūsu kolēģiem paļauties uz jums, un jūs - paļauties uz tiem;

Uzrakstiet šādu kodu patīkamāku.

Bet kā iegūt tīru kodu, kas darbojas? Daudzi spēki traucē mums, lai iegūtu tīru kodu, un dažreiz tas nav iespējams pat iegūt kodu, kas tikai darbojas. Lai atbrīvotos no daudzām problēmām, mēs izstrādāsim kodu, pamatojoties uz automatizētu testēšanu. Šo programmēšanas stilu sauc par testēšanu. Saskaņā ar šo tehniku

Jaunais kods ir uzrakstīts tikai pēc automātiska testa, kas pabeigta neizdodas;

Jebkura dublēšanās tiek likvidēta.

Divi vienkārši noteikumi, vai ne? Tomēr tie rada sarežģītu indivīdu un grupu uzvedību ar daudzām tehniskām sekām:

Dizaina procesā mēs pastāvīgi uzsākam kodu un saņemu priekšstatu par savu darbu, tas palīdz pieņemt pareizos lēmumus;

Mēs rakstām testus sevi, jo mēs nevaram gaidīt, ka kāds cits rakstīs testus mums;

Mūsu attīstības videi ir ātri jāatbilst maziem kodu modifikācijām;

Programmas projektam jābalstās uz autonomo, vāju saistīto komponentu kopuma izmantošanu, lai vienkāršotu kodu testēšanu.

Abi minētie TDD noteikumi nosaka procedūru plānošanas posmiem.

1. Sarkanā - uzrakstiet nelielu pārbaudi, kas nedarbojas, un varbūt pat nav pat apkopoti.

2. Zaļais - padarīt testa darbu pēc iespējas ātrāk, nedomājiet par kodeksa dizaina un tīrības nosaukumu. Rakstiet tieši tik daudz kodu, lai veiktu pārbaudi.

3. Uzfactoring - novērst jebkādu dublēšanos no rakstiskā koda.

Sarkanais - zaļais - refactoring ir TDD mantra.

Ja mēs pieņemam, ka šāds programmēšanas stils ir iespējams, to var pieņemt, ka tā lietošanas dēļ kodeksā būs ievērojami mazāk defektu, turklāt darba mērķis būs skaidrs ikvienam, kurš tajā piedalās. Ja tā, tad, tad attīstība tikai kodu, kas nepieciešams, lai nodotu testus, arī noved pie sociālajām sekām:

Ar pietiekami zemu defektu blīvumu, kvalitātes nodrošināšana, QA varēs pāriet no atbildes uz kļūdām, lai viņu brīdinātu;

Ar nepiedienīgu pārsteigumu skaita samazināšanos, projektu vadītāji varēs precīzāk novērtēt darbaspēka izmaksas un iesaistīt klientus attīstības procesā;

Ja tehnisko diskusiju tēmas ir skaidri definētas, programmētāji var pastāvīgi mijiedarboties ar otru, un vairāk nekā vienu reizi dienā vai reizi nedēļā;

Un atkal, ar diezgan zemu defektu blīvumu, mēs varam saņemt integrētu darba produktu ar jaunu funkcionalitāti, kas to pievieno katru dienu, lai mēs varētu pievienoties mūsu klientiem biznesa attiecībās pilnīgi jauna veida.

Tātad, ideja ir vienkārša, bet kāda ir mūsu interese? Kāpēc programmētājs uzņemas papildu maksu, lai rakstītu automatizētus testus? Kāpēc pārvietot programmētāju, lai virzītos uz priekšu ar sīkām ķēdēm, kad viņa smadzenes var domāt vairāk par daudz sarežģītāku dizaina struktūru? Drosme.

Drosme

TDD ir veids, kā pārvaldīt bailes programmēšanas procesā. Es nenozīmē bailes no krēsla no galvas vai bailes no galvas. Es domāju bailes no uzdevuma, "tik sarežģīts, ka man nav ne jausmas, kā to atrisināt." Sāpes ir tad, kad daba stāsta mums: "Stop!" Un bailes ir tad, kad daba stāsta mums: "Esiet uzmanīgi!" Uzmanība vispār nav slikti, bet papildus labumam, bailes ir negatīva ietekme uz mums:

Bailes padara mūs iepriekš un rūpīgi domā par kaut ko vai atšķirīgu rīcību;

Bailes padara mūs mazāk sazināties;

Bailes liek mums baidīties no atgriezeniskās saites uz mūsu darbu;

Bailes padara mūs uzbudināmus.

Nekas no tā nevar saukt par noderīgu programmēšanas procesu, it īpaši, ja jūs strādājat ar sarežģītu uzdevumu. Tātad, mēs saskaramies ar jautājumu par to, kā izkļūt no sarežģītās situācijas un

Nemēģiniet prognozēt nākotni un nekavējoties sākt praktisku problēmu;

Nav labots no pārējās pasaules, bet, lai palielinātu saziņas līmeni;

Neizvairieties no atbildēm, bet, gluži pretēji, izveidojiet uzticamu atgriezenisko saiti un ar tās palīdzību rūpīgi pārrauga jūsu darbību rezultātus;

(Ar kairinājumu, jums ir jātiek galā ar sevi).

Salīdziniet programmēšanu ar akas spaini. Spainis ir piepildīts ar ūdeni, jūs pagrieziet sviru, tinumu ķēdi uz vārtiem un paaugstinot spaini augšāvā. Ja neliels spainis ir diezgan piemērots regulāriem, brīvi rotējošiem vārtiem. Bet, ja spainis ir liels un grūti, jūs būsiet noguris pirms to audzēšanas. Lai iegūtu iespēju atpūsties starp pagriezieniem sviru, ir nepieciešams ratchet mehānisms, kas ļauj jums noteikt sviru. Jo grūtāk spainis, jo biežāk zobiem vajadzētu sekot uz zobratūras pārnesumu.

TDD testi ir zobi uz ratchet rīkiem. Piespiežot testu darbam, mēs zinām, ka tagad testa darbi, no šī brīža uz visiem laikiem. Mēs esam kļuvuši par vienu soli tuvāk darba pabeigšanai nekā pirms nopelnītā testa. Pēc tam mēs spiesti strādāt otrajā testā, tad trešais, ceturtais, utt. Jo grūtāk problēma saskaras programmētājs, jo mazāk funkcionalitāti jāaptver katrs tests.

Lasītāju grāmatas Extreme programmēšana izskaidroTai jāpievērš uzmanība tonim starp ekstrēmo programmēšanu (ekstrēmi programmēšana, XP) un testēšana, izmantojot testēšanu (testēšanas virzīta attīstība, TDD). Atšķirībā no XP TDD tehnika nav absolūta. XP saka: "Lai pārietu uz priekšu, jums ir jāiemācās to un tā." TDD ir mazāk specifiska tehnika. TDD uzņemas intervālu starp lēmumu pieņemšanu un rezultātu iegūšanu un piedāvā instrumentus, lai kontrolētu šī intervāla ilgumu. "Ko darīt, ja nedēļas laikā es izstrādāt algoritmu uz papīra, un pēc tam uzrakstīt kodu, izmantojot" pirmās pārbaudes "pieeju? Vai tas atbilst TDD? " Protams, tas būs. Jūs zināt, cik lielumu starp lēmumu pieņemšanu un rezultātu novērtēšanu un apzināti kontrolēt šo intervālu.

Lielākā daļa cilvēku, kas apguvuši TDD, apgalvo, ka viņu programmēšanas prakse ir mainījusies labākai. Inficēts ar testiem (Testa inficēts) - Šāda definīcija nāca klajā ar Erich Gamma (Erich Gamma), lai aprakstītu šīs izmaiņas. Apgūtis TDD, jūs atklājat, ka jūs rakstāt daudz vairāk testu nekā iepriekš, un virzieties uz priekšu ar nelieliem soļiem, kas būtu parādījušies jums bezjēdzīgi. No otras puses, daži programmētāji, iepazinušies ar TDD, nolemj atgriezties pie iepriekšējo praksi, rezervējot TDD īpašiem gadījumiem, kad parastā programmēšana neizraisa vēlamo progresu.

Noteikti ir neiespējami (vismaz šobrīd) uzdevumi, lai atrisinātu tikai testus. Jo īpaši TDD neļauj mehāniski pierādīt izstrādātā koda atbilstību attiecībā uz datu drošību un paralēlu darbību uzticamību. Protams, drošība ir balstīta uz kodu, kurā nevajadzētu būt defektiem, bet tas ir balstīts arī uz cilvēku līdzdalību datu aizsardzības procedūrās. Plānas paralēlu operāciju problēmas nav iespējams reproducēt ar pārliecību, vienkārši darbojas kādu kodu.