Definizione breve

Proprietà di un sistema i cui contratti tra API, le cui regole di dominio e i cui test che descrivono il comportamento atteso sono abbastanza riconoscibili e abbastanza separati perché un team sappia rifarlo altrove, con un'altra tecnologia.

Definizione dettagliata

Fuori da qui la parola circola con diversi significati. In ambito operativo indica la capacità di rigenerare un ambiente identico a partire dai sorgenti e dalla configurazione. In archivistica e nella scienza dei dati indica la possibilità di ritrovare un dato o un risultato a partire da ciò che è stato conservato.

Negli articoli di questo blog il termine indica una proprietà della comprensione, non degli strumenti: un sistema è ricostruibile quando lo si saprebbe rifare, il che presuppone di sapere dove passano i confini — dove corre il contratto di un'interfaccia, dove vivono le regole di dominio, quali test dicono il comportamento atteso invece dell'implementazione attuale. La ricostruzione non va eseguita: serve come domanda di controllo, posta al posto di «funziona?».

Il senso normativo e l'uso sul campo divergono su un punto. La norma vorrebbe una ricostruzione identica, fin nei dettagli dell'implementazione. Sul campo la domanda è più debole e più utile: si saprebbe ottenere lo stesso comportamento con altri mezzi, ripartendo da ciò che il sistema dice di sé?

Uso nel dominio

Il termine interviene come criterio di qualità di uno sviluppo assistito da un assistente, là dove la velocità di consegna non dice più nulla su quanto il sistema sia padroneggiato. Serve anche nelle decisioni di architettura — imporre contratti tra API, scrivere la piramide dei test prima di sviluppare, rifiutare che la logica di dominio finisca sparsa negli endpoint — e nelle revisioni di fine lavoro, come domanda che sostituisce la demo funzionante.

Sinonimi e varianti

«Saprei ricostruirlo?» — la forma interrogativa è l'uso corrente del termine. Varianti attestate: «avere appigli sul sistema», «punti di ancoraggio», «linee di separazione».

Da non confondere con

• Debito di comprensione — passivo accumulato da un team su un sistema che non sa spiegare; la ricostruibilità è l'attivo corrispondente, e un team può non avere né l'uno né l'altra su un sistema che non ha ancora toccato.
• Riproducibilità di una build — proprietà di una catena di produzione che genera lo stesso artefatto a partire dagli stessi input; riguarda gli strumenti e si verifica in automatico, senza che nessuno abbia capito che cosa fa il sistema.
• Portabilità — capacità di un software di funzionare in un altro ambiente senza essere rifatto; evita la ricostruzione invece di renderla possibile.
• Documentazione di architettura — descrizione dello stato del sistema così com'è; può essere completa e lasciare un sistema che non si saprebbe rifare, così come può mancare su un sistema i cui test bastano a dirne il comportamento.
• Debito tecnico — debolezza di progettazione di cui si è deciso e messo a budget l'intervento; un sistema può essere pesantemente indebitato e perfettamente ricostruibile, perché uno qualifica la progettazione e l'altra ciò che se ne sa dire.

Esempi

«Se domani devo portare questa applicazione su un'altra tecnologia, so dove sono i contratti, dove sono le regole di dominio, dove sono i test che descrivono il comportamento atteso.» — l'uso di riferimento, applicato a un'applicazione sviluppata con un assistente.

Rinunciare a un approccio DDD completo su un progetto che non lo giustifica, rifiutando però che la logica di dominio finisca sparsa negli endpoint, è una scelta di ricostruibilità: non si cerca la purezza del modello, si cercano linee di separazione riconoscibili.

Ambiguità / dibattiti

La portata non è stabilizzata: ricostruire il comportamento, ricostruire l'architettura o ricostruire il codice. Il senso adottato qui è il primo.

La verifica lo è ancora meno. Nessuno ricostruisce per controllare che ne sarebbe stato capace, il che lascia il criterio allo stato di domanda posta in coscienza — e quindi esposta all'indulgenza di chi risponde.