Ce este datoria tehnică și o puteți evita?

Dacă sunteți în dezvoltare de software, va trebui să faceți față datoriilor tehnice la un moment dat. Deci, pentru a răspunde la întrebarea din titlu ... nu, nu o puteți evita. Cu toate acestea, există pași pe care îi puteți lua pentru a minimiza efectele sale și pentru a vă asigura că nu scapă de sub control. Cel puțin prea rău.

Ce este datoria tehnică?

Datoria tehnologică, așa cum se numește uneori, este în esență costul pe care îl suportați în timp pentru a avea un cod imperfect. Modificările și actualizările la codul sursă au un cost, la fel ca adăugarea unui nou membru la echipa de dezvoltatori, adăugarea unei noi caracteristici sau remedierea erorilor și exploatările de corecție.

Pe măsură ce proiectul dvs. se extinde, baza de coduri se extinde și mai mulți oameni lucrează la acel cod, vocile și stilurile lor se vor ciocni ici și colo. Poate aveți un termen limită și o soluție mai puțin ideală este introdusă în codul sursă pentru a finaliza la timp. Poate că adăugați o componentă open-source pe care nu o înțelegeți complet să gestionați o caracteristică în loc să o codificați singură. Sau puteți schimba bibliotecile între versiuni (de la Backbone la React, de exemplu), dar totuși trebuie să sprijiniți oamenii care folosesc baza de cod moștenită pentru proiectele lor.

Absolut niciunul dintre aceste lucruri nu este rău . Nu pe cont propriu. Poate deloc. Dar, atunci când sunt adăugați împreună, datoria tehnică pe care o suportă va trebui să fie rambursată la un moment dat în viitor.

La un moment dat, poate fi necesară înlocuirea (sau bifurcarea) componentei open-source. Asta va costa timp și bani. În viitorul îndepărtat, va trebui să eliminați tot codul Backbone din proiect și să nu mai sprijiniți utilizatori vechi. Din nou, timp și bani. Patch-ul pe care l-ai făcut pentru a respecta un termen? Ei bine, în cele din urmă va fi anulat și va avea nevoie de o soluție mai permanentă. Timp și bani. Și veți avea noi membri ai echipei dvs. care revin prin vechiul cod pentru a face toate acestea, trebuind să înțeleagă codul și logica dezvoltatorilor anteriori. Timp. Bani.

Îl înțelegi.

În timp ce datoria tehnică este un termen abstract, adesea metaforic, costul datoriei tehnice este foarte real. Rambursarea acestuia are o valoare monetară și puteți urmări dobânda pe care o plătiți pentru aceasta în orele de lucru și în plățile de plată. Îl puteți vedea în linia de jos a dezvoltării tuturor software-urilor.

Puteți evita datoria tehnică?

Cum am mai spus ... nu chiar, nu. Veți acumula datorii tehnice în fiecare proiect pe care îl scrieți dacă reveniți vreodată la cod după lansarea acestuia. Cu toate acestea, dacă defalcați tipurile de datorii tehnice, le puteți minimiza și chiar contabiliza în proiectele dvs. Dacă luați în considerare datoria în prealabil, nu este diferit decât contractarea unui împrumut auto sau a unui credit ipotecar. Vă uitați la cost, dobândă și beneficii și apoi decideți dacă puteți / doriți să-l plătiți.

Să aruncăm o privire la câteva dintre exemplele pe care le-am discutat mai sus și să vedem dacă există o modalitate de a evita, minimiza sau absorbi costul.

Luând în considerare datoria tehnică cu scop

Când spunem datorii tehnice intenționate, ceea ce vrem să spunem este că echipa dvs. a luat decizii despre care știți că nu se încadrează în așa-numitele bune practici, nici pentru limba, nici pentru tipul de proiect la care lucrați. Am menționat mai devreme că este posibil să aveți un termen limită de îndeplinire. Și poate că acest termen este greu și rapid. Poate există 0% șanse ca acesta să fie schimbat sau mutat.

Acesta este momentul în care trebuie să luați în considerare contractarea unui împrumut și intrarea în datorii tehnice.

Ai într-adevăr trei opțiuni aici:

• Afișați software care este neterminat și buggy, dar nu faceți concesii pentru claritatea codului și logica
• Trageți caracteristici pe care nu le puteți reuși să le perfecționați, dar eliberați ceea ce aveți, cât mai bine scris
• Luați decizii de dezvoltare care să difuzeze un cod „suficient de bun” pentru a pune totul în funcțiune, dar va trebui probabil să fie abordat din nou mai târziu

A treia opțiune aici este adesea cea pe care o aleg oamenii. Asta duce la datorii tehnice. Și nu este nimic în neregulă cu asta. Pentru că ai luat decizia să o faci .

Rambursarea împrumutului unei datorii intenționate

Asigurați-vă că documentați deciziile din spatele alegerii de a parcurge această rută în codul dvs. Păstrați note despre ceea ce ați făcut față de soluția ideală. Și asigurați-vă că includeți cel puțin un fel de comentariu în codul sursă pentru a indica unde a fost implementată această soluție de luare a datoriilor (și, dacă știți, sistemele afectate din alte zone ale proiectului). Dacă nu faceți acest pas, adăugarea la proiect (chiar și în remedierile de erori și corecții, ca să nu mai vorbim de caracteristici noi sau o bază de cod extinsă) poate fi întârziată teribil prin găsirea unei soluții de patch-uri atunci când vă așteptați la o soluție completă.

Din nou, această soluție patchwork ar putea fi perfectă și nu vă va oferi niciodată probleme reale. Dar datoria tehnică este încă acolo și trebuie contabilizată.

Luând în considerare datoriile tehnice ale codului vechi

