Datoria tehnică este bine documentată pe internet. Este posibil să discutați despre asta în ceea ce privește îmbunătățirea sau refactorizarea codului, sau poate fi pur și simplu câteva elemente dintr-o listă lungă de activități. Mergând mai departe, vă voi împărtăși câteva experiențe din lumea reală pe care le-am avut cu datoria tehnică și vă voi oferi cele 10 reguli ale mele privind controlul și evitarea acesteia.

1. Folosește-l în avantajul tău

Datoria tehnică, precum datoria financiară, devine o problemă dacă este ignorată sau tratată ca inexistentă. În schimb, acceptați-l și mențineți-l ca pe un instrument.

În primul rând, înțelegeți că datoria tehnică este sănătoasă. Petrecerea timpului pe datorii tehnice ar putea însemna că nu îi ajutați clienții să rezolve noile provocări.

Datorii bune vs. datorii slabe: Obiectivul este de a echilibra compromisuri importante pentru a maximiza valoarea clientului, minimizând în același timp datoria. Acest stil de evaluare poate varia în cadrul aceleiași organizații.

2. Adaugă-l în cultura ta

Cultura companiei noastre include o revizuire colaborativă a codului pentru datoria tehnologică. Acest lucru ajută la răspândirea cunoștințelor în întreaga organizație și previne repetarea erorilor cu îmbunătățiri și produse viitoare.

Am stabilit o definiție amănunțită a ciclului „terminat”, în care, chiar dacă faceți concesii tehnice de-a lungul drumului, acestea sunt remarcate instantaneu, astfel încât produsul sau caracteristica nu este TERMINAT până când le-am abordat, chiar dacă asta înseamnă suntem veșnic în faza beta.

Infrastructura este o altă modalitate bună. Dacă costul pentru realizarea unei infrastructuri solide ca parte a platformei, pentru serviciile și completările viitoare, nu este prea scump, vom face acest lucru.

3. Reguli de documentare

Pierderea abilităților unei echipe IT competente poate fi destul de devastatoare pentru o corporație. Documentația solidă ajută la eliminarea și prevenirea datoriilor tehnologice. Pregătirea tehnicienilor noștri pentru a captura fiecare parte dintr-un bilet și orice anomalie și informații de configurare pe care le găsesc într-un mediu înainte de a trece mai departe oferă liderilor noștri tehnici o mai bună înțelegere a stării mediilor clienților noștri și care ar putea fi problema atunci când ceva nu merge bine.

O documentare mai bună și un mediu mai curat permit IT-ului să realizeze mai mult cu mai puțină forță de muncă, atât în ​​mod reactiv pentru a rezolva problemele, cât și în mod proactiv pentru a crește compania.

4. Angajează și ascultă Product Owner

Un proprietar de produs vă poate ajuta să opriți apariția unor noi datorii tehnice. Caracteristicile pe care utilizatorii sau clienții nu le folosesc nu ar trebui să fie menținute la același nivel de calitate ca și restul produsului; eliminați-le codul înainte de a crea datorii tehnice. Una dintre echipele mele a găsit recent o funcție pe care nici clienții noștri din trecut, nici cei actuali nu o folosesc. Mai rău, nu au existat verificări automate care să se potrivească. Nu numai că a cauzat probleme în timpul procesului de codificare, dar a fost nevoie și de mult timp pentru a verifica manual regresiile.

5. Organizațiile ar trebui să acorde prioritate datoriei tehnice

A nu fi un paznic de poartă sau un ciudat de control ar trebui să ajute. Nu ar trebui să fim niciodată conectați la cod. Organizațiile apreciază cultura. Prea mulți dezvoltatori lucrează în locuri în care nu există niciodată suficient timp pentru a o face bine, așa că o vom face din nou. Atitudinea este cheia. Dezvoltatorii sunt autonomi și nu le plac recenziile riguroase de cod, programarea perechilor etc., dar pot evita datoria tehnică.

Datoria tehnică încetinește performanța. Eliminarea acestuia accelerează și îmbunătățește codul. Recompensa personală este un alt avantaj. Odată ce inițiativele mele open-source decolează, participanți suplimentari se alătură. Codul meu este adesea rescris și optimizat mai bine decât aș fi putut anticipa înainte să devină cod spaghetti sau datorie tehnică.