Idea principale

Si parla spesso delle buone pratiche del software come di un patrimonio stabile: basterebbe documentarle, depositarle nel file di direttive di un assistente di sviluppo e chiedergli di applicarle.

La loro storia racconta altro. I design pattern classici rispondevano a un certo mondo software; il cloud, i sistemi distribuiti, l'asincrono, i microservizi e le architetture a eventi ne hanno fatto emergere un altro, ed è stato necessario inventare l'idempotenza, i retry, i circuit breaker, le saga, l'osservabilità, la resilienza distribuita. Nessuna di queste pratiche è uscita da una rilettura delle precedenti: sono nate da sistemi reali, da guasti, da migrazioni difficili, da vincoli operativi e da compromessi dolorosi.

Per inventare una buona pratica, quindi, non basta conoscere quelle vecchie. Bisogna sentire perché non bastano più, il che presuppone di essere stati esposti a un terreno che resiste — e di saper distinguere quando un pattern è una risposta elegante e quando è soltanto complessità inutile.

Perché è importante

Separa due capacità che si confondono appena uno strumento sa recitare il catalogo: applicare una pratica e produrne una nuova. Un assistente che confronta soluzioni, individua ricorrenze e documenta pratiche emergenti aiuta nella prima; niente dimostra che copra la seconda prima che il terreno abbia reso leggibile il bisogno.

Dà anche la misura di un costo invisibile per un team che non affronta più direttamente l'esercizio in produzione: eredita i pattern esistenti e perde il meccanismo che permetteva di inventarne altri — una perdita che si constata solo alla generazione tecnologica successiva.

Sfumature e limiti

Il terreno non deve per forza essere vissuto in prima persona per insegnare: un post mortem serio, una traccia operativa, l'incidente pubblico di un'altra azienda trasmettono una parte della resistenza. Quello che trasmettono di sicuro è il pattern già trovato; la loro capacità di far emergere il successivo resta da dimostrare.

E non ogni resistenza produce una pratica: molti incidenti lasciano solo una correzione locale, perché nessuno si è preso il tempo di ricavarne una regola.

Domande aperte

• Che cosa fa sì che un guasto generi una pratica riutilizzabile invece di una correzione dimenticata il mese dopo?