Riscrivere il codice da zero raramente funziona: meglio testare e rifattorizzare l’esistente

👁 116 letture

Simon Willison ha pubblicato il 6 settembre 2026 un commento sul thread Lobsters dedicato al debito tecnico, sostenendo che la riscrittura completa di un sistema legacy fallisce quasi sempre e che l’alternativa più solida è il consolidamento progressivo del codice esistente.

Il ragionamento di Willison parte da un’osservazione ricorrente: nel momento in cui un’azienda annuncia che il sistema vecchio è irrecuperabile e forma un team per riscriverlo da zero, il vecchio sistema non si ferma - continua a far girare il business e continua a cambiare. Chi ci lavora, sapendo che sarà presto sostituito, non ha incentivi a fare di più del minimo indispensabile. Il debito tecnico, quindi, continua ad accumularsi anche durante la riscrittura.

Sul fronte opposto, il team incaricato del nuovo sistema parte con entusiasmo su un progetto greenfield, ma si scontra rapidamente con una realtà scomoda: nessuno conosce per intero il comportamento del sistema che sta sostituendo. Se fosse ben documentato e testato, del resto, non avrebbe bisogno di essere riscritto.

«After months (or even years) without delivering value, the pressure is on to ‘ship it’, so the new system is launched to handle a subset of what the old system handled.»- Simon Willison

Il risultato tipico è avere due sistemi in produzione: il vecchio, che nessuno vuole toccare, e il nuovo, che copre solo una parte delle funzionalità e contiene l’80% di codice inattivo destinato a rimpiazzare il precedente. Se nel frattempo le priorità aziendali cambiano - e accade spesso - il progetto di sostituzione totale viene abbandonato, lasciando l’organizzazione con due sistemi dove prima ce n’era uno. Willison indica come lettura di riferimento l’articolo Migrations: the sole scalable fix to tech debt di Will Larson.

La sua raccomandazione pratica è precisa: aggiungere quanti più test automatizzati possibile al sistema esistente, poi valutare se refactoring mirati possono portarlo alla forma desiderata. «My hunch is that in many cases that will have a much higher chance of success than the siren call of a greenfield replacement», scrive.

Implicazione pratica. Per chi costruisce con strumenti AI - agenti, pipeline di automazione, integrazioni rapide - il punto vale doppio: i sistemi generati o accelerati dall’AI tendono ad accumulare debito tecnico velocemente proprio perché la velocità di produzione supera quella della documentazione e dei test. Prima di cedere alla tentazione di buttare tutto e ripartire da zero, vale la pena investire in una copertura di test solida: è la sola base da cui un refactoring controllato ha probabilità reali di riuscire.

// continua a leggereScala di confidenza LLM: 0-20 funziona meglio di 0-100MagazineCloudflare WARP e 1.1.1.1: cos’è, come funziona e se convieneStrumenti IASkyReels V4: prezzi API, benchmark e come funzionaStrumenti IA