Cos'è il debito tecnico e puoi evitarlo?

Se ti occupi di sviluppo software, prima o poi dovrai affrontare un debito tecnico. Quindi, per rispondere alla domanda nel titolo... no, non puoi evitarlo. Tuttavia, ci sono dei passaggi che puoi adottare per ridurre al minimo i suoi effetti e assicurarti che non sfugga di mano. Almeno troppo male.

Cos'è il debito tecnico?

Il debito tecnologico, come viene talvolta chiamato, è essenzialmente il costo che si sostiene nel tempo per avere un codice imperfetto. Le modifiche e gli aggiornamenti al codice sorgente hanno un costo, così come l'aggiunta di un nuovo membro al team di sviluppo, l'aggiunta di una nuova funzionalità o la correzione di bug e gli exploit di patch.

Man mano che il tuo progetto diventa più grande, la base di codice si espande e più persone lavorano su quel codice, le loro voci e i loro stili si scontreranno qua e là. Forse hai una scadenza e una soluzione tutt'altro che ideale è stata inserita nel codice sorgente per finire in tempo. Forse aggiungi un componente open source che non comprendi appieno per gestire una funzionalità invece di codificarlo da solo. Oppure potresti cambiare le librerie tra le versioni (da Backbone a React, per esempio), ma devi comunque supportare le persone che usano la base di codice legacy per i loro progetti.

Assolutamente nessuna di queste cose è cattiva . Non da soli. Forse per niente. Ma una volta sommati, il debito tecnico che incorrono dovrà essere rimborsato ad un certo punto in futuro.

Ad un certo punto, potrebbe essere necessario sostituire (o eseguire un fork) quel componente open source. Ciò costerà tempo e denaro. In un lontano futuro, dovrai rimuovere tutto il codice Backbone dal tuo progetto e smettere di supportare gli utenti legacy. Di nuovo, tempo e denaro. Quella patch che hai fatto per rispettare una scadenza? Bene, alla fine verrà annullato e avrà bisogno di una correzione più permanente. Tempo e denaro. E avrai nuovi membri del tuo team che tornano indietro attraverso il vecchio codice per fare tutto questo, avendo bisogno di comprendere il codice e la logica degli sviluppatori precedenti. Tempo. Soldi.

L'hai capito.

Mentre il debito tecnico è un termine astratto, spesso metaforico, il costo del debito tecnico è molto reale. Il rimborso ha un valore monetario e puoi tenere traccia degli interessi che paghi su di esso in ore di lavoro e buste paga. Puoi vederlo nella riga inferiore di tutto lo sviluppo del software.

Puoi evitare il debito tecnologico?

Come ho detto prima... non proprio, no. Accumulerai un debito tecnico in ogni progetto che scrivi se torni al codice dopo il suo rilascio. Tuttavia, se scomponi i tipi di debito tecnico, puoi minimizzarlo e persino tenerne conto nei tuoi progetti. Se consideri il debito in anticipo, non è diverso dal prendere un prestito auto o un mutuo. Guardi il costo, gli interessi e i benefici e poi decidi se puoi/vuoi pagarlo.

Diamo un'occhiata ad alcuni degli esempi discussi sopra e vediamo se c'è un modo per evitare, ridurre al minimo o assorbire il costo.

Considerare il debito tecnico intenzionale

Quando diciamo debito tecnico intenzionale, ciò che intendiamo è che il tuo team ha preso decisioni che sai non rientrano nelle cosiddette migliori pratiche né per la lingua né per il tipo di progetto su cui stai lavorando. Abbiamo detto prima che potresti avere una scadenza da rispettare. E forse quella scadenza è dura e veloce. Forse c'è una probabilità dello 0% che venga modificato o spostato.

Questo è il momento in cui devi prendere in considerazione l'assunzione di un prestito e l'indebitamento tecnico.

Hai davvero tre opzioni qui:

• Pubblica software incompleto e difettoso, ma non fai concessioni per la chiarezza e la logica del codice
• Ottieni funzionalità che non riesci a perfezionare, ma rilascia ciò che hai scritto il più bene possibile
• Prendi decisioni di sviluppo che forniscano un codice "abbastanza buono" per far funzionare tutto, ma che probabilmente dovranno essere affrontate di nuovo in seguito

La terza opzione qui è spesso quella scelta dalle persone. Questo sta andando in debito tecnico. E non c'è niente di sbagliato in questo. Perché hai deciso di farlo .

Ripagare il prestito del debito intenzionale

Assicurati di documentare le decisioni alla base della scelta di seguire questa strada nel tuo codice. Prendi appunti su ciò che hai fatto rispetto a quale sarebbe la soluzione ideale. E assicurati di includere almeno una sorta di commento nel codice sorgente per indicare dove è stata implementata questa soluzione per l'assunzione di debiti (e se lo sai, i sistemi interessati in altre aree del progetto). Se non esegui questo passaggio, l'aggiunta al progetto (anche in correzioni di bug e patch, per non parlare di nuove funzionalità o di una base di codice ampliata) può essere orribilmente ritardata trovando una soluzione patchwork quando ti aspetti una soluzione completa.

Ancora una volta, quella soluzione patchwork potrebbe andare benissimo e non darti mai problemi reali. Ma il debito tecnico è ancora lì e deve essere contabilizzato.

