---
title: "Refactoring"
description: "Refactoring che migliora il codice senza rompere il business: subentro su codebase ereditate, modernizzazione legacy e debito tecnico. Interventi incrementali. - Refactoring - Pagina 1 di 5"
canonical: "https://www.mauriziofonte.it/blog/cat/refactoring.html"
author: "Maurizio Fonte"
---

Categoria

# Refactoring

Pagina 1 di 5

## **Refactoring**: migliorare il codice esistente senza rompere il business

Fare refactoring vuol dire trasformare una codebase confusa, fragile o lenta in qualcosa di leggibile e testabile, tenendola in produzione mentre la modifichi. È il lavoro meno appariscente che uno sviluppatore senior possa fare, e uno dei più utili. In questa categoria raccolgo il metodo con cui si interviene su codice reale, quello che le aziende hanno davvero, lontano dagli esempi dei tutorial.

Spesso si parte dal **subentro sull'ignoto**. Molto del mio lavoro comincia con una base ereditata, senza documentazione, spesso dopo la sparizione dello sviluppatore originale: migliaia di righe da capire, credenziali da recuperare, un business che intanto deve continuare a girare. Scrivo del metodo per mappare in pochi giorni cosa hai davanti, del reverse engineering sistematico e del protocollo delle prime ore quando la situazione è un'emergenza.

Poi viene la **modernizzazione senza rotture**: portare avanti una base PHP legacy o un framework fuori supporto attraverso le versioni, gestendo i cambi di comportamento silenziosi, che sono il rischio più insidioso. La metrica che conta è il rischio di regressione, e l'approccio è incrementale, misurabile e reversibile, così che il software funzioni come prima ma diventi finalmente modificabile.

Infine il **debito tecnico come questione aziendale**. Il debito ha un costo che si può calcolare e presentare al management, e decidere quando pagarlo è una scelta strategica. Racconto come si porta questa conversazione fuori dal reparto tecnico, dove le decisioni si prendono davvero.

Se hai una codebase che rallenta il team, vedi la [consulenza IT e DevOps](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) o [parliamone](https://www.mauriziofonte.it/pages/contattami).

> Il refactoring ben fatto si vede dal fatto che nessuno se ne accorge: il software funziona come prima, ma adesso si può toccare senza paura.

1[2](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=4)[5](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=5) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html)

## [Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html)

30/09/2026 ![Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/image/005410200-scadenze-eol-php-2026-piano-migrazione-parte-adesso.jpg) Le scadenze EOL di PHP non sono un dettaglio da sysadmin: sono una leva di rischio per chi resta indietro. Lo stato reale nel 2026, con le date dal dossier: 8.3 già in security-only, 8.4 in supporto attivo fino a fine anno, 8.2 fuori dalla sicurezza a fine 2026. Il piano di migrazione da avviare adesso per chi è su 8.2 o 8.3: checklist, deprecazioni da gestire, test, e perché aspettare l'ultimo trimestre è la scelta più costosa. [Continua a leggere](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html) Ultima modifica: Mercoledì 30 Settembre 2026, alle 07:49 [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

## [Principi SOLID applicati a Laravel: refactoring da controller a service layer](https://www.mauriziofonte.it/blog/post/principi-solid-laravel-refactoring-controller-service-layer.html)

