Audit tecnico iniziale di un progetto PHP legacy: metodo operativo per i primi 30 giorni

Quando un titolare di PMI mi chiede "quanto costa sistemare il nostro gestionale PHP?", la mia risposta è sempre la stessa: non lo so, e chiunque ti dia un numero senza prima fare un audit mente o indovina. Un audit tecnico iniziale è il primo investimento sensato su un progetto PHP legacy - è l'equivalente di una radiografia prima di un intervento chirurgico. Senza audit, qualsiasi preventivo di refactoring è una scommessa.

A gennaio 2025 un cliente friulano - PMI del settore arredamento, 20 dipendenti, gestionale PHP 7.0 custom per ordini, preventivi e gestione produzione - mi ha chiesto esattamente questo: "abbiamo un gestionale che funziona, lo sviluppatore è sparito, non sappiamo quanto sia messo male, e dobbiamo decidere se investire o riscrivere". In 30 giorni ho prodotto un audit completo - inventario tecnico, analisi di sicurezza, classificazione del debito tecnico, mappatura delle dipendenze e una roadmap con tre scenari di intervento e i relativi costi. Quel documento è stato la base per una decisione informata che ha fatto risparmiare al cliente oltre 60.000 euro rispetto al big rewrite che stava considerando. In questo articolo ti racconto il metodo.

Stai cercando un Consulente Informatico esperto per un audit del tuo progetto PHP legacy? Nel mio profilo professionale trovi l'esperienza concreta su analisi tecnica, valutazione del debito e roadmap di modernizzazione. Contattami per una consulenza diretta.

Settimana 1: l'inventario tecnico - capire cosa hai

Il primo deliverable dell'audit è un inventario tecnico completo che risponde alla domanda: cosa c'è in questo progetto? La risposta non è ovvia: senza documentazione, anche chi usa il gestionale ogni giorno non sa quanti file ci sono, quali librerie usa, quali servizi esterni chiama, o quanto è grande il database.

# Script di inventario tecnico (eseguo sul server di produzione)
echo "=== DIMENSIONI ==="
find . -name "*.php" -type f | wc -l           # file PHP
find . -name "*.php" -type f | xargs wc -l | tail -1  # righe totale
du -sh . --exclude=vendor --exclude=node_modules # dimensione codice

echo "=== VERSIONI ==="
php -v | head -1
mysql --version
nginx -v 2>&1

echo "=== DIPENDENZE ==="
test -f composer.json && composer show --locked | wc -l || echo "No Composer"
test -f package.json && cat package.json | jq '.dependencies | length' || echo "No npm"

echo "=== DATABASE ==="
mysql -u root -p -e "
SELECT table_schema, 
       COUNT(*) as tables,
       ROUND(SUM(data_length + index_length)/1024/1024, 2) as size_mb
FROM information_schema.tables 
GROUP BY table_schema;"

echo "=== COMPLESSITÀ ==="
# Complessità ciclomatica con phploc (se disponibile)
vendor/bin/phploc --count-tests src/ 2>/dev/null || echo "phploc non installato"

Nel caso friulano: 43.000 righe PHP su 312 file, PHP 7.0 (fine supporto sicurezza dal novembre 2019 - cinque anni senza patch di sicurezza), nessun Composer (librerie copiate a mano in una directory libs/), database MySQL 5.7 da 4.2 GB con 127 tabelle, e un'interfaccia frontend in jQuery 1.x con Bootstrap 3.

Settimana 2: analisi di sicurezza e debito tecnico

La seconda settimana produce il report di sicurezza e la classificazione del debito tecnico. PHPStan per l'analisi statica generale e Psalm con taint analysis per la sicurezza sono i due strumenti chiave.

# PHPStan: analisi statica (livello 0 per legacy estremo)
composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src/ --level 0 --error-format=json > phpstan-report.json
echo "Errori trovati: $(jq '.totals.errors' phpstan-report.json)"

# Psalm: taint analysis per vulnerabilità di sicurezza
composer require --dev vimeo/psalm
vendor/bin/psalm --init
vendor/bin/psalm --taint-analysis --output-format=json > psalm-security.json

