Za mnoge koji dolaze nakratko u kontakt sa Extreme Programming, čini se da XP poziva na smrt dizajna softvera. Ne samo je mnogo dizajna aktivnost ismevane kao “Big Up Front Design”, ali kao što dizajn tehnike kao UML, fleksibilne okvire, pa čak i obrasci su de-naglasio ili stvarno zanemariti. U stvari, XP uključuje puno dizajna, ali to radi na drugačiji način nego osnovan softvera procesa. XP je podmlađena pojam evolucije dizajna sa praksama koje omogućavaju evolucija da postane održiva strategija dizajna. Ona također pruža nove izazove i vještine kao dizajneri trebaju naučiti kako napraviti jednostavan dizajn, kako koristiti pravljenja da bi dizajn čist, i kako koristiti obrasce u evolucioni stilu.
Extreme Programming (XP) izaziva mnoge zajedničke pretpostavke o razvoju softvera. Od ovih jedan od najkontroverznijih je njegova odbijanja značajne napore u up-front dizajn, u korist više evolutivni pristup. Svojim klevetnici da je ovo povratak “kod i popraviti” razvoj – obično ismijavana kao sjeckanje. Da bi svojim fanovima se često doživljava kao odbacivanje tehnika dizajna (kao što je UML), principa i obrazaca. Ne brinite o dizajnu, ako slušate vaš kod će se pojaviti dobar dizajn.
Sam se pronaći na adresi u centru ovog argumenta. Veći dio svoje karijere je uključen grafički dizajn jezika – Unified Modeling Language (UML) i njegova prethodnika – i obrazaca. Zaista sam pisao knjige i na UML i obrasce. Da li moj zagrljaj XP znači da povuče sve ono što sam napisao o ovim temama, čišćenje moj um od svih takvih kontra-revolucionarne ideje?
Pa neću očekivati da se mogu ostaviti da visi na udici dramske napetosti. Kratak odgovor je ne. Dugi odgovor je ostatak ovog rada.
Planirani i Evolucijski Dizajn
Za ovaj rad ću opisati dva stila kako se dizajn radi u razvoju softvera. Možda je najčešći je evolucijski dizajn. U suštini evolucijski dizajn znači da je dizajn sistema raste kao što je implementiran sistem. Dizajn je dio procesa programiranja i kao program razvija dizajn promjene.
U svojoj uobičajenoj upotrebi, evolucijski dizajn je katastrofa. Dizajn završava što je agregaciju gomilu ad-hoc taktičke odluke, od kojih svaka čini kod teže mijenjati. Na mnoge načine možda tvrditi da ovo nije dizajn, svakako to obično dovodi do lošeg dizajna. Kao Kent kaže, dizajn je tu da vam omogućiti da zadrži lako mijenjaju softver na dugi rok. Kao što je dizajn pogoršava, tako se vaša sposobnost da učinkovito napraviti promjene. Imate stanje softvera entropije, tokom vremena dizajn postaje sve gore i gore. Ne samo da ovo napraviti softver teže promijeniti, to čini bugova i lakše uzgajati i teže naći i sigurno ubiti. Ovo je “kod i popraviti” noćna mora, gdje bube postaju eksponencijalno skuplji popraviti kao projekt ide dalje.
Planirana Design je kontra toga, i sadrži pojam rođena iz drugih grana inženjerstva. Ako želite izgraditi nemilosti, možete samo dobiti neke drva zajedno i dobiti lošem stanju. Međutim, ako želite izgraditi neboder, možete raditi na taj način – samo će propasti prije nego što čak i dobiti na pola puta gore. Dakle, što počnete s inženjerske crteže, obavlja u inženjerska uredu poput onog moja supruga radi u Bostonu. Kao ona dizajna ona shvati sva pitanja, dijelom matematičke analize, ali uglavnom pomoću građevinskih propisa. Građevinski propisi postoje pravila o tome kako dizajnirati strukture na osnovu iskustva o tome šta radi (i neke osnovne matematike). Kada je dizajn učinio, onda je inženjering kompanija može predati dizajn off na drugu kompaniju koja gradi.
Planirani dizajn u softveru treba da rade na isti način. Dizajneri da se veliki problemi u unaprijed. Njima ne treba pisati kod jer nisu izgradnji softvera, oni su projektiranje ga. Tako da oni mogu koristiti dizajn tehnike kao što je UML koja dobije od neke detalje programiranja i omogućava dizajnerima da rade na više apstraktnom nivou. Kada je dizajn vrši se mogu predati ga u posebnu grupu (ili čak zasebna kompanija) za izgradnju. Budući da je dizajneri razmišljaju o većem obimu, mogu izbjeći niz taktičkih odluka koje dovode do softvera entropija. Programera mogu pratiti pravac dizajna i, pod uslovom da pratite dizajna, imaju dobro izgrađen sistem
Sada je planirano dizajn pristup još od 70-ih godina, i mnogi ljudi su ga koristili. Bolje je na mnogo načina nego kod i popraviti evolucijski dizajn. Ali ima neke mane. Prva greška je u tome što je nemoguće da kroz sva pitanja koja vam je potrebna da se bave kada programiranja. Tako da je neminovno da prilikom programiranja ćete naći stvari koje dovode u pitanje dizajn. Međutim, ukoliko se vrši dizajnera, preselio na drugi projekt, što se događa? Programeri početi kodiranje oko dizajna i setovi entropije u. Čak i ako je projektant nije prošla, treba vremena da sredim pitanja dizajn, promijeniti crteža, a zatim mijenjati kod. Tu je obično brži popravak i vremenskim pritiskom. Stoga entropija (opet).
Osim toga tu je često kulturni problem. Dizajneri su se dizajneri zbog znanja i iskustva, ali oni su tako zauzeti rade na dizajnu ne dobiju puno vremena da se kodirati bilo koji više. Međutim, alate i materijale razvoja softvera promjena velikom brzinom. Kada više nije kod ne samo da propustite o promjenama koje se javljaju s ovim tehnološkim fluksa, možete izgubiti poštovanje onih koji rade kod.
Ova tenzija između graditelja i dizajnera se događa u zgradi previše, ali to je intenzivnije u softveru. To je intenzivan jer je ključna razlika. U zgradi postoji jasnija podjela u sposobnosti između onih koji dizajniraju i onih koji grade, ali u softver koji je manje slučaj. Bilo koji programer koji rade u visokom dizajnu sredinama treba biti vrlo vješt. dovoljno vješti u pitanje dizajna dizajnera, posebno kada je dizajner je manje upoznati sa svakodnevnim stvarnostima razvojne platforme.
Sada može biti fiksna ovim pitanjima. Možda možemo nositi sa ljudskim napetosti. Možda možemo dobiti dizajneri dovoljno vješti da se bave većini pitanja i imati proces dovoljno disciplinovani promijeniti crteža. Postoji još jedan problem: mijenja zahtjeve. Mijenjanje zahtjevi su broj jedan veliki problem koji uzrokuje glavobolje u softverskim projektima koji radi u.
Jedan od načina da se nosi s promjenom zahtjeva je da se izgradi fleksibilnost u dizajnu, tako da možete lako može promijeniti kao mijenja zahtjeve. Međutim, to zahtijeva uvid u kakve promjene očekujete. Dizajn može se planirati da se bave područjima volatilnost, ali dok koji će pomoći za predviđene zahtjeve promjene, to neće pomoći (a može povrijediti) za nepredviđene promjene. Tako da ćete morati shvatiti zahtjeve dovoljno dobro da se odvoje nestabilna područja, i moja opservacija je da je to jako teško.
Neki od ovih zahtjeva problemi zbog ne razumijevanja zahtjeva dovoljno jasno. Tako mnogo ljudi se fokusiraju na zahtjeve inženjerskih procesa na bolje uslove u nadi da će to spriječiti potrebu za promjenu dizajna kasnije. Ali čak i tom pravcu je ona koja ne može dovesti do lek. Mnoge nepredviđene zahtjeve promjene nastaju zbog promjena u poslovanju. Oni se ne mogu spriječiti, međutim, oprezni vašim zahtjevima inženjering proces.
Dakle, sve ovo čini planirane dizajn zvuči nemoguće. Svakako oni su veliki izazovi. Ali ja nisam sklon tvrditi da planirani dizajn je gore nego evolucijski dizajn, jer se najčešće praktikuje u “kod i popraviti” način. Zaista volim planirao dizajn “kod i popraviti”. Međutim, svjestan sam problema planiranih dizajna i am seeking novom pravcu.
U Omogućavanje prakse XP
XP je kontroverzno iz mnogo razloga, ali jedan od ključnih crvene zastave u XP-u je u tome što se zalaže evolucijski dizajn, a od planiranog dizajna. Kao što znamo, evolucijski dizajn nikako ne može raditi zbog ad hoc odluke dizajn i softver entropija.
U srži razumijevanja ovaj argument je kriva promjena softvera. Kriva promjena kaže da kao projekat traje, postaje eksponencijalno skuplje napraviti promjene. Krivulja promjene se obično izražava u smislu faza “promjene se u analizi za 1$ bi koštalo hiljade popraviti u proizvodnji”. To je ironično jer je većina projekata i dalje raditi u proces ad-hoc da nema faze analize, ali je stepenovanje je i dalje tu. Eksponencijalna krivulja promjene znači da evolucijski dizajn nikako ne može raditi. Takođe, prenosi zašto planirane dizajn mora biti učinjeno pažljivo, jer neke greške u planiranim dizajn suočavaju sa istim stepenovanje.
Osnovnih pretpostavka u osnovi XP je da je moguće da se poravnati krivu promjenu dovoljno da evolucijski dizajn posao. Ovaj ravnanje je i omogućeno XP i eksploatišu XP. Ovo je dio spojnice prakse XP: konkretno ne možeš one dijelove XP da iskoristi spljoštene kriva bez raditi one stvari koje omogućavaju poravnavanje. Ovo je zajednički izvor kontroverzi oko XP. Mnogi ljudi kritikuju eksploatacije bez razumijevanja omogućava. Često kritike proizilaze iz vlastitog iskustva kritičara gdje nisu radili povoljnog prakse koje omogućavaju eksploataciju prakse za rad. Kao rezultat toga opekao i kad vide XP pamte vatru.
Postoji mnogo dijelova za omogućavanje prakse. U srži su prakse testiranja, i kontinuirano integracije. Bez sigurnosti koja testiranjem ostatak XP bi bilo nemoguće. Kontinuirano Integracija je potrebno zadržati tim u sync, tako da možete napraviti promjenu, a ne biti zabrinut integraciji sa drugim ljudima. Zajedno ove prakse mogu imati veliki uticaj na krivoj promjene. Setio sam se opet ovdje u ThoughtWorks. Uvođenje testiranje i kontinuirano integracije su imala značajno poboljšanje u odnosu na razvoj napor. Svakako dovoljno da ozbiljno dovode u pitanje XP tvrdnju da ti sve prakse da se veliki napredak.
Refaktorisanje ima sličan efekt. Ljudi koji refactor svoj kod na disciplinovano predlaže XP naći značajne razlike u njihovu efikasnost u odnosu na radio gubitnik, više ad-hoc restrukturiranja. To je svakako moje iskustvo kad me je Kent naučio da pravilno refactor. Na kraju krajeva, samo tako snažnu promjenu bi me motivisalo da napišem celu knjigu o tome.
Jim Highsmith, u svojoj odličnoj sažetak XP, koristi analogiju set vage. U jednoj ležište planirano dizajn, a drugi je pravljenja. U više tradicionalnih pristupa planirane dizajn dominira, jer pretpostavka je da ne možete kasnije predomisliti. Što su troškovi promjene onda snižava možete učiniti više od vašeg dizajna kasnije pravljenja. Planirani dizajn ne nestanu potpuno, ali sada postoji ravnoteža dva pristupa dizajnu za rad. Za mene je to izgleda kao da je prije pravljenja sam radio sve moj dizajn jednom rukom.
Ove omogućava praksa kontinuiranog integracije, testiranje, i pravljenja, pružaju novu sredinu koja čini evolucijski dizajn prihvatljivo. Međutim, jedna stvar mi još nismo shvatili je mjesto gdje je težište. Siguran sam da je, uprkos izvan utisak, XP nije samo test, kod, i refactor. Postoji prostor za dizajniranje prije kodiranja. Neke od ovih je pre nego što je bilo kodiranje, uglavnom se javlja u iteracija prije kodiranja za određeni zadatak. Ali postoji nova ravnoteža između up-front dizajn i pravljenja.
Vrijednosti Jednostavnost
Dva najveća okupljanja plače u XP-u su parole “Da najjednostavnije što može da rad” i “nećete da je to potrebno” (poznat kao YAGNI). Oba su manifestacije XP prakse jednostavan dizajn.
Način YAGNI se obično opisuje, kaže da ne treba dodavati kod danas koji će se koristiti samo mogućnost da je potrebna sutra. Na prvi pogled to zvuči jednostavno. Pitanje dolazi sa stvarima kao što su okviri, za višekratnu upotrebu komponenti, i fleksibilan dizajn. Takve stvari su komplikovane za izgradnju. Plaćate dodatni trošak up-front da ih graditi, u očekivanju da ćete dobiti natrag te troškove kasnije. Ova ideja izgradnje fleksibilnosti up-front vidi kao ključni dio efikasne dizajn softvera.
Međutim savjet XP je da ne graditi fleksibilan komponente i okvira za prvi slučaj da to treba funkcionalnost. Neka ovih struktura rasti kao što je potrebno. Da sam danas da se bavi toga, ali ne i množenje žele Novac klase onda graditi samo dodatak u klasu novca. Čak i ako sam sigurna da ću trebati množenja u sljedećoj iteraciji, i shvatiti kako je lako raditi, a mislim da će biti jako brzo da radim, ja ću ipak ostaviti do tog sljedećoj iteraciji.
Jedan od razloga za to je ekonomska. Ako moram da radi bilo koji posao koji se koristi samo za funkciju koja je potrebna sutra, to znači da gubim napor funkcije koje je potrebno da se uradi za ovu iteraciju. Plan za oslobađanje kaže šta treba da se radi na sada, radeći na druge stvari u budućnosti je u suprotnosti sa sporazumom programerima sa kupcem. Postoji rizik da priča ovo ponavljanje ne može obaviti. Čak i ako priča ovog iteracije a nisu u opasnosti da je na kupcu da odluče šta dodatni posao treba raditi – i to možda još ne uključuje množenje.
Ovaj ekonomski odvraća se pogoršava šansa da možda ne bude u redu. Međutim, neke možemo biti o tome kako ova funkcija radi, još uvijek možemo ga pogrešno – pogotovo što nemamo još detaljne zahtjeve. Rad na pogrešnom rješenje rano je još rasipno nego rade na pravo rješenje rano. I Xperts uglavnom smatraju da smo mnogo veće šanse da budu u pravu nego u pravu (i ja se slažem s tim sentiment).
Drugi razlog za jednostavan dizajn je to složen dizajn je teže shvatiti nego jednostavan dizajn. Stoga bilo kakva modifikacija sistema otežano strane dodao složenosti. Ovo dodaje trošak u periodu kada je dodao komplikovanije dizajn i kada je to bilo potrebno.
Sada ovaj savjet udara mnogo ljudi kao besmislica, a oni su u pravu da misle da. Pravo pod uslovom da li zamisliti što je to uobičajeno u svijetu razvoju gdje su omogućavanje prakse XP nije na mjestu. Međutim, kada je ravnoteža između planiranih i evolucijski dizajn mijenja, onda YAGNI postaje dobre prakse (i samo tada).
Da rezimiramo. Ne želite provesti napor dodavanjem novih mogućnosti koje neće biti potrebno dok se budućnost iteracije. A čak i ako je trošak je nula, i dalje ne želite dodati jer povećava troškove modifikacija čak i ako se ništa ne košta da se stavi u. Međutim, možete samo razumno ponašati na ovaj način kada koristite XP, ili neki sličan tehnika koja smanjuje troškove promjene.
Ono što na Zemlji je jednostavnost svakom slučaju
Dakle, mi želimo da naša kod da bude što jednostavnije. To ne zvuči kao da je to teško za raspravu, na kraju krajeva, koji želi da bude komplikovano? Ali, naravno, ovo dovodi do pitanja “šta je jednostavno?”
U XPE
- Pokreće sve testove
- No dupliranja
- Otkriva sve u namjeri
- Najmanji broj klasa ili metoda
Radi sve testove je prilično jednostavan kriterij. Ne dupliranje je prilično jednostavan, iako dosta programera trebaju smjernice o tome kako to postići. Nezgodna jedan ima veze sa otkrivajući namjerom. Šta to znači?
Osnovna vrijednost ovdje je jasno koda. XP pridaje veliki značaj na broj koji se lako čita. U XP “pametan kod” je termin zlostavljanja. Ali namjera otkriva kod nekih ljudi je drugog pameti.
U svom radu XP 2000. godine, Josh Kerievsky ističe dobar primjer za to. On gleda možda najviše javnosti XP kod svih – JUnit. JUnit koristi dekorateri dodati opcijske funkcionalnost test slučajeva, takve stvari kao što sinhronizacija konkurentnosti i serijski postavljen kod. Odvajanjem ovaj kod u dekorateri omogućava opće kod biti jasnije nego što bi inače bilo.
Ali morate da se zapitate da li je rezultat kod je veoma jednostavno. Za mene je to, ali onda sam ja upoznat sa Decorator obrazac. Ali za mnoge koji nisu to baš komplikovano. Slično JUnit koristi pluggable metode koje sam primijetio većina ljudi u početku naći ništa, ali jasan. Dakle, može se zaključiti da je JUnit dizajn je jednostavniji za iskusne dizajnere, ali komplikovanije za manje iskusne ljude?
Mislim da je fokus na otklanjanju dupliciranja, oba sa XP “Jednom i samo jednom” i Pragmatični Programerski
Nedavno sam bio uključen u tome nešto što može postati preko dizajniran. Dobila Refactored i neke fleksibilnost je uklonjen. Ali, kao jedan od developera rekao “to je lakše refactor preko dizajna nego što je refactor ne dizajn”. To je najbolje da bude malo jednostavnije nego što je potrebno da bude, ali nije katastrofa da je malo složeniji.
Najbolji savet koji sam čuo na sve ovo dolazi iz Uncle Bob (Robert Martin). Njegov savjet je da se ne zamarajte o tome šta je najjednostavniji dizajn. Na kraju krajeva možete, treba, i da li će refactor kasnije. Na kraju spremnost da refactor je mnogo važnije od znajući šta najjednostavnije stvar je odmah.
Da li Refaktorisanje Violirati YAGNI?
Ova tema je došao na XP mailing listu nedavno, i to je vrijedno izvlači kao gledamo ulogu dizajna u XP.
U osnovi je pitanje počinje sa stanovišta da pravljenja treba vremena, ali ne dodaje funkciju. Budući da je svrha YAGNI je u tome što bi trebalo da dizajnira za sadašnju ne za budućnost, je li to kršenje?
Poenta YAGNI je da ne dodati složenost koja nije potrebna za tekuću priče. Ovo je dio prakse jednostavnog dizajna. Refaktorisanje je potrebno da zadrži dizajn kao jednostavan kao možete, tako da bi trebalo refactor kad god shvatite možete napraviti jednostavnije stvari.
Jednostavan dizajn i eksploatiše XP prakse i je također omogućava praksu. Samo ako imate testiranje, kontinuirano integracije i pravljenja možete li efikasno praktikuju jednostavan dizajn. Ali, u isto vrijeme zadržavajući dizajn jednostavan je od suštinskog značaja za čuvanje stana kriva promjene. Bilo koji nepotrebnih složenosti čini sistem teže promijeniti u svim pravcima, osim onaj koji vam predvidjeti sa složenom fleksibilnost te u. Međutim, ljudi nisu dobri u predviđanju, tako da je najbolje da se borim za jednostavnost. Međutim, ljudi neće dobiti najjednostavniji stvar prvi put, tako da je potrebno da refactor kako bi se približili cilju.
Obrasci i XP
Primjer JUnit me dovodi neminovno u odgajanje obrasce. Odnos između obrazaca i XP je zanimljiv, a to je često pitanje. Joshua Kerievsky tvrdi da su obrasci pod-naglasio je u XP-u, a on čini argument elokventno, tako da ne želim da se ponovi to. Ali to je imati na umu da je za mnoge ljude obrasce čini u sukobu na XP-u.
Suština ovog argumenta je da obrasci često previše koristi. Svijet je pun legendarnog programer, svježe skinuo prvom čitanju GOF
Jedna od teorija ovoga je da su snage jednostavnog dizajna će vas dovesti u obrasce. Mnogi refaktorisanih ovo eksplicitno, ali i bez njih tako što ćete pratiti pravila jednostavnog dizajna ćete doći do obrasce, čak i ako ih ne već znaju. To može biti istina, ali da li je zaista najbolji način da se to uradi? Sigurno da je bolje ako znate otprilike kuda ideš i imam knjigu koja vam mogu pomoći kroz pitanja, umjesto da sve to sami izmisliti. Ja svakako i dalje posegnuti za GOF kad god mi se uzorak dolazi u. Za mene je efikasan dizajn tvrdi da moramo znati je cena uzorak vredi platiti – to je vlastitu vještinu. Isto tako, kao što Joshua predlaže, moramo biti više upoznati o tome kako da se olakša u obrazac postupno. U tom smislu XP tretira način na koji koristimo obrasce drugačije na način na koji neki ljudi ih koriste.
Ali čitajući neke mailing liste Imam jasan osjećaj da mnogi ljudi vide XP kao obeshrabrujući obrasce, uprkos ironija da je većina zagovornika XP bili vođe obrazaca pokreta previše. Da li je to zbog toga što su vidjeli izvan obrasce, ili zato što obrasci su tako ugrađeni u svoje razmišljanje da više ne to shvatiti? Ne znam odgovore za druge, ali za mene obrasce i dalje su od vitalnog značaja. XP može biti proces za razvoj, ali obrasci su okosnica dizajn znanje, da je vrijedan bez obzira na proces može biti. Različiti procesi mogu koristiti obrasce na različite načine. XP naglašava kako ne koristite obrazac sve dok je to potrebno i razvija svoj put u obrazac pomoću jednostavnog implementacije. Ali obrasci su ipak ključni dio znanja da steknu.
Moj savjet XP-e koristeći obrasce bi bilo
- Uložiti vremena za učenje o obrascima
- Koncentrirati o tome kada će primijeniti obrazac (ne prerano)
- Koncentrirati o tome kako su prve sprovele obrazac u svom najjednostavnijem obliku, zatim dodajte složenosti kasnije.
- Ako stavite obrazac u, a kasnije shvatiti da se ne vuče svoje težine – ne boj se da ga ponovo.
Mislim XP Treba naglasiti učenje o obrascima više. Nisam siguran kako bih uklopiti to u praksi XP, ali siguran sam da Kent može smisliti način.
Raste arhitektura
Šta se podrazumeva od strane softverske arhitekture? Za mene je pojam arhitektura prenosi pojam od osnovnih elemenata sistema, komade koje je teško promijeniti. A temelj na kojem treba biti izgrađen do kraja.
Koja je uloga arhitekture igrati kada koristite evolucijski dizajn? Opet XPS kritičari navode da XP ignoriše arhitektura, da trasa XP je da se ide brzo kod i vjerovati da pravljenja koji će riješiti sva pitanja dizajna. Zanimljivo je da su u pravu, a to može biti slabost. Svakako najagresivniji XP-e – Kent Beck, Ron Jeffries, i Bob Martin – stavljaju sve više i više energije u izbjegavajući napred arhitektonski dizajn. Nemojte stavljati u bazu podataka dok ne znam da ćeš to potrebno. Rad sa datotekama prvi i refactor baze podataka u toku kasnije iteracije.
Ja sam poznat po tome što je kukavički xper, i kao takav moram da se ne slažemo. Mislim da postoji uloga za širok arhitekturu polazište. Takve stvari kao navodeći rano o tome kako da sloj aplikacije, kako ćete interakciju s bazom podataka (ako treba), što pristup koristi za upravljanje web servera.
U suštini, mislim da su mnogi od tih područja su obrasci koje smo naučili tijekom godina. Kao što raste svoje znanje o obrazaca, trebalo bi da imate razumne prvi take kako da ih koriste. Međutim, ključna razlika je u tome se ne očekuje ove rane arhitektonski odluke biti postavljen u kamenu, odnosno tim zna da oni mogu pogriješilo u ranim odluke, i treba imati hrabrosti da ih popraviti. Drugi su rekli priču o jednom projektu koji, u neposrednoj blizini raspoređivanje, odlučio da više nisu potrebni EJB i ukloniti ga iz svog sistema. To je bio značajan pravljenja, to je učinjeno kasno, ali omogućavajući praksi je to ne samo moguće, ali isplati.
Kako bi to radili obrnuto. Ako ste odlučili da ne koriste EJB, da li bi bilo teže da ga dodati kasnije? Treba da na taj način nikada ne početi sa EJB dok ste pokušali stvari bez i našao ga nema? To je pitanje koje uključuje mnogo faktora. Sigurno rade bez kompleksa komponenta povećava jednostavnost i čini stvari idu brže. Međutim, ponekad je lakše iščupati tako nešto nego da ga stavim u.
Dakle, moj savjet je da počne procjenom što je vjerovatno arhitekture. Ako vidite veliku količinu podataka s više korisnika, samo naprijed i koristiti bazu podataka iz dana 1. ako vidite složene poslovne logike, staviti u model domenu. Međutim, u poštovanja prema bogovima YAGNI, kada je u nedoumici pogriješilo na strani jednostavnosti. Također biti spremni da se pojednostavi svoj arhitekture čim vidite da je dio arhitekture se ne dodaje ništa.
UML i XP
Od svih pitanja koja sam se o mojoj povezanosti sa XP jedan od najvećih vrti oko moje povezanosti sa UML. Nisu dva nespojiva?
Postoji veliki broj bodova od nekompatibilnosti. Svakako XP de-naglašava dijagrama u velikoj mjeri. Iako je službeni stav je po uzoru na “koristite ih ako su korisni”, postoji jak podtekst “pravi XP-e ne rade sheme”. Ovo je ojačan činjenicom da su ljudi poput Kent nisu nimalo ugodno sa dijagramima, zaista nikada nisam video Kent dobrovoljno nacrtati dijagram softver ni u jednom fiksnom notaciji
Mislim da je problem dolazi iz dva odvojena uzroka. Jedan od njih je činjenica da su neki ljudi smatraju softver dijagrame pomoći i neki ljudi ne. Postoji opasnost da oni koji misle da su oni koji ne bi trebalo da radimo i obrnuto. Umjesto toga, treba prihvatiti da će neki ljudi koriste dijagrame, a neki neće.
Drugi problem je taj softver dijagrami imaju tendenciju da se u vezi sa teškoj proces. Takvi procesi provode puno vremena za crtanje dijagrama koji ne pomažu i zapravo može uzrokovati štetu. Tako da mislim da ljudi treba savjetovati kako da koriste dijagrame dobro i izbjeći zamke, a ne poruku “samo ako morate (izneveriti)” koja obično dolazi iz Xperts.
Evo moj savjet za korištenje dijagrama dobro.
Prva imajte na umu ono što vi crtanje dijagrama za. Primarna vrijednost je komunikacija. Efektivna komunikacija znači odabirom važne stvari i zanemarujući manje važno. Ova selektivnost je ključ za dobro pomoću UML. Ne bi privukli svaki čas – samo važnih. Za svaku klasu, ne pokazuju svaki atribut i rad – samo važnih. Ne bi privukli slijed dijagrama za sve slučajeve korištenja i scenarija – samo … ti sliku. Čest problem sa zajedničko korištenje dijagrama je da ljudi pokušavaju da ih konačan. Kod je najbolji izvor sveobuhvatne informacije, kao što je kod najlakše da ostanu u sync sa kodom. Za sheme sveobuhvatnost je neprijatelj razumljivosti.
Uobičajena upotreba dijagrama je da se istraže dizajn prije nego što počnete kodiranja. Često ste dobili dojam da je takva aktivnost je nelegalno u XP, ali to nije istina. Mnogi ljudi kažu da kada imate ljepljive zadatak to je vrijedno da zajedno na prvo brzo dizajn sesije. Međutim, kada radite takve sesije:
- držati ih kratko
- ne pokušavaj da se obrati svim detaljima (samo važno one)
- tretiraju kao rezultat dizajna kao skica, a ne kao konačan dizajn
Posljednju tačku vrijedi širi. Kada radite neke up-front dizajn ćete neizbježno naći da su neki aspekti dizajna nisu u pravu, a ti otkriti tek ovo kad kodiranje. To nije problem s tim da se onda promijeniti dizajn. Problemi nastaju kad ljudi misle da je dizajn se radi, a onda ne uzimaju znanje koje su stekli kroz kodiranje i pokrenite ga natrag u dizajn.
Promjenu dizajna ne znači nužno mijenja dijagrama. To je sasvim razumno da bi privukli dijagrame koje će vam pomoći razumjeti dizajn, a zatim baciti dijagrama dalje. Crtanje im pomogli, i to je dovoljno da ih isplati. Oni ne moraju postati stalni artefakata. Najbolji UML dijagrami nisu artefakti.
Dosta XP-e koristi CRC kartice. To nije u sukobu sa UML. Ja koristim mješavinu CRC i UML cijelo vrijeme, koristeći god tehnika je najkorisniji za posao na dohvat ruke.
Još jedna upotreba UML dijagrama je u toku dokumentacije. U svojoj uobičajenoj formi to je model koji se nalaze na slučaj alat. Ideja je da je održavanje ove dokumentacije pomaže ljudima da rade na sistemu. U praksi se često ne pomaže uopće.
- to traje predugo zadržati dijagrama do danas, tako da padaju u raskoraku sa kodom
- oni su skriveni u CASE alata ili debeli vezivo, tako da niko ne gleda u njih
Dakle, savjet za tekući dokumentacije traje od ovih uočeni problemi:
- koristiti samo dijagrame koji možete zadržati do datuma bez uočljive bol
- Put dijagramima gdje su svi lako mogu da ih vide. Volim da ih postaviti na zid. Ohrabriti ljude da biste uredili zid kopiju olovkom za jednostavne promjene.
- Obratite pažnju na to da li ljudi ih koriste, ako ih ne bacaju.
Poslednji aspekt korištenja UML je za dokumentaciju u primopredaje situaciji, kao što je jedna grupa preda drugom. Ovdje XP Stvar je u tome da proizvodi dokumentacija je korisnik priča kao i svaki drugi, i na taj način svoje poslovanje vrijednost određuje kupac. Opet UML je korisno ovdje, pružajući dijagrami su selektivni da pomogne komunikaciju. Imajte na umu da je kod spremište detaljnih informacija, dijagrami djelovati da se sumiraju i istakne važna pitanja.
Na metafora
U redu, možda to i reći javno – Još se nisam snasao ove metafore stvar. Vidio sam da radi, i dobro rade na projektu C3, ali to ne znači da sam imao pojma kako se to radi, a kamoli kako objasniti kako se to radi.
XP praksa metafora izgrađen na Ward Cunninghams pristup sistema imena. Stvar je u tome da si došao s dobro poznatim set imena koja djeluje kao vokabular da razgovaramo o domenu. Ovaj sistem imena igra u način na koji ime klase i metode u sistemu
Sam izgradio sistem imena izgradnjom konceptualnog modela domene. Ja sam to učinio sa stručnjacima domena koristeći UML ili njegovog prethodnika. Našao sam da morate biti oprezni sa ovim. Potrebno je da se drže minimalni jednostavan skup notacije, i morate čuvati protiv puštajući sve tehničke probleme puzanje u model. Ali ako to otkrio sam da možete koristiti za izgradnju vokabular domena koje stručnjaci domena može razumjeti i koristiti za komunikaciju s programerima. Model ne odgovara klasi dizajnira savršeno, ali to je dovoljno da daju zajedničku terminologiju na cijelu domenu.
Sad ja ne vidim ni jedan razlog zašto je ovo rečnik ne može biti metaforički jedan, kao što je C3 metafora koji su se pretvorili platnom spisku u fabriku traci. Ali isto tako ne vidim zašto zasniva svoj sistem imena na vokabular domena je bilo tako loša ideja. Niti sam sklon da napusti tehniku koja radi dobro za mene da dobije sistem imena.
Često ljudi kritikuju XP na osnovu toga što vam je potrebno barem neki obris dizajn sistema. XP-e često odgovoriti odgovor “to je metafora”. Ali i dalje ne mislim da sam vidio metafora objasnio na uvjerljiv način. Ovo je pravi jaz u XP i onaj koji je XP-e treba da sredimo.
Da li želim biti arhitekta kad odrasteš?
Za veći deo prošle decenije, pojam “softver arhitekt” je postao popularan. To je pojam koji je teško osobno mi koristiti. Moja supruga je strukturalni inženjer. Odnos između inženjera i arhitekata je … zanimljivo. Moja omiljena je “arhitekti su dobri za tri B: grmlje, ptice sijalice”. Pojam je da arhitekti dolaze sa svim ovim prilično crteže, ali to je inženjera koji moraju osigurati da oni zapravo mogu ustati. Kao rezultat toga sam izbjeći pojam softvera arhitekta, na kraju krajeva, ako svoju ženu ne može da me tretiraš sa profesionalnim poštovanjem kakve šanse da stojim sa nekim drugim?
U softveru, pojam arhitekta znači mnogo stvari. (U softveru svaki izraz znači mnogo stvari.) U principu, međutim prenosi određenu težinu za, kao “Ja sam ne samo puki programer – Ja sam arhitekta”. To može prevesti u “Ja sam arhitekta sada – Ja sam previše važno da radi bilo koji programiranje”. Pitanje onda postaje jedno od toga da li odvajanje sebe od svakodnevnih programiranja napor je nešto što bi trebalo učiniti kada želite da ostvare tehničke vodstvo.
Ovo pitanje stvara ogromnu količinu emocija. Vidio sam ljude se jako naljuti na pomisao da oni nemaju ulogu više kao arhitekata. “Nema mjesta u XP za iskusne arhitekte” je često plače čujem.
Baš kao što u ulozi samog dizajna, ja ne mislim da je to slučaj da XP ne vrednuje iskustvo ili dobar dizajn vještine. Zaista mnogi od zagovornika XP – Kent Beck, Bob Martin, i naravno Ward Cunningham – su oni od kojih sam naučio mnogo o tome šta dizajn je oko. Međutim, to ne znači da je njihova uloga mijenja od onoga što mnogi ljudi vide kao ulogu tehničkog vodstva.
Kao primjer, ja ću citirati jedan od naših tehničkih lideri na ThoughtWorks Dave Rice. Dave je prošla kroz nekoliko života ciklusa i preuzela nezvanični plašt tehničkog vodstva, nakon pedeset osoba projekta. Njegova uloga kao lider znači provodi puno vremena sa svim programerima. On će raditi sa programer kada im je potrebna pomoć, on gleda oko sebe da vidi kome je potrebna pomoć. Značajan je znak gdje je sjedi. Kao dugoročni ThoughtWorker, mogao je dobro imati ured mu se sviđa. Je dijelio jedan za dok je kod Cara, menadžer u saopštenju. Međutim, u posljednjih nekoliko mjeseci preselio na otvoreno uvale gdje su programeri rade (koristeći otvorene “room rat” stil koji XP usluge.) Ovo je važno da ga, jer na taj način on vidi šta se dešava, a dostupan je za kreditiranje ruku gdje god je to potrebno.
Oni koji znaju XP će shvatiti da sam opisujući eksplicitne XP ulogu treneru. Zaista jedan od nekoliko igara sa riječima da je XP čini se da se zove vođenje tehničke figura je “trener”. Smisao je jasan: u XP tehnički vođstvo pokazuje uči programeri i pomaže im donose odluke. To je onaj koji traži dobre ljude vještina, kao i dobre tehničke vještine. Jack Bolles na XP 2000 prokomentarisao da je sada malo prostora za usamljenog majstora. Saradnja i nastava su ključevi uspjeha.
Na konferenciji za večeru, Dave i ja smo razgovarali sa vokalnim protivnik XP. Kao što smo razgovarali ono što smo radili, sličnosti u našem pristupu su prilično označena. Svi smo se dopao adaptivni, iterativni razvoj. Testiranje je bilo važno. Tako da smo bili zbunjeni na žestinom svoje protivljenje. Onda je došla njegova izjava, po uzoru na “zadnja stvar koju želim je moj programeri pravljenja i majmunisanja sa dizajnom”. Sada je sve bilo jasno. Konceptualni jaz je dodatno objašnjena Dave nakon toga rekao da me, “ako on ne vjeruje njegov programeri zašto ih zaposliti?”. U XP najvažnije iskusni programer može učiniti je proći na onoliko vještine kao što može kako bi što više junior programera. Umjesto arhitekta koji donosi sve važne odluke, imate trenera koji uči programerima da se važne odluke.
Preokretljivost
Na XP 2002 Enrico Zaninotto dao fascinantan govor da su razgovarali o tie-ins između agilnih metoda i lean proizvodnje. Njegov stav je bio da je jedan od ključnih aspekata oba pristupa je da su oni bavili složenost smanjenjem nepovratnost u tom procesu.
U ovom pogledu jedan od glavnih izvora kompleksnosti je nepovratnost odluka. Ako ne možete lako promijeniti vaše odluke, to znači da je manje važno da ih u pravu – što čini vaš život mnogo jednostavnije. Posljedica za evolucijski dizajn je da dizajneri treba razmišljati o tome kako mogu izbjeći nepovratnosti u svojim odlukama. Umesto da se dobije pravu odluku sada, tražiti način da ni odložiti odluku kasnije (kada ćete imati više informacija) ili donijeti odluku na takav način da ćete biti u mogućnosti da se preokrene kasnije bez previše poteškoća.
Ova odlučnost da podrži reverzibilnost je jedan od razloga zbog kojeg agilnih metoda stavio mnogo naglasak na sistemima kontrole izvornog koda, i stavljanja svega u takav sistem. Dok se ovo ne garantuje reverzibilnosti, posebno za čeznuo-živio odluke, on ipak pruža temelj koji daje povjerenje u tim, čak i ako se rijetko koriste.
Dizajniranje za reverzibilnost podrazumijeva proces koji čini greške pojavi brzo. Jedan od vrijednosti iterativnog razvoja je da brze iteracija omogućiti korisnicima da vide sistema koji se razvija, a ako je napravio grešku u zahtjevima može se uočiti i fiksni prije trošak pričvršćivanja postaje zabrane. Ovaj isti brzog uočavanje je također važno za dizajn. To znači da morate postaviti stvari tako da potencijalna područja problem se brzo testirali da vide šta stigne pitanja. To također znači da je vrijedno radi eksperimente da vidi kako je teško budućih promjena može biti, čak i ako zapravo ne bi sada stvarne promjene – efektivno radi baca prototip na grani sistema. Nekoliko timova su izvještavanje isprobavanje budućnost promjene rano prototip režimu da vidi koliko je teško bi bilo.
Volja za dizajn
Dok sam koncentriran dosta tehničke prakse u ovom članku, jedna stvar koja je vrlo lako izostaviti je ljudski aspekt.
Kako bi se raditi, evolucijski dizajn treba sila koja pokreće da konvergiraju. Ova sila može doći samo od ljudi – neko u timu mora imati odlučnost kako bi se osiguralo da je kvalitetan dizajn ostaje visok.
Ta volja ne mora doći od svih (iako je lijepo ako se radi), obično samo jednu ili dvije osobe u timu preuzeti odgovornost vođenja dizajna cjelini. Ovo je jedan od zadataka koje obično spada pod termin ‘arhitekta’.
Ova odgovornost znači zadržavanje konstantan na oku osnovni kod, u potrazi za vidjeti ako postoje područja to su sve u neredu, a zatim uzimanje brze akcije da ispravite problem prije nego što izmakne kontroli. Vratar dizajn ne mora biti onaj koji to popravlja – ali oni moraju osigurati da se fiksira za nekog.
Nedostatak volje za dizajn čini se da je glavni razlog zašto je evolucijski dizajn može propasti. Čak i ako su ljudi upoznati sa stvari koje sam govorio u ovom članku, bez da će dizajnirati neće održati.
Stvari koje je teško refactor u
Možemo koristiti pravljenja da se bavi svim odlukama dizajn, ili postoje neka pitanja koja su toliko sveprisutni da su teško dodati kasnije? U ovom trenutku, XP ortodoksija je da su sve stvari lako dodati kad ih trebate, tako YAGNI uvijek se odnosi. Pitam se da li postoje izuzeci. Dobar primjer nečega što je kontroverzna dodati kasnije je internacionalizacija. Da li je to nešto što je takva bol da dodate kasnije da treba početi s tim odmah?
Nisam mogao lako zamisliti da postoje neke stvari koje bi spadaju u ovu kategoriju. Međutim, realnost je da i dalje imamo vrlo malo podataka. Ako imate nešto dodati, kao što su internacionalizacija, kasnije vrlo si svjestan napora je potrebno da to učini. Ti si manje svjestan napor da bi zapravo su se, iz nedelje u nedelju, da ga stavim u i održavati ga prije nego što je zapravo potrebno. Također ti si manje svjesni činjenice da možda i dobili to pogrešno, a time i potrebno da malo pravljenja u svakom slučaju.
Dio opravdanosti YAGNI je da su mnogi od tih potencijalnih potreba završiti ne potrebno, ili barem ne na način na koji biste očekivali. Od njih ne radi, vi ćete uštedjeti mnogo truda. Iako neće biti napor potreban da refactor jednostavno rešenje u ono što vam zapravo treba, ovo pravljenja će vjerovatno biti manje posla nego izgradnju svih upitna funkcije.
Još jedno pitanje koje treba imati na umu u ovom je da li znam kako se to radi. Ako ste učinili internacionalizacije nekoliko puta, onda ćeš znati obrasce trebate zaposliti. Kao takav si veće šanse da bude kako treba. Dodavanje anticipirajući strukture je vjerojatno bolje da ste u tom položaju, nego ako ste novi problem. Dakle, moj savjet bi bio da, ako znate kako se to radi, ti si u poziciji da sudi troškove to rade sada to radi kasnije. Međutim, ako ste ne to i ranije, a ne samo niste u mogućnosti procijeniti troškove dovoljno dobro, ti si i manje šanse da to dobro. U tom slučaju trebalo bi da je dodati kasnije. Ako vam se dodati onda i da je bolno, verovatno ćete biti bolje nego što bi bio da si ga dodao rano. Vaš tim ima više iskustva, znate domenu bolje, i razumjeti zahtjeve bolje. Često u ovom položaju se osvrnete na to kako je lako bi bilo sa 20/20 vremenske distance. Možda je to bilo mnogo teže da ga dodajte ranije nego što mislite.
To se povezuje na pitanje o naručivanje priča. U planiranje XP
Sa svakom novom tehnikom da je prirodno da su njeni zagovornici su sigurni od svojih graničnih uslova. Većina XP-e su rekli da evolucijski dizajn je nemoguće za određeni problem, samo da otkrijete da je zaista moguće. To osvajanje ‘nemoguće’ situacije dovodi do povjerenje da su sve takve situacije mogu prevazići. Naravno, ne možete napraviti takvu generalizacija, ali do XP zajednice pogađa granice i ne uspije, ne možemo nikada biti sigurni gdje te granice leže, a to je pravo da pokuša gurnuti izvan potencijal granice koje drugi mogu vidjeti.
(U nedavnom članku Jim Shore raspravlja o nekim situacijama, uključujući i internacionalizacije, gdje potencijalni granice ispostavilo da ne bude prepreka nakon svega.)
Je dizajn događa?
Jedna od poteškoća evolucione dizajna je da je veoma teško reći da li dizajn se zapravo dešava. Opasnost od preplitanja dizajn sa programiranjem je da programiranje može dogoditi bez dizajn – to je situacija u kojoj Evolucijski Design odstupa i ne uspije.
Ako ste u razvojnom timu, onda osjetiti da li je dizajn se događa po kvalitetu baze koda. Ako je kod bazne postaje sve složeniji i teži za rad, ne postoji dovoljno dizajn uzimajući učinio. Ali, nažalost, to je subjektivna gledišta. Mi nemamo pouzdane metrike koji nam mogu dati objektivan pogled na kvalitetu dizajna.
Ako se ovaj nedostatak vidljivosti je teško za tehničku ljude, to je daleko više alarmantno za ne-tehnički članovi tima. Ako ste menadžer ili kupca kako vam mogu reći da li je softver je dobro osmišljen? Važno je da ti, jer će se loše dizajniran softver biti skuplji modificirati u budućnosti. Nema jednostavan odgovor na ovo, ali evo nekoliko naznaka.
- Poslušajte tehničke ljudi. Ako se žale na poteškoće donošenja promjena, onda uzeti takve pritužbe ozbiljno i dati im vremena da popravi stvari.
- Držati na oku koliko kod se baci. Projekat koji radi zdrav pravljenja će biti stalno brisanje loše kod. Ako se ništa ne uzimajući izbrisani onda je gotovo sigurno znak da nema dovoljno pravljenja događa – što će dovesti do degradacije dizajna. Međutim, kao i svaki metričkih to može biti zlostavljana, mišljenje dobre tehničke ljudi aduti bilo metričkih, uprkos subjektivnosti.
Tako da je dizajn mrtav?
Ne na bilo koji način, ali priroda dizajna promijenio. XP dizajn izgleda za sljedeće vještine
- A stalna želja da zadrži kod kao jasan i jednostavan kao moguć
- Refaktorisanje vještine tako da možete sa sigurnošću napraviti poboljšanja kad god vidim potrebu.
- Dobro poznavanje obrazaca: ne samo rješenja, ali i cijeneći kada ih koristiti i kako evoluirati u njima.
- Dizajniranje sa ciljem da se buduće promjene, znajući da odluke sada će se morati mijenjati u budućnosti.
- Znajući kako da komuniciraju dizajna do ljudi koji treba da ga razumiju, koristeći kod, dijagrami i iznad svega: razgovor.
To je zastrašujući izbor vještina, ali onda biti dobar dizajner je uvijek bilo teško. XP zapravo ne čini ništa lakše, barem ne za mene. Ali mislim da XP ne daju nam novi način razmišljanja o efikasan dizajn, jer je ponovo napravio evolucijski dizajn prihvatljivo strategije. I ja sam veliki fan evolucije – inače ko zna šta bi bilo?
