Metodo
Il mio approccio è architecture-first: non significa progettare tutto in anticipo, ma chiarire presto i confini che permettono al sistema di evolvere.
1. Partire dagli Invarianti
Prima delle funzionalità identifico cosa deve restare vero: assunzioni, requisiti minimi, errori inaccettabili e condizioni di correttezza. Quando possibile, questi invarianti vengono documentati, modellati e validati a runtime.
2. Rendere Espliciti i Contratti
Preferisco sistemi in cui interfacce, assunzioni e compatibilità siano verificabili. Questo può avvenire tramite schemi dichiarativi, regole di validazione, runtime contracts o controlli di versione.
3. Estendibilità Senza Caos
Un sistema estendibile non è solo un sistema con plugin. Servono extension point chiari, contesti isolati, validazione dei componenti e prevenzione del coupling nascosto.
4. Fallire Presto e Chiaramente
Un errore deterministico e diagnosticabile è preferibile a una corruzione silenziosa. Questo principio guida il modo in cui progetto validazione, modello degli errori e controlli runtime.
5. Trattare l’Infrastruttura Come Parte del Sistema
Container, deployment, networking, secrets, logging e modello dei permessi non sono dettagli esterni. Fanno parte del modello di esecuzione e della strategia di affidabilità.
6. Preferire la Prevedibilità alle Soluzioni Furbe
Ottimizzo per chiarezza, determinismo e manutenibilità. Un sistema leggermente meno elegante ma più leggibile e debuggabile spesso è una scelta migliore.