Il report PHPStan del progetto friulano ha trovato 847 errori al livello 0 - variabili undefined, classi non trovate, tipi incompatibili. Il report Psalm ha trovato 9 SQL injection, 17 XSS e 2 file inclusion vulnerabili. La classificazione del debito tecnico che produco usa tre categorie:

• Debito critico (fix entro 2 settimane): vulnerabilità di sicurezza sfruttabili, PHP non supportato, credenziali esposte
• Debito alto (fix entro 3 mesi): assenza di test, codice non versionato, backup non testato, assenza di logging
• Debito medio (fix entro 12 mesi): dipendenze obsolete ma funzionanti, codice duplicato, assenza di pattern architetturali

Ho descritto l'audit di sicurezza specifico per PHP legacy - con la checklist delle 7 vulnerabilità più comuni e le tecniche di remediation - in un articolo dedicato.

Settimana 3: mappatura delle dipendenze e dei flussi critici

La terza settimana mappa le dipendenze del sistema - non solo le librerie PHP, ma i servizi esterni, le integrazioni, i cron job, i flussi dati tra sistemi. Questa mappa è fondamentale per capire l'impatto di qualsiasi intervento: modificare il modulo ordini potrebbe rompere la sincronizzazione con il gestionale contabile se non sai che esiste un cron notturno che li collega.

Nel caso friulano, la mappatura ha rivelato 4 integrazioni esterne che nessuno aveva menzionato: un web service SOAP verso il gestionale contabile, un'API REST verso il configuratore prodotti del sito web, un export CSV notturno verso il sistema di logistica del magazzino, e una sincronizzazione email via IMAP per l'acquisizione automatica degli ordini ricevuti via PEC. Ciascuna di queste integrazioni era un punto di accoppiamento che qualsiasi intervento di refactoring doveva preservare.

Settimana 4: la roadmap con tre scenari

L'ultimo deliverable è il documento che il titolare aspetta: la roadmap di intervento con costi, tempi e rischi per ciascun scenario. Presento sempre tre scenari:

Scenario A - Manutenzione conservativa (costo basso, rischio alto a lungo termine): fix delle vulnerabilità critiche, aggiornamento PHP a 8.x, introduzione di Git e backup. Non si tocca l'architettura. Tempo: 2-4 settimane. Costo: 5.000-10.000 euro. Il sistema resta manutenibile per 2-3 anni ma il debito tecnico continua a crescere.

Scenario B - Refactoring incrementale (costo medio, rischio basso): tutto lo scenario A più refactoring graduale con Strangler Fig Pattern, introduzione di test, modernizzazione progressiva. Tempo: 3-6 mesi. Costo: 15.000-30.000 euro. Il sistema diventa manutenibile a lungo termine.

Scenario C - Riscrittura completa (costo alto, rischio alto): nuovo sviluppo da zero su Laravel/Symfony. Tempo: 8-14 mesi. Costo: 60.000-120.000 euro. Rischio: perdita di conoscenza di business codificata nel vecchio sistema, doppia manutenzione durante la transizione.

Il cliente friulano ha scelto lo scenario B. Dopo tre mesi di refactoring il gestionale era sotto Git con test, vulnerabilità chiuse e i moduli più critici riscritti in codice moderno. Il costo totale è stato 22.000 euro - un terzo dello scenario C, con rischio molto inferiore.

Per il passo precedente al refactoring - mettere il codice sotto version control - rimando alla guida sull'implementazione di Git su sistemi legacy in produzione, e per il subentro senza lo sviluppatore originario che è spesso il contesto in cui l'audit viene richiesto.

Un audit tecnico non è un costo - è l'investimento che previene tutti i costi inutili che vengono dopo. Senza audit, qualsiasi decisione sul futuro del tuo software è basata su supposizioni. Con l'audit, hai numeri, evidenze e scenari concreti su cui basare una decisione informata. Se il tuo progetto PHP legacy ha bisogno di una radiografia prima dell'intervento, contattami.