La modernizzazione del vecchio codice richiede innanzitutto l’archeologia

La cosa più difficile del vecchio codice non è mai la vecchia sintassi, ma i vecchi tempi. Un progetto è pieno di build.xml, vecchio JDK, vecchio framework di test e vecchi metodi di packaging. In apparenza, sembrano diverse pile di file, ma in realtà sono strati di ipotesi storiche impilate l’una sull’altra. Il codice stesso è solo lo strato più esterno. Ciò che realmente blocca la consegna è spesso se questi presupposti sono ancora presenti, se possono essere riprodotti e se il vecchio comportamento andrà perso dopo le modifiche.

Ecco perché l’“archeologia” precede la “trasformazione”. Guarda prima il file di build, poi le dipendenze, poi l’ambiente in esecuzione, quindi i test. L’ordine non può essere invertito. Il build.xml è ancora lì, ma il pom.xml non esiste. Tali segnali sono sufficienti per indicare che il progetto vive nell’era delle Ant; se il codice può essere compilato, se i test possono essere eseguiti e se il prodotto può essere ricostruito sono la prima prova. La parte più utile del modello qui non è scrivere immediatamente nuovo codice per il vecchio codice, ma identificare queste prove da una pila di frammenti.

Anche l’ambiente deve essere bloccato per primo. Il vecchio codice spesso viene fornito con vecchie JVM, vecchi contenitori e vecchi presupposti architettonici. Lanciatelo direttamente sulle macchine di oggi, soprattutto in un ambiente con più architetture, ed è facile mescolare nuovo rumore quando si verificano problemi: il codice è intrinsecamente rotto o sono l’emulazione, il mirroring e le catene di strumenti a causare problemi? Se in questa fase non si riesce nemmeno a ottenere che “lo stesso codice possa essere riprodotto stabilmente nello stesso ambiente”, tutte le successive azioni di modernizzazione saranno solo congetture.

Il valore dell’intelligenza artificiale in questa fase è chiaro: può aiutare con la traduzione a livello di carattere e di struttura. Convertire Ant in Gradle, convertire vecchi script di build in una forma ora gestibile, spostare un mucchio di XML ripetitivi e boilerplate in una posizione più chiara sono tutte cose che sono buoni candidati da lasciare ai modelli. È veloce, disposto a riprovare ancora e ancora e non troppo banale. Ma non è adatto per l’arbitraggio. Quali avvisi possono essere mantenuti per primi, quali test mentono effettivamente, quali moduli dovrebbero essere tagliati per primi e quali classi dovrebbero essere solo impacchettate e adattate. Alla fine, deve ancora essere deciso dalle persone.

I test sono il modo più semplice per ingannare le persone. Superare i test nel vecchio progetto non significa che il sistema sia compreso, può solo significare che alcuni vecchi comportamenti sono semplicemente inseriti nell’ambiente attuale. Quella sensazione di “tutto verde” è pericolosa perché spesso maschera un problema più ampio: ciò che il test verifica sono i dettagli di implementazione di una certa epoca, non la semantica aziendale che deve essere preservata ora. Se si vuole veramente riformare, la prima cosa da fare è togliere questi test dal “senso decorativo di sicurezza” e riconsiderare ciò che stanno proteggendo.

Pertanto, il modo più stabile per questo tipo di progetto di solito non è riscriverlo in una volta sola, ma creare prima una capsula del tempo per riparare il vecchio ambiente, i vecchi comportamenti e le vecchie dipendenze, quindi rimuoverli lungo le crepe più strette. Per prima cosa rendi il sistema riproducibile, poi affida il lavoro ripetitivo all’intelligenza artificiale per la traduzione, quindi elimina i confini strato dopo strato. Se l’ordine è disordinato, il modello accelererà il vecchio progetto e lo spingerà nel caos più profondo; se l’ordine è corretto, il modello sarà come un assistente archeologico davvero utile, responsabile di spostare i mattoni, pulire la polvere e confrontare le prove, liberare le persone dal lavoro sporco e lasciare il giudizio nelle loro mani.