Riparare o riscrivere il software? Come decidere

Una riscrittura è una conclusione, non un punto di partenza. La maggior parte dei sistemi di cui si propone la riscrittura non ne ha bisogno. Hanno bisogno di un responsabile, di un piano di riparazione e di qualche mese di lavoro paziente. Pochi invece vanno davvero riscritti, e l’unico modo per capire la differenza è comprendere prima il sistema.

Perché si propone una riscrittura

Le riscritture raramente si propongono perché il sistema è tecnicamente irrecuperabile. Si propongono perché nessuno nel team attuale capisce il sistema, e ricostruirlo sembra l’unico modo per riavere quella comprensione.

È una motivazione onesta. È anche il modo più costoso di raggiungere l’obiettivo. Una riscrittura ricrea la conoscenza ricreando il software, e tutto ciò che il vecchio sistema ha imparato in anni di produzione, ogni caso limite e ogni correzione, va imparato da capo.

Il secondo motivo più comune è la frustrazione. Modifiche lente, incidenti ricorrenti e uno stack poco conosciuto rendono allettante ripartire da zero. La frustrazione è reale. Il rimedio, di solito, è una responsabilità chiara, non la sostituzione.

Cosa guardiamo prima di decidere

Non rispondiamo alla domanda «riparare o riscrivere?» nel primo incontro. Rispondiamo dopo una revisione che copre cinque aspetti.

Cosa fa il sistema. Non ciò che dice la documentazione o che ricorda il fondatore. Ciò che fa in produzione, per quali utenti e con che frequenza. Molte riscritture vengono dimensionate su un uso immaginato.

Dove sta il rischio. Quali parti si rompono, quali non le tocca nessuno e quali contengono dati che non si possono perdere. Di solito il rischio è concentrato in una piccola parte del codice.

Se si può modificare in sicurezza. C’è un modo per rilasciare una modifica e sapere che ha funzionato? Ci sono test, ambienti di staging, backup e rollback? Se non ci sono, vengono prima di tutto, qualunque sia la decisione finale, perché una riscrittura senza di essi è solo una versione più grande dello stesso problema.

Quanto costa mantenere lo stack. Framework e runtime arrivano a fine vita. Le spese di hosting crescono. Per alcuni stack è difficile trovare sviluppatori. Sono costi reali, ma misurabili, e spesso più piccoli di una riscrittura.

Di cosa avrà bisogno l’azienda in futuro. Un sistema che richiede tre piccole funzionalità all’anno ha esigenze diverse da uno che deve raddoppiare le proprie capacità. La decisione sulla riscrittura dipende dalla destinazione, non solo dallo stato attuale.

Quando la risposta è riparare

La riparazione è la risposta giusta più spesso di quanto i team si aspettino. I segnali:

• Il modello dei dati di base è solido, anche se il codice che lo circonda è disordinato.
• I problemi sono concentrati. Due o tre moduli causano la maggior parte degli incidenti.
• Il sistema è in produzione con utenti reali e il comportamento da cui dipendono è per lo più non documentato.
• Lo stack è vecchio ma ancora supportato, oppure si può aggiornare per gradi.

Riparare significa stabilire la responsabilità, aggiungere le protezioni (test attorno alle parti rischiose, monitoraggio, deploy affidabili) e poi migliorare il sistema sul posto, una modifica circoscritta alla volta. Gli utenti vedono prima la stabilità e poi i miglioramenti. Nulla viene buttato finché il suo sostituto non è dimostrato.

Quando la risposta è riscrivere

Alcuni sistemi devono davvero essere sostituiti. I segnali sono specifici:

• La piattaforma non è più supportata e non si può aggiornare. Un framework senza correzioni di sicurezza è una scadenza.
• Il modello dei dati non è adatto a ciò che l’azienda fa oggi, e ogni funzionalità deve lottare contro di esso.
• Il sistema è stato costruito per una scala o un caso d’uso che non esistono più, e gran parte di esso è zavorra.
• Il costo di capirlo supera il costo di specificarlo, cosa che accade con codice generato o copiato in massa, privo di un progetto coerente.

Anche in quel caso, dove è possibile riscriviamo per parti. Un nuovo sistema che rileva una responsabilità alla volta dal vecchio mantiene l’azienda in funzione e lascia la decisione reversibile.

Una matrice decisionale

I cinque aspetti della revisione si riducono a una piccola tabella. Assegnate un punteggio a ogni riga per il sistema che avete davanti; la colonna con più segni indica la raccomandazione, e un solo «sostituire» nella riga della piattaforma prevale sul resto.

Domanda	Indica la riparazione	Indica la modernizzazione sul posto	Indica la riscrittura o la sostituzione
La piattaforma è supportata?	Sì, versioni attuali	Sì, ma con diversi passaggi di aggiornamento arretrati	No, e non si può aggiornare
Il modello dei dati è adatto all’azienda?	Sì	In gran parte; alcune strutture ostacolano le nuove funzionalità	No; ogni funzionalità lo aggira
Esiste un modo sicuro per modificarlo?	Sì	In parte; per alcune parti ci sono test e rollback	No, e aggiungerli costa più di quanto valgano le parti
Dov’è il rischio?	Concentrato in due o tre moduli	Distribuito su uno strato che si può sostituire da solo	Ovunque; non c’è un progetto coerente da preservare
Quanto se ne usa ancora?	La maggior parte	La maggior parte, con aree inutilizzate da eliminare	Una minoranza; il resto serve casi che non esistono più
Di cosa ha bisogno l’azienda dopo?	Piccole funzionalità e stabilità	Nuove capacità significative sulla stessa base	Un prodotto diverso

Riparare è manutenzione con un piano. Modernizzare sul posto è il nostro servizio di riparazione e modernizzazione. Una riscrittura si fa comunque per parti dove possiamo, con il vecchio sistema in funzione finché ogni parte non si è dimostrata valida.

La nostra posizione

Capire il sistema, renderlo sicuro da modificare, poi decidere. I team che saltano direttamente alla riscrittura saltano la parte in cui si impara che cosa si sta sostituendo, e quella conoscenza è la cosa più costosa da ricostruire.