L'architettura del codebase AI-friendly: deep modules, AI come dependency, e perché il debito non si refactora da solo
Architetture pensate per umani aiutano l'AI di più di architetture pensate per l'AI. Moduli profondi con interfacce semplici. AI integrata come dependency lenta e non deterministica, dietro circuit breaker e fallback. E la verità che spinge il mercato in direzione opposta: il debito accumulato oggi non sarà refactorato da nessun modello futuro, perché refactoring richiede intent originale, non sintassi. Continua a leggere
Ultima modifica:
La prima settimana su un progetto legacy è sempre disorientante. Ho sviluppato un processo sistematico di audit tecnico in 5 fasi: analisi statica con PHPStan, complessità ciclomatica con PHP Metrics, mappa delle dipendenze esterne, test di copertura esistente e interviste al team. Output: un report con priorità chiare. 
Un e-commerce torinese con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
Ho migrato tre applicazioni da Symfony 5 a Symfony 7 in produzione. Il percorso non è una singola migrazione: si passa per Symfony 6 gestendo ogni set di deprecation progressivamente. Vi racconto i breaking change che mi hanno sorpreso di più, le scorciatoie che non funzionano e il processo sistematico che uso. 
Ogni codebase PHP legacy che eredo ha la stessa peste: costanti integer o stringhe magiche per rappresentare stati di business. ORDINE_STATO_1, ORDINE_STATO_2. Con PHP 8 Enums, ho modernizzato un sistema ordini trasformando 40 costanti sparse in enum tipizzati con metodi di dominio. Il codice è diventato leggibile. 
Un CTO mi ha chiesto di convincere il suo CEO a investire in refactoring. Ho costruito un modello di costo basato su dati reali: tempo medio per aggiungere una feature, numero di bug per rilascio, costo orario del team. Il debito tecnico costava all'azienda 180.000€/anno in produttività persa. Il CEO ha approvato. 
La 'riscrittura totale' è quasi sempre un errore. Con il pattern Strangler Fig ho aiutato una società logistica a estrarre gradualmente funzionalità dal loro monolite Laravel: prima il modulo di tracking, poi la fatturazione. Due anni dopo, tre microservizi autonomi e il monolite ridotto del 40%, sempre in produzione. 
Modernizzare un'applicazione PHP 7.4 a PHP 8.3 non significa riscrivere tutto - significa sfruttare le nuove feature dove migliorano la leggibilità e la sicurezza. Vi mostro il processo che uso: identificare i candidati giusti per match expression e named arguments, refactoring sicuro con test a tappeto. 
Un gestionale PHP legacy con zero test e 3 regressioni al mese: ogni fix rompeva qualcosa. In 5 giorni ho introdotto 28 smoke test HTTP e 12 snapshot test sulle funzioni di calcolo - senza toccare il codice applicativo. Regressioni in produzione scese da 3/mese a zero nel primo trimestre. 
Un gestionale PHP 5.6 con 23.000 righe, zero test e debito tecnico che rendeva ogni modifica un rischio: il cliente pagava il triplo per ogni nuova funzionalità rispetto a un'applicazione moderna. In tre mesi di refactoring incrementale con Strangler Fig Pattern, PHPStan e Rector l'ho reso manutenibile senza riscrivere una riga da zero.