Datoria tehnică (denumită adesea după termenul din sau ) este o descriere cantitativă de a costurilor suplimentare de întreținere a unui sistem, derivate din alegerea unor soluții rapide în faza de proiectare sau dezvoltare. Soluțiile rapide pot accelera dezvoltarea pe termen scurt, dar rabatul de la calitate rezultat poate crește costurile viitoare dacă este lăsat nerezolvat. Termenul este folosit adesea în domeniul tehnologiei informației și mai ales în dezvoltarea de software, dar este aplicabil în multe domenii, în special în inginerie.

Denumirea face aluzie la datoriile monetare, dar conceptul este diferit, deși funcționează în aceeași manieră. Acumularea oricărui fel de datorie complică în general îndeplinirea obiectivelor din viitor. Spre deosebire de datoria monetară, cea tehnică este adesea acumulată fără intenție și în necunoștință de cauză. Factorul primar este cedarea la presiunile de a minimiza timpul și costurile de dezvoltare, un aspect omniprezent în afaceri. Datoria tehnică se poate evalua de cele mai multe ori doar retroactiv (după ce efortul de dezvoltare a fost depus).

În dezvoltarea software, gestiunea datoriei tehnice este esențială pentru menținerea calității și sustenabilității pe termen lung. În unele cazuri, acumularea de datorie tehnică poate fi o alegere strategică pentru a îndeplini obiectivele imediate, cum ar fi livrarea unui sau un release rapid în condiții critice. Neprioritizarea și neadresarea datoriei tehnice poate avea însă ca rezultat reducerea mentenabilității, creșterea costurilor de dezvolttare și diverse riscuri pentru sistemele aflate în producție.

Datoria tehnică rezultă din decizii de proiectare și implementare care pot optimiza pe termen scurt, cu costul pierderii unei adaptabilități și mentenabilități viitoare. Aspectele care produc datorie tehnică pot fi descrise ca o colecție de construcții de implementare care ridică costurile unor modificări ulterioare, sau chiar le fac imposibile, cu impact primar asupra unor calități interne ale sistemului, cum ar fi mentenabilitatea sau capacitatea de evoluție.

Origine Ward Cunningham a avansat în 1992 termenul . După ce a citit , Cunningham a gândit metafora datoriei pentru a-i explica șefului său nevoia de a refactoriza produsul financiar la care lucrau:A livra cod proaspăt scris este ca și cum ai lua datorii. Puțină datorie accelerează dezvoltarea, atâta vreme cât este plătită în scurt timp cu o rescriere.... Pericolul apare când datoria nu mai este plătită. Fiecare minut petrecut reparând un cod care nu e chiar bun contează ca dobândă la acea datorie. Întregi organizații inginerești pot fi frânate de datoriile produse de o implementare neconsolidată, orientată pe obiect sau altfel.Existaseră și alte concepte similare până atunci. În 1980, publicase o lege similară folosind o „metaforă din arhitectură” despre evoluția deteriorării produselor software. Legea lui Manny se enunță astfel: „pe măsură ce un program în evoluție este schimbat permanent, îi crește complexitatea ce reflectă structura ce se deteriorează, dacă nu se depune o muncă pentru a o controla și pentru a o reduce.”

Cauze Printre cauzele frecvente ale datoriei tehnice se numără:

Presiunea de a minimiza timpul de dezvoltare Aspect omniprezent în domeniu.

Caracteristici și modificări cerute neașteptat și slab definite Implementarea unor schimbări de ultim moment ale specificațiilor sau schimbări insuficient documentate sau testate,

Lacune de cunoaștere sau aptitudini Se pot manifesta ca lipsa de înțelegere a procesului, cunoștințe insuficiente, leadership tehnologic slab, mentoring inadecvat sau practici deficitare de .

Probleme în procesul de dezvoltare Soluții suboptime, cerințe insuficient detaliate, cerințe contradictorii pe ramuri paralele, refactorizări amânate, sau amânarea contribuțiilor către upstream.

Neconformarea cu practicile recomandate insuficientă, practici colaborative slabe, lipsă de asumare, rescrieri ale unor software-uri venite pe filieră de outsourcing, atenție inadecvată acordată calității codului, , lipsa , sau nealinierea la standarde (inclusiv cu ignorarea frameworkurilor standard din industrie).

Consecințe Crescând costul mentenanței, datoria tehnică îngreunează pregătirea și conformarea la un program de release. „Plata dobânzilor” rezultă din munca incompletă, iar costurile de integrare escaladează din cauza schimbărilor din proiectul din . Creșterile de complexitate și cantitatea de fac să fie din ce în ce mai greu să se estimeze cu acuratețe efortul necesar, ceea ce duce la întârzieri, ratări de termene, și stress pe echipele inginerești, ceea ce poate duce la plecări ale angajaților, care agravează problema. Ducerea datoriei tehnice în producție crește riscul de căderi, de pierderi financiare, și de potențiale probleme legale din cauza nerespectării acordurilor de service. Refactoringul viitor devine mai riscant și mai costisitor, iar modificările în codul aflat în producție introduc șanse mai mari de perturbare. 

Neadresarea datoriei tehnice poate duce la scăderea productivității și la încetinirea livrării de caracteristici software noi. Efectele cumulative ale datoriei tehnice pot avea ca rezultat sisteme fragile pe care îmbunătățirile îndrăznețe sunt dificil de realizat. Dominarea schimbărilor incrementale, împreună cu amânările refactorizărilor critice, pot avea ca rezultat sisteme sub stress, cu design inconsistent, a căror performanță la utilizator se degradează, în timp ce funcționalitatea rămâne limitată și dezvoltatorii au dificultăți să mențină calitatea.

Planificare Kenny Rubin folosește următoarele categorii pentru a ajuta la gestionarea datoriei tehnice:

Găsită din întâmplare Echipa de dezvoltare nu știa că există datorie tehnică până când a fost expusă în cursul normal al lucrului la produs. De exemplu, echipa adăugă o nouă caracteristică a produsului și, pe parcurs, își dă seama că în cod a fost introdus cu ani în urmă un comportament lateral de către cineva care a plecat demult din echipă.

Cunoscută Știută de echipa de dezvoltare, dar a cărei vizibilitate a crescut în urma utilizării unei noi abordări.

Țintită Cunoscută și asumată pentru reparare de către echipa de dezvoltare.

Limitări Conceptul de datorie tehnică prezumă că un efort de dezvoltare excesiv de expeditiv are ca rezultat creșterea costurilor adiționale, și că aceste costuri pot fi evitate dacă la momentul efortului se iau decizii diferite. Există însă și alte considerente care au impact asupra costului potențial al deciziilor de dezvoltare pe termen scurt. De exemplu, dacă sistemul nu supraviețuiește suficient pentru a fi modificat pentru un release ulterior, atunci economiile făcute cu alegerile pe termen scurt sunt reale, întrucât nu va exista un cost viitor de dezvoltare. Evenimentele viitoare pot face ca designurile pe termen lung să fie inutile. Unelte și tehnici noi pot reduce costul reajustărilor viitoare, ceea ce face ca presupunerile actuale despre datoria tehnică să fie inexacte.

Vezi și

Note

Legături externe

Interviuri ale unor experți în datorie tehnică: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY Steve McConnell discută datoria tehnică Averting a "Technical Debt" Crisis de Doug Knesek David E. Boundy, Software cancer: the seven early warning signs, ACM SIGSOFT Software Engineering Notes, Vol. 18 Nr. 2 (aprilie 1993), Association for Computing Machinery, New York, New York, USA

Categorie:Arhitectură software Categorie:Metafore