Un alt tip obișnuit de datorii tehnice este acela pe care WordPress îl acumulează acum foarte mult. WordPress poate rula pe PHP 5.x. Cu toate acestea, cea mai nouă actualizare le va spune utilizatorilor că trebuie să fie cel puțin PHP 5.6. Până la sfârșitul anului 2019, WP Core va necesita PHP 7.x. Cu toate acestea, prin împingerea cerințelor în sus, o mulțime de coduri vechi trebuie actualizate. Deoarece există încă cod PHP 5.x în pluginuri, teme și Core în sine.

Ca să nu mai vorbim de noul Block Editor. Este scris în JavaScript. Reacționează, în mod specific. Asta nu este nimic lângă PHP. De fapt, o mare parte din WordPress Core este re-scris în JavaScript, încetul cu încetul. Dar toate aceste JS trebuie să complimenteze și să se înțeleagă și cu PHP. Asumarea de noi tehnologii este excelentă și este necesară adoptarea de noi cerințe de versiune. Dar, făcând acest lucru, plătiți dobânzi pentru datoria tehnică inevitabilă pe care o aveți datorită acelui software existent de ceva vreme.

Rambursarea datoriilor codului vechi

Acesta este cam dur pentru că nu există o modalitate excelentă de a face acest lucru. Ați putea alege opțiunea nucleară și a face o rescriere completă de la capăt în noul limbaj / cadru / versiune (uitați-vă la ce am făcut între Divi 2 și Divi 3.0, mergând de la Backbone.js la React). Totuși, acest lucru nu rezolvă în totalitate problema datoriilor, totuși, deoarece încă mai aveți oameni care folosesc biblioteca veche. La un moment dat, va trebui să renunțați la suportul pentru baza de cod moștenită. Ceea ce seamănă cu rambursarea împrumutului. Până când trebuie să-l scoți pe următorul.

Dacă aceasta nu este o opțiune (sau cea mai bună idee pentru dvs.), vă puteți asigura că nu vă bazați pe caracteristici specifice limbii sau versiunilor. Dezvoltatorii front-end trebuie să se ocupe de acest lucru tot timpul, deoarece unele browsere acceptă rapid funcții noi, în timp ce alții (Microsoft Edge / IE, tuse de tuse) s-ar putea să nu-l adopte niciodată. Vă puteți demonstra proiectele în viitor, respectând elementele de bază, care, la rândul lor, vor face numărul de modificări care trebuie abordate la actualizarea sau refacerea mai puțin decât ar fi altfel.

Luând în considerare mai mulți dezvoltatori în timp

Acesta este un fel de datorie tehnologică pe care echipele mari tind să o acumuleze în timp mai rău decât echipele mici de dezvoltare. Deși chiar și cei mici trebuie să-și facă griji. Vedeți, fiecare inginer software scrie cod diferit. Foarte rar veți avea două dezvoltatoare care rezolvă aceeași problemă cu exact același cod. Acestea pot îndeplini aceeași funcție, iar rezultatul final ar putea fi același, dar codul va fi scris în vocea autorului (așa cum puteți spune cine a scris postări aici, de exemplu, ca Jason, Nathan, Donjete și Toți am stiluri distincte). Codul nu este diferit.

Având în vedere acest lucru, logica poate avea uneori și voci diferite. Ceea ce un dev crede că este perfect clar, un alt dev se va uita și nu are nicio idee de ce codul face ceea ce face. Această problemă devine cu adevărat problematică atunci când autorul original nu mai este disponibil pentru consultare. Datoria tehnică acumulată de aceasta poate fi catastrofală. Dar există modalități de rezolvare.

Rambursarea datoriilor tehnice ale dispozitivelor vechi

Cea mai ușoară modalitate este de a angaja cei mai buni dezvoltatori posibil și să nu-i lăsați niciodată să părăsească compania dvs. Vreodată.

Deoarece acest lucru nu se va întâmpla în jur de 100% din timp, rambursarea acestei datorii poate fi atenuată puțin mai ușor decât ați putea crede. În primul rând, asigurați-vă că vă instruiți echipa de dezvoltatori pentru a le comenta codul. Și să o comentez bine. Ori de câte ori iau o decizie care ar putea fi considerată chiar de la distanță ambiguă de către altcineva, cereți-i să noteze de ce au făcut-o și cum funcționează funcția.

În plus, asigurați-vă că fiecare dezvoltator din echipa dvs. respectă un ghid de stil sau un set de standarde. WordPress Core are un set de standarde de codare care vor menține pluginurile, temele și contribuțiile Core în linie, astfel încât oricine mai vine mai târziu să nu aibă probleme cu acesta. Airbnb are un ghid de stil pentru React, care a fost adoptat ca un standard neoficial la nivel de industrie. Chiar și ghidurile și standardele interne de stil împiedică dezvoltatorii să meargă prea departe singuri, deoarece aceste tipuri de comitere nu vor fi combinate decât dacă sunt la îndemână.

Încheierea

Datoria tehnică este o problemă foarte reală. Este, de asemenea, o resursă foarte reală, dacă știi cum să o gestionezi. Prin posibilitatea de a decide când preluați datoria tehnologică și cum o rambursați, dezvoltarea dvs. poate merge mai repede și mai ușor decât altfel posibil. Și în acele vremuri în care preluarea acestei sarcini este inevitabilă, sperăm că ți-am dat câteva idei de strategii pe care le poți implementa pentru a o face mai puțin impactantă decât ar fi altfel.

Cum gestionați datoria tehnică în cadrul proiectelor și al echipelor de dezvoltatori?

Imagine prezentată de articol de Andrey Suslov / shutterstock.com