Cum gestionati Technical Debt?

Salutare Devforum,

Trebuie sa recunosc ca sunt putin frustrat pe tema “datoriei tehnice” si cred ca asta este unul din motivele pentru care Agile(sub orice forma) pe termen lung nu functioneaza. Mi-ar placea sa citesc si opiniile voastre despre asta.

Peste tot pe unde am lucrat am dat de aceeasi problema a datoriei tehnice care din punctul meu de vedere e tratata superficial din cauza ca facem Agile si mai intai trebuie implementat X, facut release in productie si vedem dup-aia la code-review(daca se mai face) cum imbunatatim. Si nu, testingul NU REZOLVA situatia. De parca e prima daca cand vezi totul verde in command line, mai primesti OK de la QA si peste 2 zile ai pe email 24 de exceptii de la ultimul feature implementat.

De ce cred ca Agile, in orice forma ar veni, va da fail pe termen lung din cauza datoriei tehnice? Pai toate proiectele Agile la care am luat parte erau ceva de genul:
Nu am idee ce o sa iasa la final, nici eu nici clientul nici product ownerul. Gradul de incertitudine este mare la inceput…si ma rog, OK, lucram toti in echipa la niste features, vedem ce iese, probam, raspundem la change cum zice unul din principii, A/B testing, stergem niste functionalitati ca sa introducem altele si tot asa. Dupa 1-2 luni daca ai noroc sa faci o retrospectiva o sa ai un moment din ala gen: “Daca stiam ce se doreste si unde se vrea sa se ajunga, cu siguranta o faceam altfel”.

Nu va “miroase” cunoscut? :smiley:

Apoi intervin constrains de tipul: “Ain’t nobody got time for that design and test shit” daca ai un business mai sensibil la problemele stakeholderilor sau “We must ship now and deal with consequences”, daca ai un business mai sensibil problemelor tale.

Dar oricum ai intoarce problema, in opinia mea atunci este momentul cand intram intr-o spirala negativa din care nu mai ai cum sa iesi pana cand ajungi cu proiectul ca in Broken windows theory si ori moare de tot ori te apuci sa il refaci.

Ma rog, eu accept ideea de datorie tehnica si cred ca face parte din proiect(oarecum) insa problema principala este ca ea trebuie gestionata oficial de companie sau echipa iar acest lucru nu se intampla sau se intampla doar pe hartie.

Ca un mic disclaimer, frustrarea me este generata de experienta mea in diferite proiecte cu echipe mai mici sau mai mari si de traiectoria mea laborala. Insa de aia scriu aici ca sunt curios si de experientele altora.
Eu am lucrat ca dezvoltator si in companii de produs si in companii de servicii. Cand am lucrat singur, intr-adevar, nu am avut problema datoriei tehnice :smiley: insa in rest, peste tot, fara nici un fel de discriminare, a fost la fel.

5 Likes

Din ce am citit cea mai buna varianta e sa monitorizezi si sa incerci sa tii sub control cat posibil technical debt-ul. Pentru asta ai nevoie de un tool extern care sa-ti identifice/masoare aceasta valoare gen http://www.sonarqube.org/
Odata configurat poti urmari progresul in timp si monitoriza nivelul datoriei. Fara suport din partea managementului nu vei putea implementa asa ceva deoarece implica anumite costuri.

Nu dau un raspuns direct, dar ma intereseaza subiectul si as vrea sa discutam pe seama lui.

Un prim raspuns la intrebarea: “Daca stiam ce se doreste si unde se vrea sa se ajunga, cu siguranta o faceam altfel” - Nimeni nu stia. Produsul la care ai ajuns are forma actuala tocmai datorita muncii imbricate cu gandirea si proiecatarea lui (avem un astfel un produs viu).

Un produs trebuie sa aiba un roadmap, chiar daca abordarea este agile. Cultura agile se invarte in jurul conceptului de produs minim viabil, astfel ca tot ce ai construit tu trebuie sa fie functional (ca nu il vei mai utiliza acel feature e altceva). Tehnical debt-ul nu este un feature al Agile-ului. Ideea de agile era ca atunci cand ai 3 directii: calitate, timp si cantatite (numar de feature-uri) sa tai din catitate nu din calitate (tehnical debt=0).

In experienta mea, tehnical debt-ul s-a tradus in

  • foarte mult rewriting . Atunci cand tehnical debt-ul s-a produs intr-un loc cu high dependancy. Costuri pe care cu greu si le poate asuma cineva
  • interventie de pomier - mai un fix, mai un script, mai un mic developement - Costuri acoperite de obicei de mentenanta produsului
  • folosire mai greoaie al produsului - Exemplu: utilziatorul trebuie sa completeze mereu un camp (in loc sa il ia din istoric). - Costul timpului pierdut apare la client

Nu am reusit sa implementez un sistem de cod review insa el pare singurul care ar trebui sa functioneze (cu ocazia asta ma gandesc sa fac un post separat sa vad cum as putea implementa un astfel de siste). Insa un cod review sistematic zi de zi, altfel nu conteaza. Exista o expresie: 10 linii de cod - propbleme gasite, 300 de linii de cod - e OK.

1 Like

Chiar acum lucrez la un proiect mai vechi (adaug funcționalități noi). Dacă aș fi luat în considerare strict cerințele clientului, funcționalitățile erau adăugate în câteva ore. În schimb, am ales să fac cât de mult refactor permite timpul; am deja aproape 20 de ore în care am eliminat warnings, am implementat (parțial) autoloader, am extras metode în mai multe clase aplicând SRP, am eliminat cod duplicat șamd. Pe scurt, am aplicat ce am învățat citind Modernizing Legacy Applications in PHP

Clientul nu a fost foarte încântat de acest lucru (timp și buget mai mare decât spera), dar a înțeles că mai devreme sau mai târziu oricum trebuie să trecem prin asta (tocmai pe exemplul ferestrelor sparte). Și dacă tot am avut mai mult timp la dispoziție pentru asta… de ce nu/? :smile:


Nu știu dacă rezolvă, dar cu siguranță ajută! Pentru moment am evitat să mă ating de logica prea complexă tocmai pentru că nu aveam teste (și mi-era frică să nu stric ceva). Chiar și așa, o modalitate stupid de simplă poate ajuta: faci un sha1 al output-ului, după care compari ce aveai înainte cu ce ai după refactor. (sigur, nu ajută foarte mult în cazul în care schimbi markup sau ai date dinamice, dar… e mai bine decât deloc)

1 Like

I kinda agree with this: http://www.agileoverflow.com/t/why-do-some-developers-at-strong-companies-like-google-consider-agile-development-to-be-nonsense/107

EDIT: revin si cu o opinie proprie :smile:

2 Likes

Ia uite ce face colegu’ @serbanghita peste două săptămâni :stuck_out_tongue:

Munca nu se termina dupa lansarea codului in productie, iar cu timpul, codul poate deveni o piedica in calea unor dezvoltari noi ulterioare. Cum facem sa scriem un cod cat mai testabil si mai usor de inteles pentru toata lumea? Cum platim “datoria” stransa in contul codului scris in graba? Cum ne motivam sa scriem unit teste si cum ii informam pe ceilalti despre necesitatea lor? Acestea sunt intrebarile la care vom raspunde pe parcursul primei sesiuni de “Code Quality”.

1 Like

Dor ce am dat peste articolul asta pe twitter (@sendgrid).

1 Like