Idea principale

Come si scrive un'API in questo team? Come si gestiscono gli errori? Come si scrive un job asincrono? Come si testa una chiamata a un servizio esterno? Finché queste risposte restano implicite, vengono ricostruite ogni volta — e un assistente di sviluppo, che non ha alcun motivo di preferire la convenzione locale a un'altra, ne propone una diversa a ogni funzionalità.

Il risultato non è un difetto di qualità funzionalità per funzionalità: ogni soluzione, presa da sola, può essere corretta. Il risultato è un team che mantiene più architetture in un solo prodotto, senza che nessuna decisione abbia sancito questa pluralità.

Quello che manca è un catalogo dei pattern autorizzati, deciso dal team e messo per iscritto. Deciso, perché un inventario di ciò che il codice contiene già non fa che ratificare la dispersione; scritto, perché la convenzione mai formulata non si trasmette né a chi arriva né a uno strumento.

Perché è importante

Sposta il bersaglio dello sforzo di omogeneità: la rilettura caso per caso non tiene il passo di un ritmo di generazione, un riferimento a monte sì.

Rivela anche un costo che l'accelerazione nasconde. La lentezza imponeva un'omogeneità di fatto — reinventare ogni volta costava troppo, si copiava il modulo accanto. Questo freno cade quando produrre non costa più niente, e niente lo sostituisce finché la convenzione non è diventata una decisione.

Sfumature e limiti

Un catalogo troppo ricco diventa un ostacolo: congela scelte che il contesto dovrebbe poter riaprire, e finisce ignorato perché nessuno lo tiene aggiornato. Il suo valore sta nella breve lista di domande ricorrenti, non nell'esaustività.

E l'omogeneità non è un fine. Su un perimetro esplorativo, lasciar convivere per un po' più modi di fare è un modo legittimo di confrontarli — a patto che poi la scelta venga presa e messa per iscritto.

Domande aperte

• Chi decide l'ingresso di un nuovo pattern nel catalogo, e da quale segnale un team riconosce che una voce esistente ha smesso di andare bene?