Calitatea codului si durata de lucru
Am inceput sa scriu acest blog in urma cu aproximativ 1 an.
Un subiect mai delicat si de multe ori mai putin abordat de project manageri este relatia intre calitatea codului si timpul de dezvoltare.
Calitatea codului este o problema presanta pentru programatori, o problema cu care ne confruntam aproape zilnic.
In ce masura este asta relevant din punct de vedere economic?
Am construit un grafic incercand sa ilustrez mai bine aceasta problema:
Graficul l-am realizat acum aproximativ un an, cand am inceput sa scriu acest post si nu eram prea sigur de el.
Recent am inceput sa citesc “Clean Code” de Robert C. Martin. Cand citeam primul capitol in drum spre munca am ajuns la “The Cost of Owning a Mess”. Fata de mine care analizam “Code quality” vs “Development time”, in carte este “Productivity vs. time”:
Am fost foarte entuziasmat sa gasesc acest grafic similar. Cu alte cuvinte, daca avem un cod calitativ, timpul necesar pentru dezvoltare va fi mai mic. Cu cat codul este mai neorganizat, cu atat timpul de dezvoltare creste.
O varianta destul de populara pentru a rezolva problema timpului de dezvoltare este rescrierea intregii platforme. Rescrierea unei intregi platforme poate sa nu fie o alegere foarte buna din pricina costurilor. In carte este adus un argument in plus, daca cele doua platforme se dezvolta in paralel acestea pot sa nu se intersecteze niciodata, deci noua platforma sa nu ajunga niciodata in productie. Eu nu am vazut niciodata un plan atat de radical pus in practica fara sa se renunte la vechiul proiect, dar un caz care l-am vazut cu mai multe ocazii este acela cand platforma se reface si desi inceputul este deosebit de promitator si totul este aliniat cu cerintele, iar problemele vechi sunt abordate intr-un mod constructiv, vine un moment cand incep sa apara compromisurile. In general un compromis arhitectural nu vine niciodata singur, o data ce realizezi ca poti face compromisuri, iar echipa nu are remuscari este primul semn ca directia va ajunge sa fie gresita din nou.
O solutie partiala cred ca este desemnarea unui arhitect care sa stabileasca cursul dezolvarii, persoana care sa managerieze proiectul si sa nu-l lase sa scape de sub control.
O alta perspectiva este ca un bug cu cat este mai vechi cu atat va fi mai greu de rezolvat. De fapt, calitatea codului este un factor mai relevant. Cu cat un cod este mai bine scris cu atat este mai usor de inteles si modificat. Ca o actiune directa este de preferat sa existe un “conding standard”.
Problema cu un “coding standard” este ca nu orice programator este gata sa-l imbratiseze. In general programatorii seniori au tendinta sa faca lucrurile asa cum sunt obisnuiti. Nici un standard nu este perfect, dar chiar si imperfect, daca se regaseste in intreg codul, calitatea acestuia creste considerabil pentru ca te astepti la o anumita abordare, nu trebuie sa o ghicesti.
Morala este: aveti grija de cod si o sa aveti mai mult timp liber, pana la urma viata e scurta, nu merita sa o petreci facand debugging. 🙂