08/09/2026 ![Principi SOLID applicati a Laravel: refactoring da controller a service layer](https://www.mauriziofonte.it/image/005250200-principi-solid-laravel-refactoring-controller-service-layer.jpg) I controller gonfi sono il debito tecnico più comune in Laravel, ma la cura non è astrarre tutto. Come applicare i principi SOLID in modo pragmatico: spostare la logica di business in un service layer, dove la separazione paga davvero e dove invece aggiunge solo indirezione. Refactoring concreto da un controller reale, con i tradeoff dichiarati: la testabilità che guadagni contro la complessità che introduci. [Continua a leggere](https://www.mauriziofonte.it/blog/post/principi-solid-laravel-refactoring-controller-service-layer.html) Ultima modifica: Martedì 8 Settembre 2026, alle 09:12 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html)

## [Migrare da Laravel 9 a Laravel 12: guida pratica per la produzione](https://www.mauriziofonte.it/blog/post/migrare-laravel-9-laravel-12-guida-pratica-produzione.html)

02/09/2026 ![Migrare da Laravel 9 a Laravel 12: guida pratica per la produzione](https://www.mauriziofonte.it/image/005210200-migrare-laravel-9-laravel-12-guida-pratica-produzione.jpg) Saltare da Laravel 9 a 12 non è un singolo upgrade ma una sequenza, e il lavoro vero spesso non è nel framework ma nel salto della versione PHP minima richiesta. Guida pratica per la produzione: i breaking changes che contano versione per versione, cosa testare prima del deploy, e perché zero breaking changes dichiarati non significa zero differenze comportamentali. Strategia incrementale da un'applicazione reale. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrare-laravel-9-laravel-12-guida-pratica-produzione.html) Ultima modifica: Mercoledì 2 Settembre 2026, alle 07:35 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html)

## [Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/blog/post/migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.html)

31/08/2026 ![Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/image/005190200-migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.jpg) Migrare un'applicazione legacy da PHP 7.4 a 8.3 è un progetto di rischio gestito, non un aggiornamento al volo. Checklist concreta: i breaking changes che mordono davvero, le deprecazioni da intercettare prima del deploy, la strategia incrementale per non fermare la produzione e la suite di test che fa da rete. Con le date EOL aggiornate, perché restare su 7.4 nel 2026 non è più un'opzione di sicurezza. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.html) Ultima modifica: Lunedì 31 Agosto 2026, alle 07:56 [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

## [Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/blog/post/porting-funzioni-mysql-verso-mysqli-php.html)

20/05/2026 ![Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/image/000290200-porting-funzioni-mysql-verso-mysqli-php.jpg) Le funzioni mysql_ di PHP sono deprecate dalla 5.5 e rimosse dalla 7.0. Un'applicazione che le contiene ancora gira per forza su una versione di PHP fuori supporto da circa dieci anni: non un problema di stile, ma una falla di sicurezza che cammina. Questo articolo rifà la guida al porting con l'occhio del 2026: cosa fa un convertitore automatico e dove ti lascia scoperto, mysqli o PDO, e perché la posta in gioco non è la deprecazione ma l'SQL injection che il vecchio codice si porta dietro. [Continua a leggere](https://www.mauriziofonte.it/blog/post/porting-funzioni-mysql-verso-mysqli-php.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Code Quality](https://www.mauriziofonte.it/blog/cat/code-quality.html)

## [Automatizzare la revisione tecnica del codice ereditato: dalla paura all'analisi sistematica](https://www.mauriziofonte.it/blog/post/revisione-tecnica-codice-ereditato-analisi-sistematica-metodologia.html)

30/03/2026 ![Automatizzare la revisione tecnica del codice ereditato: dalla paura all'analisi sistematica](https://www.mauriziofonte.it/image/002840200-revisione-tecnica-codice-ereditato-analisi-sistematica-metodologia.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/revisione-tecnica-codice-ereditato-analisi-sistematica-metodologia.html) Ultima modifica: Lunedì 30 Marzo 2026, alle 09:02 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html)

## [Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html)

11/03/2026 ![Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/image/002320200-migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.jpg) Un e-commerce B2B 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:40 [Symfony](https://www.mauriziofonte.it/blog/cat/symfony.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

## [Migrazione da Symfony 5 a Symfony 7: guida pratica con casi reali di breaking change](https://www.mauriziofonte.it/blog/post/migrazione-symfony-5-symfony-7-breaking-change-guida-pratica.html)

23/02/2026 ![Migrazione da Symfony 5 a Symfony 7: guida pratica con casi reali di breaking change](https://www.mauriziofonte.it/image/002520200-migrazione-symfony-5-symfony-7-breaking-change-guida-pratica.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrazione-symfony-5-symfony-7-breaking-change-guida-pratica.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Claude Code](https://www.mauriziofonte.it/blog/cat/claude-code.html)

## [Migrazione PHP 7.4 a 8.3 LLM-assisted: il workflow che trasforma 200.000 righe in settimane invece di mesi](https://www.mauriziofonte.it/blog/post/migrazione-php-74-a-83-llm-assisted-workflow.html)

04/02/2026 ![Migrazione PHP 7.4 a 8.3 LLM-assisted: il workflow che trasforma 200.000 righe in settimane invece di mesi](https://www.mauriziofonte.it/image/003820200-migrazione-php-74-a-83-llm-assisted-workflow.jpg) Migrare 200.000 righe di PHP da 7.4 a 8.3 manualmente è un progetto da 2-3 mesi. Con un workflow LLM-assisted scende a 2-3 settimane senza sacrificare qualità. Nella mia pipeline combino Rector per le trasformazioni meccaniche, Claude per i breaking change complessi, test caratterizzanti generati dal LLM, regression testing incrementale. Ti mostro il workflow reale con tempi giornalieri e le trappole tipiche. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrazione-php-74-a-83-llm-assisted-workflow.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Strategia IT](https://www.mauriziofonte.it/blog/cat/strategia_it.html)

## [Il debito tecnico ha un costo reale: come calcolarlo e presentarlo al management](https://www.mauriziofonte.it/blog/post/debito-tecnico-costo-reale-calcolo-presentazione-management.html)

12/12/2025 ![Il debito tecnico ha un costo reale: come calcolarlo e presentarlo al management](https://www.mauriziofonte.it/image/003260200-debito-tecnico-costo-reale-calcolo-presentazione-management.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/debito-tecnico-costo-reale-calcolo-presentazione-management.html) Ultima modifica: Venerdì 12 Dicembre 2025, alle 07:38 1[2](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=4)[5](https://www.mauriziofonte.it/blog/cat/refactoring.md?page=5)

## Strumenti utili per il refactoring

Tool gratuiti per analizzare il codice esistente:

[Audit del composer.lock](https://www.mauriziofonte.it/strumenti/audit-composer), [Regex tester](https://www.mauriziofonte.it/strumenti/regex-tester).

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about