Nel modernizzare il vecchio sistema, Copilot organizza innanzitutto le prove

La prima volta che ho trasferito un progetto Java dell’era 1.5 su una macchina moderna, la prima cosa che è emersa non è stato il problema del codice, ma il problema delle prove. Se la build può essere riprodotta, se l’output del test è lo stesso, se il punto di errore proviene dalla JVM, dall’immagine o dal codice sorgente, questi fattori determinano come procedere prima di “iniziare il refactoring”. La paura più grande quando si modernizzano i vecchi sistemi non è che i cambiamenti siano lenti, ma che sia impossibile dire cosa sia successo dopo i cambiamenti.

Prima correggi la scena, poi le azioni successive saranno significative. La cosa più preziosa in questo passaggio non è il completamento nell’IDE, ma una scatola che può essere eseguita ripetutamente: il vecchio JDK, i vecchi strumenti di compilazione, i vecchi ingressi e i vecchi comandi di test sono tutti bloccati in Docker. Comandi come i seguenti non sono belli, ma funzionano:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

Questo comando ha una sola funzione: fissare il “fallimento di oggi” in prove riproducibili. Senza di esso, ogni successo successivo potrebbe essere semplicemente il risultato di circostanze che si sono rivelate clementi. Anche qui il ruolo del copilota è molto chiaro. Non è per sostituire il giudizio, ma per aiutare a risolvere le tracce: errori ripetuti in log lunghi, percorsi che si ripetono negli script di compilazione e diverse voci ricorrenti nei vecchi test possono essere tutti utilizzati per uno screening approssimativo. Ciò che viene vagliato non è una conclusione, ma una mappa da cui cominciare.

Quando arriva il momento di andare effettivamente sotto i ferri, l’area di cambiamento deve essere molto ristretta. Il modo più semplice per ribaltare i vecchi progetti è modificare il nome del pacchetto, creare, inserire e testare tutto in una volta. Alla fine, non si può nemmeno dire quale passo abbia rotto il sistema. Un approccio più stabile consiste nel cogliere prima lo spazio più piccolo: ad esempio, coprire il vecchio ingresso con uno strato di adattatori, prima consentire alla nuova catena di strumenti di stare fuori dal vecchio mondo e vedere chiaramente la struttura, quindi spostarsi lentamente all’interno. Copilot è molto adatto per gestire questo tipo di lavoro meccanico: riempire importazioni, spostare configurazioni, estrarre frammenti ripetuti e generare scheletri di test temporanei. Lasciamo che il modello faccia queste cose e l’efficienza sarà davvero elevata; ma spetta ancora alle persone decidere se questa cucitura debba essere tagliata e quale comportamento debba essere preservato dopo il taglio.

Anche quando si tratta di testare è facile lasciarsi ingannare dalle apparenze. Superare il vecchio test non significa che la modernizzazione sia sicura, significa solo che alcuni comportamenti storici non sono stati ancora superati. I test di molti vecchi progetti sono più simili a istantanee comportamentali che a specifiche semantiche aziendali. Il verde è semplicemente verde e non può essere interpretato direttamente come “comprensione del sistema”. Una delle azioni più importanti durante la trasformazione è quella di aggiungere nuovi e più stretti confini di test a ogni piccola incisione, in modo che il test cambi gradualmente da “eredità storica” ​​a “vincoli attuali”. Copilot può aiutare ad abbattere vecchie asserzioni, completare modelli e implementare shell di test duplicate. Tuttavia, quale semantica dovrebbe essere mantenuta nel test e nel modello non può prendere decisioni per il sistema.

Nella modernizzazione archeologica, la divisione del lavoro più affidabile è in realtà molto semplice: l’ambiente e i registri sono responsabili di fissare i fatti, il Copilota è responsabile dello spostamento dei mattoni e della traduzione, e le persone sono responsabili di decidere quale storia dovrebbe essere conservata e quale storia dovrebbe essere eliminata. Una volta predisposto un modello per spiegare il passato del sistema, spesso le ipotesi sono più convincenti delle prove; rimettendolo nella posizione di gestione delle prove e organizzazione meccanica, diventa più simile a un assistente veramente utile.