Refactoring Bittersweet PHP: Come posso renderlo meno doloroso?

divertente, ho appena risposto qualcosa di simile a questo questo thread .

In poche parole, il cliente non si preoccuperà di come sia realmente il codice, quindi non dovresti neanche farlo.

Vorrei altamente suggerire lo sviluppo di nuove funzionalità utilizzando gli attuali approcci standard OO e solo il refactoring del codice legacy quando assolutamente necessario .

Se il cliente vuole pagarti per il tempo di refactoring più avanti (o vuoi solo prenderti il tempo da te), allora fallo su 'er. Suppongo però che non ti paghino per questo: ti stanno pagando per funzionalità aggiuntive.

Ogni volta che si refactoring il codice, c'è sempre la possibilità di introdurre bug knock-on. Se esegui il refactoring del codice solo per motivi di refactoring e il client trova problemi nell'output, dovrai rispondere ad alcune domande difficili riguardo a perché tu lo ha fatto (e ancora una volta, gestione e client non si preoccupano del fatto che il codice sia migliore o più facile da usare).

Uno dei possibili punti di attacco senza una riscrittura da zero è iniziare con il rilevamento della duplicazione del codice che consente variazioni minori, ad esempio con phpcpd . Può rendere i primi passi ovvi rapidamente.

In realtà, dalla mia esperienza sarebbe meglio se inizi a scriverlo da zero ... Se i requisiti non ti permetteranno di farlo, probabilmente il progetto fallirà. Almeno sarà come in ritardo. E in ritardo intendo che ci vorrebbero 3 volte quello che è in programma.
La mia sincera simpatia.

L'ingegneria del software non è solo una disciplina per scrivere codice; richiede anche la capacità di progettare e testare ciò che si sta creando. Allo stesso modo, il refactoring non si limita a cambiare le linee di codice, devi anche introdurre un design eccezionale e dei test fantastici.

Senza grandi test, inizierai a giocare a whack-a-mole con bug - non sarai mai in grado di raggiungere gli ideali fiduciosi di refactoring senza pietà se hai bisogno di fermarti per capire cosa hai rotto. Quel che è peggio, potresti perdere la fiducia delle imprese introducendo bug nella produzione. A tal fine, i test automatici sono fondamentali. Fortunatamente, anche se il tuo codice non è ancora orientato agli oggetti o ha un design anti-funzionale, puoi sempre implementare test automatici. La creazione di una suite di test per i test di regressione del browser è sempre possibile e ti consiglio vivamente di farlo per le funzionalità prima di rifattorizzare il codice che si trova dietro di esse.

In termini di parte del design; il refactoring può iniziare con un processo di semplice ridenominazione di variabili e metodi in modo da descrivere con precisione cosa sta succedendo. Anche la suddivisione di metodi e classi lunghe in classi più piccole rappresenta un passaggio perfettamente logico nell'identificazione degli odori di codice. Man mano che la tua fiducia nella base di codice si sviluppa, puoi iniziare a garantire che il tuo codice converga verso i principi di Orientamento agli oggetti e SOLID. Tuttavia, ricorda che il refactoring non è un processo che dovresti cercare di completare - aggiungendo più funzionalità alla tua base di codice, la necessità di rifattorizzare senza pietà non finirà. Devi sempre cercare di garantire che il tuo codebase sia il più semplice e leggibile per il lavoro da svolgere.

Ho approfondito i dettagli con le tecnologie e i processi che puoi utilizzare per raggiungere questo obiettivo, insieme a qualche insidia comune, in un post del blog che ho scritto di recente: Refactoring Legacy PHP