Come risolvere l'anti-pattern del flusso di lava?

Penso che il tuo riassunto abbia semplificato in qualche modo il post del blog. : p Proverò tre frasi, che ritengo cruciali per spiegare perché il codice è diventato ... lava .

The code gen system had somewhat broken down after Bruce had left. None of the remaining team really understood how it worked, so it was easier just to modify the code by hand.

Lezione n. 1: il team deve comprendere appieno come funzionano le cose. Se Bruce è un cattivo educatore, rivolgiti a questo (probabilmente dalla gestione), non aggirare il codice attraverso "modificandolo a mano".

She asked Simon what to do. “Yeah, I think that code was written by some guy who was here before me. I don’t really know what it does. Best not to touch it in case something breaks.”

Lezione n. 2: Scrivi test. Lascia che i test si interrompano per far capire che l'ipotesi di qualcuno è / era sbagliata, e poi risolverlo. Su una nota correlata, non abbiate paura di refactoring o addirittura modernizzare il codice. Assicurati solo che siano state implementate misure di salvaguardia per renderlo esplicito quando "le cose si rompono", prima che il codice entri in produzione.

Ina, frustrated by management who didn’t understand the difficulty of maintaining such horrible legacy applications, left for a start-up where she would be able to build software from scratch.

Lezioni n. 3 e n. 4: è necessario il buy-in dalla direzione e non adottare un Non inventato qui mentalità. Un passo migliore è non confonderlo con il refactoring o la modernizzazione del codice. Se devi davvero passare da J2SE 1.4 a Java 8 per approfittare di 12 anni di miglioramenti e allo stesso tempo risolvere una grande quantità di debito tecnico , che comporterà la riscrittura del 90% del codebase, andare avanti. Non c'è niente di sbagliato nel reinventare la ruota qui, perché devi. Basta non rielaborare le cose per motivi di riqualificazione.

Relativo alla lezione n. 3: Come posso convincere il management a gestire il debito tecnico ?

Diverse idee. Anche se non sono molto sicuro di quanto siano generalmente applicabili.

Innanzitutto, in molti articoli che fanno riferimento a questo anti-modello, il primo consiglio è di resistere all'impulso. Un modo per resistere all'impulso è comprendere l'effetto Dunning Kruger e dedicare tempo a esplorare se l'impulso al refactoring potrebbe essere stato influenzato dalla mancanza di familiarità con il design originale e i requisiti dell'architettura esistente.

In secondo luogo, lungo la stessa linea dell'effetto Dunning-Kruger, un altro modo per resistere all'impulso è capire "Shu-ha- ri "concept . Cioè, una comprensione e una pratica sufficienti dei fondamenti sono un prerequisito prima che si possa contemplare l'esplorazione e l'innovazione. Quando viene applicato all'anti-pattern del flusso di lava, significa che si dovrebbe avere una comprensione e un'esperienza di manutenzione sufficienti sul sistema esistente prima di essere gradualmente autorizzati a apportare modifiche più drastiche alla sua architettura.

In terzo luogo, un modo irragionevole ma a volte efficace per resistere all'impulso è di applicare un bel po 'di "se non è rotto, non aggiustarlo". Dico che è irragionevole perché non si basa sul ragionamento, ma piuttosto sulla testardaggine. Tuttavia a volte risulta nel risultato corretto (un cambiamento drammatico non viene eseguito). Il detto non dovrebbe essere preso alla lettera; dovrebbe essere visto come una lingua che ricorda alla gente l'importanza della stabilità del software.

In quarto luogo, dal punto di vista della gestione, il flusso di lava dovrebbe essere meno probabile che si verifichi se c'è più continuità di squadra (che una squadra rimane insieme per un periodo di tempo più lungo, senza essere sopraffatta dal tasso di turnover, e per ogni progetto lavorare su, rimarranno con esso per gran parte del suo ciclo di vita.)

Alcune analisi aziendali come SWOT (punti di forza, punti deboli, opportunità e minacce) sono utili per promuovere una valutazione obiettiva di una proposta di modifica dell'architettura.

Il controllo della versione, il controllo delle modifiche e la gestione della configurazione possono essere utilizzati per consentire a un team di esplorare in sicurezza architetture alternative mantenendo il sistema di produzione inalterato alle modifiche. Se l'esplorazione fallisce, è accettabile scartare i tentativi falliti.

Infine, bisogna ricordare che l'innovazione non può avvenire in ambienti che non consentono l'esplorazione (e tollerano il rischio di guasti o sforzi sprecati).

Prima di tutto, hai un problema di risorse umane. Se vuoi che i tuoi sviluppatori esperti rimangano, devi dare loro una certa quantità di lavoro sul campo. I programmatori possono gestire un bel po 'di lavoro di manutenzione se hanno anche uno sbocco separato per il loro bisogno creativo di lavorare su qualcosa di nuovo. Molti programmatori gestiscono questo da soli con progetti di hobby, ma i datori di lavoro dovrebbero essere di supporto. La mia azienda ha iniziato di recente a concorsi di hackathon una volta ogni 10 settimane per dare alle persone uno sbocco per l'innovazione.

Da un punto di vista tecnico, il problema non è tanto che la tecnologia stia cambiando. Tutte le basi di codice si evolvono, poiché le tecnologie di terze parti sono supportate solo per così tanto tempo. Il problema più grande qui è che le modifiche non vengono completate prima che inizi il prossimo. Questo è un segno di accoppiamento eccessivo, scarsa coesione e pratiche di test inadeguate nella vostra base di codice. La soluzione è quindi correggere prima .

In altre parole, piuttosto che migrare lentamente verso una nuova tecnologia, migrare lentamente verso un'architettura che ti consentirà di rapidamente migrare verso una nuova tecnologia. Ad esempio, supponiamo di aver bisogno di cambiare il sistema operativo in cui è stato eseguito il prodotto. Non è possibile eseguire solo parte di due sistemi operativi separati durante la transizione. Ciò che puoi fare è astrarre le cose specifiche del sistema operativo a poco a poco, quindi un giorno sarai in grado di capovolgere l'interruttore tutto in una volta.