frollo

La storia dell'orrore

Due settimane fa, mi sono messo a fare manutenzione a un po' di codice Java al lavoro. Un processo scritto nella notte dei tempi, prima del mio arrivo in azienda (forse prima del mio arrivo nel mondo dello sviluppo) e che non aveva richiesto nemmeno un riavvio negli ultimi 700 giorni si era improvvisamente bloccato.

Siccome sono arrivato da meno di 700 giorni nella mia azienda, mi stavo inoltrando in un mondo ignoto. Dopo qualche ora di lavoro trovo il punto incriminato (un banalissimo puntamento hardcodato – peccato avessimo migrato il servizio). A metà modifica ho una curiosa sensazione di déjà-vù. Questa roba l'avevo già corretta da un'altra parte. E da un'altra parte ancora. Questo significa due cose: 1. Una sessione di 20 minuti di insulti verso chi ha hardcodato in giro puntamenti a servizi, senza neanche avere la creanza di lasciarmi della documentazione; 2. Che c'è del materiale per una libreria interna;

Finiti i 20 minuti di odio, mi appunto che prima o poi dovrò estrarre il codice. Settimana scorsa ho finalmente il tempo di farlo e mi ci metto. Ci va via tutta una settimana, tra l'identificazione delle classi, la brutale copia, la preparazione della documentazione e dei test (che mancavano) e la pipeline. Quando finalmente ho deployato la nuova libreria e comincio a sostituire le vecchie classi con la versione della libreria, cominciano a piovermi errori di compilazione.

Gli errori hanno poco senso, perché sembra che non ci sia compatibilità tra package.ClasseA e package.ClasseA, o che certi metodi della ClasseA abbiano una signature diversa. L'IDE (IntelliJ Idea) non aiuta, perché non li segna come errori, anzi, secondo lui va tutto che è un piacere – almeno finché non provo a compilare.

Dopo un'ora di lavoro, scopro che quelle famose classi ripetute più volte si ripetono almeno un'altra volta in una dipendenza del codice che sto modificando e che il mio paziente ogni tanto usava la sua versione interna, ogni tanto quella della dipendenza. Mi appunto di correggere anche quella ma, finché non avrò un'altra settimana da dedicarci, si mantiene la porcheria.

La morale

La prima cosa importante che ho imparato da questa disavventura è che le librerie vanno estratte il prima possibile. Se, al momento di riscrivere la stessa classe due volte, coscientemente, il mio predecessore avesse detto “Aspetta, qua serve una libreria”, il macello non sarebbe successo. Il codice duplicato in contesti differenti ha la tendenza a evolversi in modi leggermente differenti (nel mio caso, diverse interfacce avevano sviluppato metodi diversi – spesso molto simili ma non del tutto compatibili – tra un progetto e l'altro, buona fortuna con le implementazioni).

La seconda cosa importante è stata una lezione pratica sul concetto di contagio, che avevo già incontrato, teoricamente, in questo post, ma vederlo con mano è tutta un'altra cosa: fixare quel problema richiedeva una nuova classe, che ora esiste in progetti diversi e, magari, non sarà così identica tra un progetto e l'altro ora che riuscirò a tornare per estrarla. Anche se ci ho messo del mio meglio, devo considerare anche questa classe e i suoi cloni come debito tecnico – e non è ancora stata deployata!