Datoria tehnică crește mai repede când feedback-ul întârzie

Ați început vreodată un proiect nou cu o echipă de ingineri talentați, doar pentru a descoperi un an mai târziu că baza de cod s-a transformat într-un labirint? Sună cunoscut? Cel mai probabil, vinovatul nu este un spirit rău, ci feedback-ul întârziat. După cum scrie autorul articolului pe Dev.to, rădăcina datoriei tehnice nu constă în decizii proaste, ci în faptul că feedback-ul vine când trenul a plecat deja, iar șinele au fost demontate pentru fier vechi.

Imaginați-vă că asamblați un dulap IKEA, dar instrucțiunile vi se dau doar după ce ați strâns toate șuruburile și ușa atârnă strâmb. La fel și cu codul — dacă revizuirea vine după o săptămână, dezvoltatorul a uitat deja ce a făcut, iar corectarea necesită rugăciuni. Autorul observă pe bună dreptate că untimely feedback nu este doar o întârziere, ci un catalizator al datoriei tehnice. Fiecare minut de întârziere a unui comentariu crește costul remedierii exponențial.

Este deosebit de dureros pentru CI/CD: în timp ce feedback-ul atârnă în JIRA cu eticheta "în examinare", în master se îmbină deja trei hotfix-uri și un feature flag experimental. Și iată că nu mai știți ce este stricat și ce este intenționat. Autorul sugerează combaterea acestui fenomen printr-o cultură a "revizuirii rapide" și discuții asincrone în pull request-uri, astfel încât feedback-ul să nu devină arheologie.

Cum să preveniți datoria tehnică din cauza feedback-ului întârziat

• Stabiliți SLA pentru revizuire: de exemplu, nu mai mult de 4 ore pentru PR-uri mici.
• Folosiți programarea în perechi pentru secțiunile critice — acesta este feedback în timp real.
• Scrieți descrieri clare pentru PR, astfel încât revizorul să nu fie nevoit să ghicească.
• Nu acumulați revizuirile: mai bine una rapidă și superficială decât una perfectă, dar după o săptămână.

Comentariul studioului METABYTE: Și noi am trecut prin această etapă — când feedback-ul vine "după o lună, în vacanță", iar codul trebuie rescris de la zero. De aceea, în proiectele noastre folosim practici care ajută la identificarea problemelor înainte ca acestea să devină datorie tehnică. Iar dacă vă place să amânați revizuirile, imaginați-vă că codul vostru este o pizza și se răcește cu fiecare minut.