Datoria tehnică (cunoscută și sub denumirea de datorie de codificare ) este o metaforă a ingineriei software care se referă la problemele acumulate în codul sau arhitectura software asociate cu neglijarea calității în dezvoltarea software și care provoacă costuri suplimentare cu forța de muncă în viitor. Datoria tehnică este de obicei invizibilă pentru utilizatorii finali ai produsului, dar este asociată cu deficiențe de întreținere , testabilitate, înțelegere, modificare, portabilitate . Prin analogie cu datoria financiară , datoria tehnică poate fi supraîncărcată cu „ dobândă ” - făcând mai dificilă (sau chiar imposibilă) continuarea dezvoltării, timp suplimentar pe care dezvoltatorii îl petrec pentru schimbarea unui produs software, remedierea erorilor, întreținere etc. Deși o creștere a datoria tehnică este de obicei negativă afectează viitorul proiectului, poate fi și o decizie conștientă, de compromis dictată de circumstanțe.
În sine, codul rău nu este întotdeauna o datorie tehnică, întrucât prejudiciul („dobânda la datorie”) provine din necesitatea modificării codului în timp [1] .
Termenul de datorie tehnică este folosit în primul rând în legătură cu dezvoltarea de software, dar poate fi aplicat și altor domenii ale ingineriei.
Uneori termenul este folosit incorect, denotând cod moștenit care nu mai este acceptat , care este de proastă calitate și a fost scris de altcineva [1] .
Cauze comune ale datoriei tehnice (pot fi mai multe) [2] :
„Plățile de dobândă” apar atât în timpul dezvoltării locale, cât și în absența suportului tehnic din partea altor dezvoltatori de proiecte. Dezvoltarea continuă a proiectului poate crește costul lucrărilor de „rambursare a datoriilor” în viitor. Datoria tehnică este rambursată prin simpla finalizare a lucrărilor în curs.
Acumularea datoriilor tehnice este o cauză majoră a întârzierilor proiectelor. Este dificil de estimat cu exactitate câtă muncă trebuie făcută pentru a plăti datoria. O cantitate nedeterminată de lucrări în desfășurare este adăugată la proiect cu fiecare modificare. Termenele limită „ard” atunci când proiectul ajunge să înțeleagă că există încă mult mai mult lucru în derulare (datorii) decât timp pentru a-l finaliza. Pentru a avea programe de lansare previzibile, echipa de dezvoltare trebuie să limiteze volumul de lucru realizat la un nivel care să minimizeze cantitatea de lucru în curs (datoria tehnică).
În timp ce Legea creșterii complexității a lui Manny Lehman a demonstrat deja că dezvoltarea constantă a programelor le crește complexitatea și le degradează designul în timp ce se lucrează la ele, Ward Cunningham a făcut pentru prima dată comparația între complexitatea tehnică și datoria într-un raport din 1992:
În articolul său din 2004 „Refactoring with Patterns”, Joshua Kerievsky pledează pentru o comparație a costului abordării malpraxisului arhitectural, pe care el o descrie drept „datorie structurală” [5] .
Acțiunile care pot fi amânate includ documentarea, scrierea testelor, acordarea atenției comentariilor marcate „TODO”, combaterea compilatorului și avertismente despre analiza codului static . Alte cazuri de datorii tehnice includ o bază de cunoștințe care nu este împărtășită în cadrul unei organizații și un cod prea complex pentru a fi schimbat cu ușurință.
În software-ul open source, întârzierea transmiterii modificărilor locale la proiectul principal este o datorie tehnică. .