Considerando il debito tecnico del codice legacy

Un altro tipo comune di debito tecnico è quello che WordPress sta accumulando molto in questo momento. WordPress può essere eseguito su PHP 5.x. L'ultimo aggiornamento, tuttavia, dirà agli utenti che deve essere almeno PHP 5.6. Entro la fine del 2019, WP Core richiederà PHP 7.x. Tuttavia, aumentando i requisiti, è necessario aggiornare molto vecchio codice. Perché c'è ancora codice PHP 5.x in plugin, temi e Core stesso.

Per non parlare del nuovo Block Editor. È scritto in JavaScript. Reagire, nello specifico. Non è niente vicino a PHP. In effetti, gran parte del Core di WordPress viene riscritto in JavaScript, a poco a poco. Ma tutto questo JS deve complimentarsi e andare d'accordo anche con il PHP. Affrontare nuove tecnologie è fantastico ed è necessario adottare nuovi requisiti di versioning. Ma in tal modo, stai pagando gli interessi sull'inevitabile debito tecnico che sostieni da quel software che esiste da un po' di tempo.

Ripagare il debito del codice legacy

Questo è un po' difficile perché non c'è un ottimo modo per farlo. Potresti prendere l'opzione nucleare e fare una riscrittura completa da zero nel nuovo linguaggio/framework/versione (guarda cosa abbiamo fatto tra Divi 2 e Divi 3.0, passando da Backbone.js a React). Tuttavia, questo non risolve ancora del tutto il problema del debito, poiché ci sono ancora persone che utilizzano la vecchia biblioteca. Ad un certo punto, dovrai abbandonare il supporto per la codebase legacy. Che è un po' come rimborsare il prestito. Fino a quando non dovrai eliminare il prossimo.

Se questa non è un'opzione (o l'idea migliore per te), puoi assicurarti di non fare affidamento su funzionalità specifiche della lingua o della versione. Gli sviluppatori front-end devono sempre occuparsene, poiché alcuni browser supportano rapidamente funzionalità nuove di zecca, mentre altri (Microsoft Edge/IE, tosse tosse) potrebbero non adottarlo mai. Puoi rendere i tuoi progetti a prova di futuro attenendosi alle basi, che, a loro volta, renderanno il numero di modifiche che devono essere affrontate durante l'aggiornamento o il refactoring meno di quanto sarebbe altrimenti.

Considerare più sviluppatori nel tempo

Questo è un tipo di debito tecnologico che i grandi team tendono ad accumulare nel tempo peggio dei piccoli team di sviluppo. Anche se anche i più piccoli devono preoccuparsene. Vedete, ogni ingegnere del software scrive il codice in modo diverso. Molto raramente avrai due sviluppatori che risolvono lo stesso problema con lo stesso identico codice. Possono svolgere la stessa funzione e il risultato finale potrebbe essere lo stesso, ma il codice sarà scritto nella voce dell'autore (proprio come puoi dire chi ha scritto post qui, ad esempio, come Jason, Nathan, Donjete e Ho tutti stili distinti). Il codice non è diverso.

Tenendo presente questo, a volte anche la logica può avere voci diverse. Quello che pensa uno sviluppatore è perfettamente chiaro, un altro sviluppatore guarderà e non avrà idea del perché il codice fa quello che fa. Questo problema diventa veramente problematico quando l'autore originale non è più disponibile per la consultazione. Il debito tecnico che ne deriva può essere catastrofico. Ma ci sono modi per gestirlo.

Ripagare il debito tecnico dei vecchi sviluppatori

Il modo più semplice è assumere i migliori sviluppatori possibili e non lasciare mai che lascino la tua azienda. Mai.

Dal momento che ciò non accadrà circa il 100% delle volte, ripagare questo debito può essere mitigato un po' più facilmente di quanto si possa pensare. Prima di tutto, assicurati di addestrare il tuo team di sviluppo a commentare il loro codice. E per commentarlo bene. Ogni volta che prendono una decisione che potrebbe anche lontanamente essere considerata ambigua da qualcun altro, chiedi loro di notare perché l'hanno fatta e come funziona la funzione.

Inoltre, assicurati che ogni sviluppatore del tuo team si attenga a una guida di stile o a una serie di standard. Il Core di WordPress ha una serie di standard di codifica che manterranno plug-in, temi e contributi Core in linea in modo che chiunque altro venga dopo non avrà problemi con esso. Airbnb ha una guida di stile per React che è stata adottata come standard non ufficiale a livello di settore. Anche le guide di stile e gli standard interni impediscono ai tuoi sviluppatori di andare troppo lontano da soli perché quei tipi di commit non verranno uniti a meno che non siano all'altezza.

Avvolgendo

Il debito tecnico è un problema molto reale. È anche una risorsa molto reale se sai come gestirla. Essendo in grado di decidere quando assumere un debito tecnologico e come ripagarlo, il tuo sviluppo può essere più rapido e agevole di quanto altrimenti possibile. E in quei momenti in cui assumersi questo fardello è inevitabile, speriamo di averti dato alcune idee di strategie che puoi implementare per renderlo meno impattante di quanto potrebbe essere altrimenti.

Come gestisci il debito tecnico all'interno dei tuoi progetti e dei tuoi team di sviluppo?

Immagine in primo piano dell'articolo di Andrey Suslov/ shutterstock.com