Scriu acest articol, pentru că am văzut ecuația "cod murdar = bani pierduți" de prea multe ori. Articolul este scris atât pentru audiența tehnică, cât și pentru cea non-tehnică din industria IT. Voi face o introducere scurtă și la obiect despre codul curat și cum influențează pozitiv aspectele financiare ale unui produs.
"În știința calculatoarelor, codul sursă este orice colecție de instrucțiuni pentru calculator (posibil cu comentarii) scrise folosind un limbaj de calculator citibil de către om, de obicei ca și text. Codul sursă al unui program este conceput special pentru a facilita munca programatorilor, aceștia specificând acțiunile ce trebuie îndeplinite de un calculator, cel mai adesea prin cod sursă" - Wikipedia
Iată niște căi posibile de a scrie cod sursă: shell scripting, SQL, C#, java, C, Python.
În paragraful de mai sus, am subliniat cuvântul "facilita", pentru că reprezintă un concept cheie în a produce cod curat.
Dar ce este "cod curat"? Cod curat este codul care: se citește foarte ușor, e facil de schimbat, scoate la suprafață deciziile de design, e foarte bine protejat de o suită de teste, e plăcut de modelat și lista poate continua. Simplu spus, codul curat este cod foarte ușor de întreținut.
Programatorul care scrie cod curat, "facilitează" munca altor programatori ce îl vor modifica.
În practică, situația e foarte diferită de cele descrise mai sus. Vedem cod care e o dezordine generală, care face foarte dificilă chiar și adăugarea unei mici funcționalități la sistem fără a fi nevoie de a petrece nenumărate ore de citit și rulat în debug printr-un teritoriu necunoscut. Există nenumărate sisteme, în producție, care rulează pe milioane de linii de cod pe care nimeni nu vrea să le atingă de frică sau pentru că ar fi imposibil să genereze o contribuție pozitivă la business.
Iată câțiva dintre indicatorii care arată că avem de a face cu cod rău: nu există o separare clară a responsabilităților (clase, metode sau funcții imense), modularitate sărăcăcioasă (totul e interconectat), multe globale, teste rele sau în care nu putem avea încredere.
Toate aceste lucruri rele generează o datorie tehnică imensă.
"Datoria tehnică (cunoscută și sub numele de datoria design-ului sau datoria codului) este un neologism metaforic, ce se referă la eventualele consecințe ale unei arhitecturi sărăcăcioase sau care evoluează, și la dezvoltarea de software. Datoria poate fi considerată munca ce trebuie făcută înainte ca o sarcină să fie considerată completă". - Wikipedia
Cu alte cuvinte, lăsând codul sursă într-o stare proastă (printre alte sarcini nelegate direct de codare), generăm datorie tehnică. De obicei, dobânda crește odată cu trecerea timpului, pe măsură ce codul "putrezește" (ca să îl citez pe Robert C. Martin). Această continuă creștere a datoriei tehnice rezultă într-o descreștere a calității produsului și o creștere a costului adăugării de funcționalitate. Un mod simplu de a măsura calitatea unui produs este formula DRE (defect removal efficiency - eficiența de înlăturare a defectelor):
DRE = Cantitatea de defecte găsite la testing / (Cantitatea de defecte găsite la testing + Cantitatea de defecte găsite de useri)
Exemplu:
DRE = 1 / (1 + 9) = 0.1 (10%) => DRE rău
DRE = 9 / (9 + 1) = 0.9 (90%) => DRE bunCapers Jones, un american specializat în metodologii pentru inginerie software, adesea asociate cu modelul pentru estimarea costului punctajului unei funcții, afirmă următoarele despre cuantificarea conceptelor legate de datoria tehnică:
"Există o măsurătoare mai veche, numită "costul calității" care a fost folosită la cuantificarea datelor existente de ani buni. Unul dintre lucrurile pe care le-am măsurat la IBM, ITT și multe alte companii, este cât costa cu adevărat atingerea unor nivele ale calității. Dați-mi voie să vă dau niște numere din industrie ca exemplu. Costul mediu pentru a implementa un oarecare software în S.U.A., este de aprox. 1000$ per punct funcțional și, în timpul developmentului, este aprox. jumătate - 500$ per punct funcțional, reprezintă costul găsirii și reparării defectelor. Odată ce soft-ul este pus în producție, în primul an, companiile cheltuiesc aprox. 200$ per punct funcțional ca să găsească și să repare defecte și, mai apoi, cheltui aprox. 250$ per punct funcțional ca să adauge specificații și îmbunătățiri. După cinci ani, dacă au procedat corect, vor scădea la aprox. 50$ per punct funcțional la repararea de defecte, iar ce cheltuie pe îmbunătățiri, rămâne constant. Deci, dacă au procedat corect, costul din primul an pentru repararea defectelor va scădea repede odată cu trecerea timpului. Pe de altă parte, dacă au făcut o mizerie, dacă nu au construit soft-ul bine și nu au fost atenți, vor cheltui 1200$ per punct funcțional pentru adăugarea de specificații noi și 600$ per punct funcțional pentru repararea defectelor înainte și 300$ după punerea lui în producție. Și în loc să scadă după cinci ani, costul va rămâne constant sau va crește. Deci, după cinci ani, pot ajunge să aibă un produs foarte rău, pe care cheltuiesc 350$ per punct funcțional, găsind și reparând defecte când ar fi trebuit deja să fi scăzut costul la 50$ per punct funcțional. De altfel, acest tip de informație - costul calității - este relativ bine cunoscut. [...] Cu cât aplicațiile sunt mai mari, procentajul de proiecte care sunt abandonate și nepuse în producție crește - la peste 10.000 de puncte funcționale, aprox. 35% dintre proiecte care sunt pornite, nu văd niciodată lumina zilei în producție. Cel mai des întâlnit motiv pentru care nu sunt puse în producție este pentru că au avut atât de multe defecte, încât nu au funcționat niciodată. Este o conexiune directă intre costul calității și executarea lucrurilor în mod greșit, sfârșind cu proiectele abandonate." - extrase dintr-un interviu din 22 ianuarie 2013
Conform celor spuse de Jones, datele ne arată că suntem foarte predispuși să plătim de șapte ori mai mult pentru mentenanța unui produs scris greșit. Iată date financiare directe! Aceasta ar trebui să fie un indiciu major pentru atât cei care investesc, cât și pentru cei care scriu (codează) un produs.
Aceasta, bineînțeles, înseamnă că scriind soft de calitate este mai ieftin. Așadar, pentru că la temelia produselor software stă codul: cod curat = bani în buzunar!
de Ramona Suciu
