Perché ho smesso di scrivere codice e ho iniziato a progettare
Un tempo pensavo che lo sviluppo software consistesse nello scrivere funzionalità. Pensavo che il mio compito fosse creare entità, costruire controller e collegare database.
Un progetto recente ha cambiato la mia prospettiva. Ho imparato che la programmazione è solo una parte della soluzione. Il vero lavoro avviene prima di scrivere una singola riga di codice.
Devi decidere l'architettura. Devi chiederti perché sia adatta, quanto costi e quali rischi risolva.
Ecco le mie lezioni principali:
• L'architettura deve essere in linea con la fase del prodotto. È tentante utilizzare immediatamente microservizi, Kubernetes e code di eventi complesse. Per il nostro progetto, abbiamo scelto un'architettura a livelli in un singolo processo. Ciò ci ha permesso di separare le responsabilità senza il mal di testa di un sistema distribuito. Quando si inizia, spesso la semplicità è la scelta migliore.
• Alcune decisioni sono economiche ora, ma costose in seguito. Abbiamo aggiunto un TenantId al nostro modello dati fin dal primo giorno. Anche se avevamo un solo cliente, questo ha facilitato un futuro passaggio a un modello SaaS. Se aspetti troppo tempo per aggiungere il multi-tenancy, la migrazione diventa un incubo.
• La progettazione previene futuri vicoli ciechi. La programmazione risolve un problema immediato. La progettazione risolve un problema senza chiudere le porte al futuro. Abbiamo utilizzato i container fin dall'inizio per facilitare il passaggio a diverse infrastrutture. Abbiamo usato le interfacce per rendere semplice la sostituzione dei provider.
• I cambiamenti del business guidano i cambiamenti tecnici. Un sistema passa ai microservizi perché il business cresce. Un'app per una singola clinica diventa una piattaforma SaaS per centinaia di cliniche. Questo cambiamento modifica il modo in cui gestisci la fatturazione, gli abbonamenti e la scalabilità.
• L'affidabilità richiede pattern intelligenti. Siamo passati dalle chiamate sincrone a un'architettura event-driven. In un sistema medico, un servizio di notifica lento non dovrebbe bloccare la prenotazione di un appuntamento. Abbiamo utilizzato l'Outbox pattern per garantire che i dati rimangano al sicuro anche in caso di guasto del message broker.
• I pattern devono adattarsi al dominio. Non usare i pattern alla cieca. Una diagnosi medica richiede una strong consistency. Non puoi fare affidamento sulla eventual consistency per la sicurezza del paziente. Non usare la cache per dati clinici sensibili se questo compromette l'audit trail.
• Il DevOps non è un pensiero postumo. Deployment, health check e pipeline fanno parte della progettazione iniziale. Devi stimare i costi e scegliere componenti che servano effettivamente alle tue esigenze.
La differenza tra un programmatore e un designer è il "perché".
Un programmatore si chiede: "Come faccio a farlo funzionare?" Un designer si chiede: "Perché questa è la soluzione giusta per questo problema specifico?"