Migrazione del codice procedurale legacy in MVC senza riscrittura [chiuso]

1

Recentemente ho iniziato a lavorare su un'applicazione PHP che è stata costruita molti anni fa prima dell'avvento di oggetti e spazi dei nomi in PHP. Il codice è procedurale, non separa la logica di presentazione dalla logica di business, manca un front end point (front controller) e ha file ovunque con una gerarchia di cartelle apparentemente casuale. Tuttavia, funziona benissimo per i clienti e nonostante il pasticcio di codice è in realtà piuttosto veloce.

Mi piacerebbe spostare lentamente il codice base in qualcosa di più gestibile e organizzato. Ho inserito MVC in questo titolo, ma sinceramente tutto ciò che intendo è un servizio organizzato e mantenibile.

Gli obiettivi principali di questo sforzo sono:

  • Non degradare l'esperienza del cliente in alcun modo durante la revisione (una riscrittura non è un'opzione)
  • Separa completamente le viste dalla logica
  • Almeno avere una "best practice" o un metodo per implementare i nuovi end point (percorsi) dell'applicazione
  • Avere un metodo o un livello coerente per i dati persistenti
  • Iniziare a incapsulare il maggior numero possibile di codice negli oggetti in modo che il test delle unità sia fattibile a un certo punto nel tempo.
posta Andy Baird 19.01.2013 - 20:18
fonte

3 risposte

7

OK, farò l'assurdo presupposto che con "senza riscrivere" intendi "senza ricominciare". Perché una volta che il tuo progetto si qualifica come MVC, ne avrai riscritto una parte significativa.

Non ti mentirò, sarà dura. Ma è fattibile.

Letteratura
La prima cosa che ti suggerirei sarebbe di prendere una copia di Michael Feather Lavorare con il codice legacy . È pieno di ottimi consigli su come gestire e lavorare con il tipo di codice che descrivi. Dovresti anche prendere Martin Fowler Refactoring e Joshua Kerievsky Refactoring to Pattern . Queste tecniche saranno molto utili per cambiare il tuo codice.

Come lavorare sul problema
Alcuni punti importanti mentre lavori sul tuo codice sono

  • Evita di mordere più di quanto puoi masticare
  • Mantieni sempre il tuo codice funzionante

Per gestire il primo punto, assicurati di cambiare sempre una piccola parte del tuo codice alla volta. Per il secondo, assicurati di avere un test di accettazione che assicuri di non infrangere il codice mentre lo cambi.

La procedura che ho usato io durante la rielaborazione del vecchio file JSP come il tuo codice era la seguente

  1. Isolare una funzionalità specifica per riscrivere
  2. Scrivi alcuni test di accettazione che controllano il comportamento (il selenio sarà uno strumento molto valido)
  3. Ora la parte divertente. Crea una nuova classe vuota e una UnitTest Suite
  4. Leggi il codice, trova la parte più semplice del codice che puoi inserire nella tua classe
  5. Prova la piccola affermazione
  6. Inserisci il codice dell'istruzione nella tua classe
  7. Sostituisci l'istruzione con una chiamata alla tua classe
  8. Rifatta la tua classe per renderla leggibile, non aver paura di creare nuove classi se vedi emergere più preoccupazioni. Non dimenticare di refactoring anche il tuo test!
  9. Vai a 4 e continua fino a quando tutto il codice è nelle tue classi testate

Ora, mentre estrai il codice procedurale nella tua classe, inizierai a vedere il pattern emerge. La duplicazione diventerà ovvia (il vecchio codice come questo tende ad essere piuttosto copia e incolla). Reingegnerizza la tua classe per riflettere la tua nuova comprensione del problema.

Una cosa che potresti notare è che mentre vai, inizierai ad andare molto più veloce, perché il codice incollato su una copia così prevalente in quelle applicazioni sarà già in una delle tue classi refactored. Quindi incontrerai il codice scritto da un'altra persona e sarai di nuovo lento. È normale.

Non esitare a fermarti di tanto in tanto e sposta il codice nella classe refactored per creare un'architettura più gradevole. Mentre vai, potresti finire con un framework MVCish. Oppure potresti aver a volte adattato il tuo problema a modo suo. La cosa bella è che avrai una bella suite di test per coprirti come fai tu.

Ora, naturalmente, il problema è che vorrete aggiungere funzionalità all'applicazione prima possibile. Puoi usare quello. Quando è necessario aggiungere qualcosa a una parte di codice, eseguire prima il refactoring per quella parte di codice. In questo modo, migliorerai lentamente il design mentre aggiungi funzionalità. Sarà più lento ma a lungo andare andrai più veloce perché il codice sarà più facile da mantenere.

Ti auguro buona fortuna

    
risposta data 20.01.2013 - 01:15
fonte
3

Qualsiasi modifica apportata a un progetto software implica la riconfigurazione (ovvero la modifica dei dati utilizzati dal codice) o la riscrittura (ovvero la modifica del codice stesso). Migrare da uno stile (procedurale) a un altro (orientato agli oggetti) è un cambiamento significativo che comporterà necessariamente un sacco di riscrittura. Il design orientato agli oggetti non è qualcosa a cui puoi pensare in un secondo momento. Adottare un paradigma come model-view-controller significa ripensare e ridisegnare il progetto.

Donald Rumsfeld ha detto famoso:

... vai in guerra con l'esercito che hai, non con l'esercito che vorresti o vorresti avere in un secondo momento.

Sembra che tu abbia bisogno di capire quale esercito hai (quanto puoi ragionevolmente cambiare, quali strumenti e conoscenze hai a tua disposizione) e quale battaglia stai cercando di combattere (di cosa hai veramente bisogno? realizzare?). Non penso davvero che tu possa accedere a MVC senza un sacco di riscrittura, ma potresti essere in grado di riorganizzare il codice per renderlo più facile da capire e mantenere.

    
risposta data 19.01.2013 - 20:57
fonte
-1

Per quanto riguarda la descrizione del tuo progetto, non credo sia possibile migrare questo, senza molte, molte modifiche al tuo codice esistente. Devi ripensare ad ogni funzione del tuo programma per convertirlo in questo "nuovo" paradigma (almeno per la tua applicazione)

    
risposta data 19.01.2013 - 21:20
fonte

Leggi altre domande sui tag