IT Industrija
🔥 Najčitanije
🔥 Najčitanije
Suština behaviour-driven developmenta (BDD) je u minimiziranju povratne sprege.
To je logični korak napred u evoluciji prakse razvoja softvera. U ovom članku ćete videti objašnjenje ovog koncepta i njegovog nastanka.
Vodopad
Ako ste developer ili inženjerski menadžer verovatno ste upoznati sa modelom vodopada, prepoznatljivom po ovom dijagramu:
Ono što je kasnije dobilo naziv “vodopad” je prvi put formalno opisao Vinston Rojs u svom radu iz 1970., “Managing the development of large software systems”. Preporučujem vam da pročitate ceo rad da biste razumeli ideju. Mnogi ljudi saznaju za ovaj model iz druge ruke i podrazumevaju da je proces sve vreme bivao predstavljan kao ultimativno rešenje. Međutim, Rojs je prepoznao da je ostavljanje faze testiranja za kraj procesa razvoja veliki problem:
I believe in this concept, but the implementation described above is risky and invites failure. […] The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. […] The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
Ovaj model se i dalje koristi za razvoj softvera u mnogim kompanijama širom sveta, iz različitih razloga. Vodopadimplicira pravolinijsku putanju, ali su u praksi prisutne povratne sprege između faza. Sva veća unapređenja modela su vremenom postizana skraćivanjem sprege sa ciljem da postane što predvidljivija. Na primer, ako pišemo program, želimo da znamo koliko će nam trebati dok saznamo kako funkcioniše. S druge strane, ako dizajniramo deo sistema, želimo da saznamo da li ga je zapravo moguće implementirati i verifikovati, i po koju cenu.
Stoga, kada pogledamo povratnu spregu, tražimo metode kojima bismo mogli da je minimiziramo. Na početku, naš cilj je da uklonimo očigledno suvišan rad. Kasnije, vidimo da smo u mogućnosti da optimizujemo i radimo stvari brže i bolje nego što smo mogli i da zamislimo dok smo radili stvari na stari način.
Prva optimizacija: Test-First programiranje
Prva optimizacija je nastala posmatranjem faza kodiranja i testiranja. U tradicionalnom quality assurance modelu razvoja programer prvo piše kod pa ga, na određeni način, predaje QA timu. Međutim, prođe nekoliko dana ili nedelja pre nego što dobije izveštaj da kod radi i da ostatak programa takođe radi. Često se desi i da postoje bagovi, tako da, iako smo mislili da je posao završen, potrebno je da se vratimo na programiranje i ispravimo sve greške.
Kako bismo skratili proces, krećemo da kodiramo i verifikujemo u isto vreme: napišemo neki kod i onda napišemo testove za njega. Testovi proizvode sjajan nusproizvod, set automatskih testova (automated test suite), koji možemo da pokrenemo svaki put kada želimo da potvrdimo svaki deo sistema za koji smo pisali test. Ubrzo počinjemo da priželjkujemo alat za testiranje koji obuhvata celokupni sistem, tako da možemo da radimo što je bezbednije moguće.
Povratna sprega kodiranja praćena testiranjem ipak dolazi po cenu nekog vremena, pa je zato invertujemo: krećemo da pišemo testove pre nego što napišemo ijednu liniju koda. Sprega tako postaje dosta mala i ne prođe mnogo vremena pre nego što shvatimo da pišemo kod koji je potreban za prolaz testova koje pišemo.
Ovo je test-first programiranje. Kada radimo po ovom principu, prvo koristimo testove koje pišemo da nam pomognu da ispravno “popunimo” implementaciju. Ovo smanjuje broj bagova, povećava produktivnost programera i pozitivno utiče na brzinu celog tima.
Test-Driven Development
Kada uvedemo kontinualnu spregu testiranja i kodiranja, i dalje dizajniranje programa radimo unapred. Koristimo test-first programiranje da osiguramo ispravnost koda, ali je tu i sprega u kojoj, radeći na implementaciji, možemo otkriti (uznemiravajuće kasno) da je dizajn težak za testiranje, nemoguć za kodiranje, ima loše performanse ili se naprosto ne uklapa u ostatak sistema.
Da bismo minimizovali ovu spregu, primenjujemo istu tehniku. Invertujemo je test-first programiranjem pre nego što počnemo da dizajniramo. Ili pak, testiramo, kodiramo i dizajniramo program istovremeno. Test utiče na kod, koji utiče na dizajn koji utiče na naš sledeći test.
Međutim, uskoro primećujemo da ovaj ciklus organski određuje naše ideje pri dizajniranju, i da implementiramo samo one delove dizajna koji su nam potrebni, na način koji i sam može lako da evoluira. Dizajn sada uključuje značajan korak refaktorisanja, koji nam omogućava da sa sigurnošću možemo manje da dizajniramo, naspram over-engineeringa. Drugim rečima, na kraju nam ostane taman onoliko dizajna i odgovarajućeg koda koji odgovaraju našim trenutnim zahtevima.
To je test-driven development (TDD). Kombinuje test-first programiranje sa dizajnerskim pristupom kroz kontinualno refaktorisanje koda. Pozitivni nus-efekti su sada pojačani: ne samo da imamo smanjeni broj bagova već i ne pišemo kod koji nam ne pomaže da implementiramo funkcionalnost. Ovo nadalje uvećava produktivnost tima, pomažući mu da izbegne greške u dizajnu koje je skuplje ispraviti kasnije nego otkriti ih na vreme.
Sledeći korak — Behavior-Driven Development
Pošto sada dizajniramo, kodiramo i testiramo sve u okviru jedne sprege, posmatramo i analizu. Pod analizom podrazumevam “razumevanje onoga što treba da napravimo”. Opet, želimo da optimizujemo spregu zato što nam uzima vreme. U praksi bi to značilo pripremanje spiska od desetak ili više funkcionalnosti i njeno prosleđivanje developerima, koji moraju da ih završe pre nego što možemo da krenemo dalje. Ovako često završimo u situaciji da smo implementirali funkcionalnosti koje nam ne trebaju. Ponekad i otkrivamo nove funkcionalnosti za koje nismo očekivali da će nam trebati, ili otkrijemo nešto novo o funkcionalnostima za koje znamo da nam trebaju.
Možemo primeniti istu tehniku i uvesti analizu u našu spregu. Sada “provozamo” funkcionalnost pre nego što probamo da implementiramo narednu. Vredi naglasiti da se vreme ovakvih ciklusa za developera meri satima, a ponekad i minutima, umesto u danima ili nedeljama.
Nakon što neko vreme konzistentno primenjujemo ovu tehniku, imaćemo tendenciju da razbijemo sve funkcionalnosti u najmanje jedinice i da ih konzistentno isporučujemo jedno po jednu. Bolje razumemo kako funkcionalnosti utiču jedna na drugu i otkrivamo mogućnost da reagujemo brže na izmene. Možemo da brže uočimo i odbacimo neželjene funkcionalnosti i prioritizujemo druge.
Time što i našu analizu radimo kroz pisanje testova na visokom nivou apstrakcije, bolje razumemo ponašanje sistema koji treba da izgradimo i odgovarajućeg načina na koji treba da ga dizajniramo i implementiramo. Istovremeno, od prvog dana proizvodimo alat za testiranje koji čini naš sistem konstantno proverljivim.
Ovo je behaviour-driven development. Štedi vreme i stejkholderima (vlasnicima biznisa) i razvojnom timu. Ranim postavljanjem pitanja, developeri istovremeno pomažu i sebi i menadžerima projekta da steknu dublje razumevanje toga šta je to što grade. Stejkholderi dobijaju rezultate predvidljivim tempom, i na svim funkcionalnostima se radi u sitnim koracima, procene su preciznije i nove funkcionalnosti se mogu odgovarajuće planirati i prioritizirati.
Još brže od toga
Ako pogledamo preostale faze izlistane na dijagramu vodopada, koje sve trebaju da se dese nezavisno od izabrane metodologije, možete se pitati da li se ista povratna sprega može primeniti i na njih. Odgovor je — da, naravno. Ali takve sprege su daleko šire od prostog dizajna i razvoja i uključivale bi ljude koji rade u vrlo različitim poljima, i ta tema je izvan opsega ovog članka. Bez obzira, pomenuću ih ovde ukratko.
Lean startup bi bio najsrodniji koncept koji objedinjuje prikupljanje zahteva, razvoj funkcionalnosti i marketinške aktivnosti tako da zatvori spregu otkrivanja onoga što startap treba da gradi. Proces je naravno nešto drugačiji u velikim poslovnim organizacijama, iako i one uče kako mogu da primene lean startup principe u mnogim projektima.
Spajanje BDD-a sa deploymentom i operacijama nas dovodi do šireg koncepta continuous deliveryja. Najvažniji procesi su continuous integration (CI) i continuouos deployment, koje lako možete konfigurisati za bilo koji projekat sa Semaphoreom.
Zaključak
Behavior-driven development je evoluirao iz raznih faza optimizovanja procesa razvoja softvera. Analizom, testiranjem, kodiranjem i dizajnom našeg sistema kroz jednu kratku povratnu spregu, dobijamo mogućnost da proizvedemo bolji softver, izbegavajući greške i nepotreban rad.
Česta je zabluda da je poenta TDD-a testiranje, i da je BDD, budući da potiče od TDD-a, samo još jedan pristup testiranju softvera. Ovo nije tako, iako su testovi skroz koristan nus-proizvod. BDD je holističan pristup razvoja softvera koji je izveden iz jedne jednostavne ideje: želimo da optimizujemo povratnu spregu u našem radu.
Generalno govoreći, nijedan od koraka koje nalaže primena BDD-a nije nužan da bi se pravio softver. Oni takođe zahtevaju vreme da bi se naučili i efektivno primenjivali. Međutim, dobijena vrednost, održivi proces koji rezultira kontinualnam proizvodnjom dobrog softvera, je vrlo vredna investicija.
Ovaj behavior-driven development članak vam prenosimo sa Semaphore Community sa zajedničkim ciljem da promovišemo dobre prakse domaćih developera i pospešujemo deljenje uspešnih praksi. Za sve nejasnoće i ne-elegantne izraze u članku je odgovorno uredništvo Startita koje je isti prevelo sa engleskog. Ovaj uradak je objavljen pod Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
***
A ako hoćete da saznate više o Rendered Textu, firmi iza Semaphorea, jednog od retkih domaćih globalno uspešnih proizvoda, možete videti u okviru njihove kompanijske stranice. Takođe, trenutno su oglasili dve otvorene pozicije na Startit Poslovima — prijavite se za softver inženjera, inženjera tehničke podrške ili ECMAScript developera.