Software Architect & Development Lead
Come lavoro
Non vendo ore né pacchetti. Racconto qui i problemi su cui sono utile e il metodo con cui li affronto, così puoi capire da solo se ha senso scrivermi.
01 /
Quando ha senso chiamarmi
01
Revisione di un’architettura esistente
Quando un sistema funziona ma è diventato difficile da far evolvere. Ricostruisco com’è fatto davvero, individuo i punti che frenano le modifiche e restituisco una lista di interventi ordinata per rapporto fra rischio e beneficio, non per gusto tecnico.
02
Recupero di applicazioni legacy
Applicazioni in esercizio da anni, senza documentazione attendibile e con poche persone che ne conoscono il funzionamento. Ricostruisco il comportamento reale partendo da codice e dati, e definisco un percorso di modernizzazione che non richieda di fermare il servizio.
03
Riferimento tecnico per un team
Affiancamento a team che crescono più in fretta delle proprie convenzioni. Definizione dei confini architetturali, revisione delle scelte che costa troppo sbagliare, e trasferimento del contesto necessario perché il gruppo decida in autonomia.
04
Progettazione di un sistema da zero
Dalla definizione del problema alla struttura dei moduli e del modello dati. L’obiettivo non è la soluzione più sofisticata, ma quella che regge i primi due anni di cambiamenti senza dover essere riscritta.
02 /
Come lavoro
Prima il problema, poi la tecnologia
Nessuna scelta tecnica prima di aver capito cosa deve fare il sistema e quali vincoli sono reali. Le decisioni prese al contrario si pagano per anni.
Le decisioni si mettono per iscritto
Una scelta architetturale senza le sue motivazioni è una scelta che verrà ribaltata al primo cambio di persone. Scrivo cosa è stato deciso, perché, e cosa si è consapevolmente rinunciato a verificare.
Lascio sistemi che altri possono mantenere
Un intervento riuscito non è quello che richiede la mia presenza per continuare a funzionare. Il criterio è quanto il team resta autonomo dopo.
03 /
Domande frequenti
- Su quali tecnologie lavori?
- Il mio terreno più solido è l’ecosistema Java lato server, con database relazionali e integrazioni verso directory aziendali. Lato client ho lavorato a lungo con Angular e TypeScript, e ho pubblicato applicazioni Android. Detto questo, la parte che porto non è lo stack: è il metodo con cui si decide quale stack ha senso.
- Lavori anche su sistemi che non hai progettato tu?
- È la situazione più frequente, e quella in cui sono più utile. Ricostruire il comportamento di un’applicazione partendo dal codice e dai dati, quando la documentazione non esiste o descrive un sistema che non c’è più, è la competenza che mi viene chiesta più spesso.
- Scrivi codice o solo documenti?
- Scrivo codice. Un’architettura proposta da chi non mette le mani nel sistema tende a ignorare proprio i vincoli che contano. La proporzione cambia a seconda del lavoro, ma non consegno mai solo diagrammi.
- Come si comincia?
- Con un’email in cui mi racconti il problema, anche in forma disordinata. Da lì capiamo se è il tipo di lavoro in cui posso essere utile: se non lo è, te lo dico subito.