Dragos Manac publica propriul top al minciunilor “de la tehnic”. Totusi, imi pare ca arunca prea usor vina in gradina “tehnicilor”.
Problema este de fapt a sistemului per ansamblu. Cam asta e viata unei cerinte tipice:
Se naste prematur in mintea clientului – care nu ii acorda nici cinci minute de gestatie.
Ajunge in inbox-ul managerului de proiect care ii da automat forward catre developer – doar nu e treaba lui sa vada despre ce e vorba si cum se leaga cu restul proiectului.
Developerul e obosit dupa o zi de alergat dupa un bug, ca doar nu-si pierde el timpul cu unit-teste. Cand vede cerinta, trage o injuratura in gand. Se uita cum se potriveste cu restul cerintelor, mai trage o injuratura in gand. Varsa o lacrima pentru structura desavarsita a codului lui care va trebui spurcata cu noua cerinta.
Apoi apare gestul reflex: reply cu o intrebare care nu lamureste cerinta (lamurirea ar cere efort mental) dar are darul de a pasa mingea in terenul managerului. Dupa un meci de vreo cateva ore pentru client, o ora-doua pentru manager si doua-trei zile de lucru pentru developer, produsele pot fi ordonate si dupa pret.
Ce ar fi rezolvat problema? 15 minute de rumegat cerinta initiala din partea clientului, 45 minute de lamurit detaliile din partea managerului de proiect, doua ore de implementat si creat teste automatizate din partea developerului.
A cui e vina? A tuturor. Mai mult decat atat, oricare dintre partile implicate poate rezolva problema. Clientul care stie ce vrea poate renunta la serviciile firmei care-i dezvolta solutia indata ce observa intarzieri nejustificate. Managerul poate lamuri cerintele stupide inainte de a ajunge la developeri; tot ei isi pot alege alti developeri. Developeri buni pot compensa management-ul prost punand intrebari pertinente; daca situatia e grava, isi pot gasi oricand alt job.
2 comments ↓
Nu mi-e clar cum reuseste unit testing sa faca toate lucrurile pe care i le atribui.
Programatorul din povestea ta zici ca alearga dupa un bug pentru ca n-are unit testing. Cine spune ca daca avea il gasea mai repede? Unit testing e o metoda formala si automatizata care te anunta cand apar (unele) bug-uri dar nu iti spune neaparat unde sunt.
Mai departe, se pare ca unit testing tine chiar loc de dezvoltare, pentru ca e dat ca solutie exclusiva. Sau poate te refereai tot la bug-ul ala dar te exprimi neclar.
Iar solutiile date de tine nu functioneaza pentru un motiv simplu: niciunul dintre actori nu realizeaza ca face ceva gresit. Unora le lipsesc cunostintele tehnice, altora human skills.
Unit testing-ul nu este un silver bullet pentru eliminarea bug-urilor, dar este de departe cea mai apropiata abordare pe care o avem. Unit testele nu iti pot spune unde este bug-ul dar iti pot sugera unde nu este. Asa ca, de obicei, un proiect care are un pachet solid de teste e mult mai usor de depanat.
Actorii vor realiza de acum problema, ca le-am zis eu :D
P.S. Comentariul e asezat. De ce a trebuit sa-l publici cu mail-ul b@c.com?
Leave a Comment