Questo articolo sul debito tecnico presenta alcuni aspetti positivi, tra cui:

Lavorare su "questioni tecniche" funziona meglio quando è guidato da storie. La base di codice ha probabilmente bisogno di lavorare ovunque, ma il payoff verrà ricevuto solo dove il codice verrà elaborato per motivi rivolti all'utente. Se nessuna storia passerà attraverso un'area crudista, lavorarci è in gran parte sprecato.

Pertanto, preferisco l'approccio di prendere le storie come al solito (ma probabilmente meno di esse) e seguire la "regola del boy scout" di lasciare il campeggio meglio di quanto tu abbia trovato. In altre parole, ovunque ci conducano le storie, scriviamo più test, rifattorizziamo in modo più aggressivo.

Questo approccio presenta almeno questi vantaggi:

• mantiene il flusso di storie "più sensato";
• fornisce aiuto da tutti i talenti del team;
• prevede che l'intero team impari come mantenere pulito il codice;
• focalizza il miglioramento esattamente dove è necessario;
• non spreca il miglioramento che "potrebbe" essere necessario;

Ho visto che la qualità del codice ha un grande impatto sulla produttività a lungo termine, quindi credo che il debito tecnico dovrebbe essere curato. Penso che il post sopra abbia un senso, ma non sono così sicuro degli ultimi due punti. Sono interessato a scoprire esperienze reali di benefici derivanti dalla pulizia del debito tecnico, anche se non era correlato alle storie degli utenti.

Quali benefici positivi hai visto ripulendo la tua base di codice e liberandoti dal debito tecnico? Quali metodi hai usato per portare a termine il lavoro?

Posso darti un esempio dalla mia esperienza.

Circa 10 o 12 anni fa ho ereditato un'applicazione da un team di sviluppatori che ha finito per lasciare l'azienda (troppo tempo per entrare qui ...). Il sistema era un grande sistema di generazione di report middleware cresciuto in casa. Funzionava ogni settimana e generava circa 2 dozzine di report Excel per i dirigenti di un'azienda Fortune 500. Quando l'ho ereditato, ci sono volute circa 5-6 ore per l'esecuzione e durante una determinata settimana fallirebbero almeno 2 notti.

Non ero un campeggiatore felice di ricevere questo casino.

Inizialmente il mio piano era solo quello di fermare l'emorragia e riparare la causa principale dei fallimenti. Dopo che mi sono sentito più a mio agio con la base di codice, ho iniziato a cercare luoghi in cui avrei potuto refactoring e aggiungere stabilità e prestazioni. Nel corso di 2 anni circa, ho apportato molte, molte modifiche al sistema. Abbiamo ritirato quel sistema un paio di anni fa e a quel punto l'intero processo ha richiesto 45 minuti per funzionare e non ha generato alcun problema negli anni.

Molto lavoro è stato impiegato per ripagare il debito tecnico, ma ne è valsa la pena. È stato bello non ricevere alcuna telefonata nel mezzo della notte per il fallimento del sistema. È stato bello entrare in ufficio al monring e non vedere nient'altro che buone notizie nei registri.

(A parte ... Dopo un paio d'anni mi sono imbattuto in uno dei principali sviluppatori di questo sistema. Mi ha chiesto come andava e gli ho detto quanto fosse grave il sistema. In realtà si è scusato e mi ha detto che sapeva che sarebbe stato una manciata di supporto dopo che se ne andò e desiderò aver fatto un lavoro migliore su di esso).

È stata la mia esperienza che i vantaggi della pulizia del codice sono più evidenti quando devo mantenere il codice in cui la pulizia non è stata eseguita. Laddove è stata eseguita la pulizia, le mie modifiche consistono nella lettura del codice, nell'individuazione di uno o due punti che devono essere modificati e passando da lì. Se la pulizia non è stata eseguita, aggiungi un primo passo per leggere il codice un paio di volte e provare a capire cosa stava pensando l'autore (a volte io) quando lo ha scritto.

l'eliminazione del debito tecnico produce meno supporto tecnico e una base migliore per i miglioramenti

sempre

Un'esperienza che ho avuto è stata quando gestivo un team di Site Performance presso il mio precedente datore di lavoro. Ogni notte, per un periodo compreso tra un'ora e due ore, il sito Web che il mio team stava monitorando scendeva al di sotto delle soglie di prestazioni accettabili a causa di un bot che ha rapidamente raccolto informazioni dal sito. Le misure adottate dal team per risolvere questo problema consistevano nel accedere a un sistema di amministrazione manuale e nel bloccare gli indirizzi IP che causavano i problemi. Inutile dire che questo costava a un membro della squadra ore di sonno quasi ogni notte. Ho notato cosa stava succedendo e ho preso il BlackBerry di guardia per diversi giorni per vedere quanto fosse brutto e dare un po 'di riposo al mio team.

Dopo alcuni giorni, sono andato semplicemente al proprietario dell'azienda del team e ho fatto sapere loro che se non avessimo implementato un sistema di blocco automatico tale che i robot avrebbero avuto un momento molto più difficile a influenzare le prestazioni del sito, probabilmente avremmo perso alcuni se non tutti i membri del team a causa della fatica e del burnout. Hanno concordato e abbiamo implementato un sistema che ci ha permesso di dormire la notte. Il proprietario dell'azienda ha capito che il costo di alcuni giorni o una settimana di sviluppo era minimo rispetto al costo di assunzione / formazione di nuovi ingegneri.

Per quanto riguarda gli ultimi due punti: capisco da dove proviene, come spiegato nel suo post originale :

Oppure, è possibile riassegnare alcuni sviluppatori per portare a termine queste questioni tecniche, mentre il resto del team continua con le attività orientate all'utente? Ciò può influire sulla velocità della squadra, ma allora?

"Quindi cosa" equivale: il proprietario del prodotto e altre persone del settore diventano infelici. E quando la mamma è infelice, tutti sono infelici.

Tuttavia, il confine tra ciò che deve essere fatto e ciò che può essere fatto è piuttosto vago. L'utente è molto vasto e include le prestazioni e il verificarsi di errori. Ma in alcuni casi, il problema alla base delle scarse prestazioni e dell'elevata occorrenza di errori risiede nel codice. Per dirlo con le sue parole: una storia potrebbe non attraversare un'area crostosa, ma quella zona crudele può nascondere alcune cose brutte che attaccano la storia sul percorso pulito accanto ad essa.

Le cose che non influenzano le prestazioni complessive sono meno interessanti da ripulire, ma si dovrebbe valutare con molta attenzione l'influenza di quei punti. Molto spesso hanno un'influenza indiretta che può essere piuttosto sostanziale.

Il più grande vantaggio che un'organizzazione riceverà a seguito del pagamento del debito tecnico è evitare l'interesse composto. Di seguito è riportato un esempio nel post di blog che mostra come l'importo principale dovuto su un debito tecnico sia passato da $ 160.000 a $ 430.000 in soli cinque anni. Ci vorrebbe un programmatore a tempo pieno dedicato esclusivamente a servire quel debito. Ciò contribuirà a metterlo in prospettiva per i decisori!

Da blog.acrowire.com .