Analisi di impatto: cosa fare prima di toccare un sistema legacy

C’è un momento ricorrente nella vita di chi lavora su sistemi di lungo corso: arriva una richiesta di modifica apparentemente banale, e nessuno sa dire con sicurezza cosa succederà applicandola. Il codice c’è, funziona da anni, e la documentazione — quando esiste — descrive un sistema che non esiste più.

La reazione istintiva è aprire l’IDE e cercare la classe da cambiare. È quasi sempre la mossa sbagliata, e non per pigrizia intellettuale: è che in un sistema legacy il costo di una modifica non sta nella modifica, sta in ciò che la modifica tocca senza che nessuno se ne accorga.

Il codice è l’unica documentazione attendibile

Il primo assunto da abbandonare è che esista una fonte di verità diversa dal sistema stesso. Le specifiche funzionali descrivono le intenzioni originarie; i wiki interni descrivono come funzionava tre riorganizzazioni fa; le persone raccontano il pezzo che hanno toccato loro.

Il codice, invece, descrive cosa succede davvero. Insieme al codice, i dati: uno schema relazionale in produzione racconta la storia vera di un’applicazione, comprese le decisioni che nessuno ha mai messo per iscritto. Colonne aggiunte e mai popolate, vincoli disattivati per far passare una migrazione, tabelle che duplicano informazioni perché a un certo punto era più veloce così.

Leggere quelle tracce è la parte più informativa del lavoro.

Tre domande prima di ogni modifica

L’analisi di impatto che uso si riduce a tre domande, poste in quest’ordine.

Chi legge questo dato? Non chi lo scrive — chi lo legge. Un campo modificato si propaga a valle attraverso query, report, integrazioni, export notturni, viste materializzate. Il consumatore che nessuno ricorda è quasi sempre quello che si romperà, e quasi sempre è un processo batch che gira una volta al mese.

Cosa succede se questo passaggio fallisce a metà? I sistemi di lungo corso sono pieni di operazioni non idempotenti scritte quando il volume era un decimo. Una modifica che allunga un’operazione può trasformare un caso limite teorico in un incidente settimanale.

Come me ne accorgo se va storto? Se la risposta è “ce lo dirà un utente”, la modifica non è pronta. Non perché serva un osservabilità perfetta, ma perché una modifica di cui non puoi verificare l’esito è una modifica che non puoi davvero difendere.

Scrivere l’analisi, non solo farla

L’analisi di impatto ha valore se produce un artefatto. Non un documento cerimoniale: bastano una pagina con gli elementi toccati, i consumatori individuati, i rischi noti e ciò che si è deliberatamente scelto di non verificare.

Quest’ultima parte è quella che di solito manca ed è la più utile. Dichiarare “non abbiamo verificato il comportamento sotto carico concorrente” è un’informazione preziosa per chi leggerà tra sei mesi, quando il problema si manifesterà. Una lacuna nota è un rischio gestibile; una lacuna implicita è una sorpresa.

Il vero obiettivo

Il punto dell’analisi di impatto non è eliminare il rischio: su un sistema che non hai scritto tu, il rischio zero non esiste. Il punto è spostare il rischio dalla categoria “non sapevamo” a quella “sapevamo e abbiamo deciso”.

È una differenza che sembra formale finché non si trasforma in un incidente in produzione. A quel punto diventa la differenza tra un problema tecnico e un problema di fiducia.