Il debito tecnico non dipende da chi ha scritto il codice, ma da quanto costa modificarlo. Un modulo perfettamente corretto che nessuno nel team comprende rappresenta un debito tecnico, anche se non presenta un singolo bug, perché ogni futura modifica richiederà di ricostruire il ragionamento che nessuno ha mai creato.
Questo è più importante che mai, perché si è creata una scorciatoia per accumulare codice corretto ma frainteso: accettare ciò che un modello genera senza capirne il perché.
Quando un team modifica un sistema, il vero lavoro non consiste nello scrivere nuove righe di codice. Consiste nel rispondere a tre domande prima di scriverle: cosa fa questo codice ora, perché è fatto in questo modo e cosa si romperà se lo modifico.
Questo lavoro si chiama comprensione e assorbe la maggior parte del tempo necessario per qualsiasi modifica a un sistema maturo. Se nessuno ha compreso il codice quando è stato introdotto per la prima volta, il conto non scompare: viene semplicemente rimandato e pagato con gli interessi, perché chi lo paga non avrà nemmeno il contesto della discussione originale.
Si riscontra una scomoda asimmetria: Generare è più veloce che comprendere.. Un modello può produrre in pochi secondi qualcosa che una persona impiega venti minuti a comprendere. Quando la generazione accelera e la comprensione non tiene il passo, lo squilibrio si accumula nel repository.
Nessuno sa se un componente viene utilizzato. Appare del codice che può essere necessario o meno e, in caso di dubbio, viene mantenuto. Il sistema si gonfia di materiale che nessuno osa eliminare.
Le recensioni diventano superficiali. Quando si verificano frequentemente cambiamenti importanti, il processo di revisione passa da "Capisco e sono d'accordo" a "Sembra ragionevole". È un cambiamento silenzioso ma decisivo.
Gli stessi problemi vengono risolti due volte. Compaiono tre funzioni che svolgono praticamente la stessa funzione, perché nessuno sapeva dell'esistenza delle altre.
Gli errori si correggono avvolgendoli, non riparandoli. Invece di risolvere il problema, si aggiunge un'ulteriore condizione, perché toccare l'originale fa paura.
GitClear ha quantificato il terzo sintomo: i blocchi di codice duplicati sono aumentati di otto volte nel 2024 e il loro successivo rapporto ha indicato che la duplicazione ha continuato a crescere. La duplicazione è la firma statistica dell'incomprensione: le persone copiano ciò che non comprendono abbastanza bene da poterlo riutilizzare efficacemente.
Noi ne proponiamo solo una, ed è facile da difendere in qualsiasi squadra:
Nessuno unisce codice che non sarebbe in grado di spiegare a una lavagna.
Non è necessario comprendere ogni dettaglio dell'implementazione. È sufficiente essere in grado di rispondere a tre domande: quale problema risolve, perché è stato risolto in questo modo e non in un altro, e cosa accadrebbe se cessasse di esistere.
Se applicata correttamente, questa regola non rallenta il processo, bensì lo riordina. La generazione del codice 80% con l'aiuto di un esperto rimane valida. Ciò che non è più valido è incorporarlo senza averlo letto.
|
Pratica |
Prima |
Con generazione assistita |
|---|---|---|
|
Entità del cambiamento |
Limitato dal tempo disponibile per scriverlo |
Può crescere senza limiti naturali. |
|
Obiettivo della revisione |
Trova gli errori |
Verificare la comprensione e l'adeguatezza |
|
Rischio principale |
Un guasto specifico |
Accettare una struttura su cui nessuno ha deciso |
|
Controllo efficace |
Revisione paritaria |
Modifica il limite di dimensione e i test obbligatori |
La dimensione delle righe spiega il risultato di DORA del 2024: con l'aumento dell'adozione dell'IA, la stabilità delle consegne è diminuita del 7,21 TP3T. La causa non è la qualità del codice generato, bensì la scomparsa del naturale deterrente alla sua scrittura. Una modifica di mille righe non viene revisionata allo stesso modo di una di cinquanta, a prescindere dalla competenza del revisore.
Pertanto, il controllo più efficace non è uno strumento, bensì uno standard di processo: limitare l'entità delle modifiche. È semplice, ma funziona.
Test redatti da una sola persona. È ragionevole che il modello generi l'implementazione; è altrettanto ragionevole che generi anche il test che convalida tale implementazione, chiudendo così il ciclo. Il test deve esprimere ciò che l'azienda si aspetta, e questo è qualcosa che solo una persona può sapere.
Documentazione della decisione, non del codice. Non è necessario commentare ogni singola riga. Ciò che serve è un paragrafo che spieghi perché è stato scelto questo approccio e quale alternativa è stata scartata. Questo permette di modificarlo entro un anno senza dover ripetere l'analisi.
Un limite di dimensione per ogni modifica. Qualsiasi limite ragionevole funziona. Il suo valore non sta nel numero in sé, ma nel fatto che costringe a scomporre il lavoro in unità comprensibili.
Tutte e tre sono economiche e nessuna richiede nuovi strumenti. È la stessa logica di base che sta alla base degli standard di ingegneria che applichiamo a ogni consegna: contratti espliciti, ambienti isolati e documentazione trasferita al cliente, perché Il codice e la relativa documentazione sono di proprietà di chi li acquista.
In un audit, c'è una domanda che guida la diagnosi più rapidamente di qualsiasi parametro: Scegliete un modulo a caso e chiedete a un membro del team di spiegarvi perché è stato realizzato in quel modo..
Se viene fornita una spiegazione coerente, il sistema è gestibile nonostante i suoi difetti. Se invece la risposta è che funziona e nessuno sa bene perché, il costo di ogni futura modifica sarà superiore a qualsiasi stima, e tale differenza non farà che aumentare.
Questo è il vero indicatore del debito tecnico. Non le righe di codice, non l'età, non lo strumento con cui è stato scritto: il divario tra ciò che il sistema fa e ciò che l'organizzazione ne sa.
Si tratta del costo aggiuntivo sostenuto per ogni modifica futura, conseguenza di decisioni prese all'epoca per accelerare il processo. Non si misura in base all'età del codice o a chi lo ha scritto, ma in base al costo di modificarlo in modo sicuro.
Non per la sua qualità intrinseca, ma perché scompare la naturale limitazione della scrittura: le modifiche aumentano di dimensioni, le revisioni diventano superficiali e la duplicazione si moltiplica. GitClear ha documentato che i blocchi duplicati sono aumentati di otto volte nel 2024.
Con una semplice regola: nessuno integra codice che non sarebbe in grado di spiegare a parole, illustrando quale problema risolve, perché è stato risolto in quel modo e cosa accadrebbe se cessasse di esistere. Non è necessario comprendere ogni singolo dettaglio di implementazione.
Tre: una prova scritta da parte di una persona che esprima le aspettative dell'azienda, la documentazione della decisione e dell'alternativa scartata, e un limite di dimensione per ogni modifica che obblighi a suddividere il lavoro in unità comprensibili.
Perché copiare è la risposta più comune quando non si comprende a sufficienza ciò che già esiste per poterlo riutilizzare. Ogni copia moltiplica il numero di punti in cui la stessa soluzione dovrà essere applicata in futuro.
Chiedere a un membro del team di spiegare perché un modulo scelto a caso è stato costruito in quel modo. Se la spiegazione è coerente, il sistema è gestibile nonostante i suoi difetti; se la risposta è che funziona e nessuno sa perché, ogni modifica costerà più del previsto.
Quanto del vostro sistema è ben compreso dal vostro team oggi? Eseguiamo audit di architettura, codice, debito e sicurezza, e forniamo una diagnosi scritta entro 10 giorni lavorativi, a un prezzo fisso. Richiedi la verifica →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
