Il pipe operator di PHP 8.5: leggibilità reale o zucchero sintattico?
PHP 8.5 introduce il pipe operator, e la domanda onesta è se migliori davvero la leggibilità o sia solo zucchero sintattico. Analisi pratica: cosa risolve davvero, ovvero le chain leggibili da sinistra a destra; i limiti reali con i callable a più parametri e i built-in da wrappare; e gli esempi da codice gestionale dove il pipe rende il flusso chiaro contro quelli dove aggiunge solo una sintassi nuova. Onesto sui tradeoff, non entusiasta per default. 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. 
Il codice PHP che scrivi oggi sarà mantenuto da qualcun altro tra cinque anni - e quel qualcun altro potresti essere tu. Ho estratto i principi concreti che distinguono il codice che invecchia bene da quello che diventa legacy immediato, basandomi su 15 anni di eredità di progetti altrui. 
I worker Laravel Horizon di un cliente consumavano 500MB di RAM dopo 6 ore di esecuzione e venivano killati automaticamente. Il memory leak non era ovvio: un event listener registrato globalmente teneva riferimenti a ogni job processato. Vi mostro il processo di diagnosi con Blackfire e le strategie di correzione. 
La documentazione API scritta a mano diverge dall'implementazione in settimane. Ho adottato un approccio code-first: annotation PHP sugli endpoint, generazione automatica dello spec OpenAPI in CI, validazione delle request/response contro lo spec nei test. Gli integratori hanno sempre documentazione fedele alla realtà. 
Dopo aver introdotto PHPStan a livello 9 su un progetto Laravel legacy con 80.000 righe di codice, ho trovato 340 errori di tipo - di cui 12 erano vulnerabilità di sicurezza reali, tra cui due SQL injection potenziali e una IDOR. L'analisi statica non sostituisce il pen test, ma lo rende più efficiente. 
Ho trovato una SQL injection in un gestionale di ordini PHP usato da un'azienda con 80 dipendenti. Il codice era del 2019, aggiornato più volte, ma la query vulnerabile era sopravvissuta a tutti i refactoring. Vi spiego perché SQLi è ancora viva, quali pattern la nascondono e come fare code review mirata. 
Un'applicazione Laravel abbandonata da due anni su PHP EOL non si affronta in emergenza: va mappata sistematicamente prima di toccarla. Il caso reale di un gestionale interno per una catena di cliniche dentistiche veronesi del 2025, il metodo in dodici giorni con cui ho prodotto documentazione viva partendo da zero, e gli strumenti di static analysis che rendono il reverse engineering effettivamente economico. 
La differenza fra senior e junior non è il numero di anni: è un set di abitudini operative misurabili. Definition of done estesa, lettura prima di scrittura nel rapporto 10:1, refactoring incrementale del 10% per PR, KISS sopra cleverness, ADR scritti come codice di prima classe, regole non negoziabili su Git e migrazioni. Sei abitudini che difendo in ogni code review PMI e che abbattono il debito tecnico in modo misurabile nei tre-quattro mesi successivi.