Ancor prima di iniziare la mia carriera lavorativa ho avuto a che fare con una codebase legacy.
Il titolo della mia tesi di laurea, infatti, recitava: “Test automatici su un software legacy”.
L’obiettivo di quelli che sarebbero diventati i miei futuri colleghi era quello di implementare un suite di test automatici end-to-end per cercare di arginare, per quanto possibile, alcune delle problematiche derivanti da decenni di sviluppi fatti da chi li aveva preceduti.
Lo scenario che mi sono trovato davanti era un po’ diverso dalla teoria che, fino a quel momento, avevo studiato sui libri:
- Monolite Java progettato ad inizio 2000
- Utilizzo di framework non più mantenuti
- No test unitari
- Bassa curva di apprendimento
- Costi/Tempi di sviluppo molto alti
- Debito tecnico altissimo
L’azienda però stava crescendo, i colleghi erano giovani e bravi con tanta voglia di sistemare le cose. Ho accettato subito il guanto di sfida.
Una delle prime cose che ho notato dal mio angolino da stagista era una processione infinita verso la scrivania dello sviluppatore senior seduto in fondo alla stanza.
Lui dispensava consigli e i junior dev prendevano coraggio andando a toccare punti di codice che non conoscevano e non potevano capire.
Questo è il primo modo in cui la tua codebase influenza la tua organizzazione: i colli di bottiglia.
Il nostro maestro Pai Mei del codice legacy passava le giornate ad istruire i suoi adepti, cercando di evitare che qualcuno premesse per sbaglio il bottone dell’autodistruzione.
Lo sviluppatore più esperto non sviluppava codice e non aveva neanche il tempo di contribuire ai nuovi progetti che stavano nascendo.
Chiaramente questa prassi era condivisa anche con altre persone, con tempi e costi per l’azienda direttamente proporzionali alla loro seniority.
A livello organizzativo questo ecosistema comportava forti dipendenze tra i team. Il team A per completare il suo progetto X aveva bisogno del supporto di uno sviluppatore del team B, che a sua volta però era già impegnato sul progetto Y.
Questo contesto produceva rapporti di causa effetto che per l’azienda erano insostenibili:
- Bassa produttività → Tempi di consegna molto lunghi
- Tempi di consegna lunghi → Clienti scontenti
- Costi di manutenzione alti → ROI basso
- ROI basso → Scarsa innovazione
Il cambio di passo organizzativo non poteva che partire dalle scelte tecniche.
Abbiamo iniziato a riscrivere il monolite portando in azienda:
- Microservizi
- TDD
- Architettura esagonale
- Framework moderni
Questo ci ha permesso di limitare il più possibile le dipendenze e creare dei team cross funzionali auto organizzati.
Per cambiare la tua organizzazione cambia la tua codebase!
Se poi ti interessasse vedere di persona come continua questa storia ti lascio il link al sito dell’azienda in cui lavoro.
Next: Storia di una codebase legacy, Capitolo 2: Progetti On-Premises e Piramidi
Marco Catellani – Engineering Lead