Recuperare un progetto prima di modificarlo
Nei software longevi, configurazioni e procedure sono spesso distribuite tra codice, server e conoscenza di chi li ha gestiti nel tempo. La prima attività consiste nel ricostruire questa mappa.
Verifichiamo versione di PHP, server web, estensioni, database, attività programmate, invio email, storage e collegamenti esterni. Cerchiamo istruzioni di installazione, configurazioni non versionate e file scritti direttamente dall'applicazione. Separiamo gli elementi necessari da copie e residui che possono confondere la diagnosi.
Nel codice individuiamo punti di ingresso, gestione delle sessioni, accesso al database, librerie incluse e funzioni condivise. Eseguiamo il progetto in un ambiente controllato e annotiamo i passaggi manuali necessari. Senza una riproduzione affidabile, anche una correzione piccola può essere difficile da verificare.
Da questa ricognizione ricaviamo un quadro concreto:
- funzioni e dati maggiormente esposti al cambiamento;
- dipendenze incompatibili o non più mantenute;
- problemi che impediscono aggiornamenti e test;
- rischi di sicurezza da affrontare per priorità;
- attività necessarie prima della nuova funzione richiesta;
Correzione
e sicurezza
Diagnosi degli errori tramite riproduzione controllata del caso, e messa in sicurezza prioritizzata per impatto reale, non per numero di segnalazioni automatiche.
Correggere un errore senza rincorrerne i sintomi
Un messaggio generico o una pagina bianca può essere la conseguenza di dati inattesi, di una query fallita, di un servizio esterno lento o di una configurazione diversa tra ambienti. Raccogliamo log, richiesta, utente, input e stato dei dati in modo da poter riprodurre il caso.
Quando il progetto non dispone di log adeguati, aggiungiamo un tracciamento mirato prima di formulare qualsiasi ipotesi. La correzione viene poi verificata sul caso originale e sui percorsi collegati. Se il problema ha creato record incompleti sul database, prepariamo anche un intervento sui dati, con copia di sicurezza e controlli separati.
Evitiamo patch che si limitano a nascondere l'errore con controlli generici: un valore nullo, ad esempio, può indicare un dato facoltativo oppure una fase del processo saltata per errore. La soluzione corretta dipende dal significato applicativo.
Sicurezza: ridurre l'esposizione per passi verificabili
Nei progetti datati controlliamo soprattutto input, query, caricamento di file, autenticazione, sessioni, autorizzazioni e gestione delle credenziali. Versioni non più supportate di PHP e delle librerie aumentano il rischio, ma l'aggiornamento deve essere pianificato insieme alle incompatibilità che può introdurre.
Gli interventi vengono ordinati per impatto ed esposizione. Possiamo, ad esempio, chiudere prima un accesso non autorizzato o proteggere un caricamento di file, per poi affrontare modifiche più strutturali. La priorità non deriva dal numero di segnalazioni automatiche ricevute, ma dalla possibilità che il difetto venga sfruttato e dai dati coinvolti.
Segreti e configurazioni vengono separati dal repository di codice. Messaggi e log non devono mostrare password, token o dati personali. Se il software è accessibile da internet, verifichiamo anche la configurazione del server e gli eventuali percorsi che aggirano l'applicazione.
Evoluzione
del codice e test
Come introduciamo nuove funzionalità e aggiorniamo versione e librerie senza compromettere ciò che già funziona.
Aggiungere funzioni creando una zona manutenibile
Una nuova funzione non deve necessariamente replicare la struttura più vecchia del progetto. Possiamo invece introdurre un confine chiaro: classi caricate tramite Composer, accesso al database centralizzato, validazione e servizi separati dalla visualizzazione dei dati.
L'obiettivo non è riscrivere ciò che non serve, ma evitare che il nuovo codice aumenti il debito tecnico già esistente. I punti di collegamento con la parte storica del progetto vengono documentati. Se una regola è critica, la estraiamo in una forma testabile e proteggiamo il comportamento attuale prima di modificarla.
Per le API definiamo:
Autenticazione
Permessi
Formato dei dati
Errori e compatibilità
Una nuova interfaccia può così consentire a portali o app di usare le funzioni esistenti senza dover accedere direttamente alle tabelle del database.
Aggiornare PHP e dipendenze senza un salto cieco
Un passaggio di versione può modificare sintassi, tipi di dato, gestione degli errori e comportamento delle librerie. Analizziamo il divario tra ambiente attuale e obiettivo, eseguiamo controlli automatici e costruiamo un elenco delle incompatibilità effettive.
Quando il salto di versione è ampio conviene procedere per versioni intermedie o per componenti. Separiamo le modifiche necessarie alla compatibilità dalle nuove funzioni, così gli errori sono più facili da attribuire. Un ambiente di prova riproduce versione, estensioni e dati realmente significativi.
Le librerie copiate nel progetto possono essere sostituite con pacchetti gestiti soltanto dopo aver verificato eventuali personalizzazioni e le API effettivamente utilizzate. Se una dipendenza non è più mantenuta, valutiamo sostituzione, isolamento o rimozione in base al suo ruolo.
test anche quando il progetto non ne ha
Non è realistico coprire subito anni di codice con dei test. Iniziamo dai percorsi su cui dobbiamo intervenire. Possiamo creare test di caratterizzazione che registrano il comportamento attuale del sistema, per poi aggiungere casi specifici per la correzione o la funzione.
Nei punti difficili da isolare utilizziamo dati di prova e verifiche attraverso l'interfaccia HTTP o procedure ripetibili. Controlliamo sempre autorizzazioni, scritture nel database ed effetti collaterali come email e chiamate esterne.
Ogni rete di sicurezza costruita durante un intervento resta utile anche per le evoluzioni successive. La manutenibilità migliora in modo incrementale, collegata a un lavoro che produce valore.
Due modalità di collaborazione
intervento su progetto
Analizziamo una richiesta o un problema, concordiamo il perimetro, sviluppiamo e consegniamo con istruzioni di verifica e rilascio. La stima distingue attività note e aree ancora da esplorare.
assistenza continuativa
Manteniamo una coda condivisa di correzioni, aggiornamenti ed evoluzioni. Le priorità vengono riviste periodicamente e ogni attività mantiene descrizione, stato e risultato. Questo modello è utile quando il software è operativo ma non giustifica una squadra interna dedicata.
Possiamo lavorare direttamente nel processo del committente, con repository, revisioni e strumenti già utilizzati. Per chi rivende il servizio, comunicazione anticipata dei rischi e consegne verificabili aiutano a proteggere il rapporto con il cliente finale.