Approccio generale al ri-factoring di un sistema legacy grande, scritto molto male [duplicato]

7

Domanda davvero aperta qui. Non sto cercando una risposta .. solo un consiglio. Qualsiasi esperienza passata che le persone hanno avuto con il ri-factoring dei sistemi legacy che potrebbero trasmettere sarebbe sorprendente. Ecco alcune informazioni sul software che sto per ri-fattore (ti rabbrividire!):

  • Applicazione Web
  • Basato su database (MySQL)
  • PHP4 e PHP5
  • La maggior parte del codice è PHP4
  • Quasi tutto il codice è procedurale
  • Il codice che è PHP5 non è OO .. esempio: 10.000 righe + file con una classe e una funzione
  • Variabili globali utilizzate ovunque
  • Non è stato utilizzato alcun controllo sorgente per scrivere il software (puoi vedere dai commenti nel codice)
  • Grandi quantità di ripetizione del codice
  • Nessuna separazione di dubbi: l'interfaccia utente e la logica sono combinate ovunque
  • L'applicazione si basa sull'ordine delle tabelle del database
  • Pochi commenti al codice
  • 250.000 righe di codice
  • Applicazione in uso intensivo

Fondamentalmente, il software è il nostro prodotto principale e io sono stato assunto per fare un importante ri-fattore (tra le altre cose). È un compito enorme e non posso semplicemente immergermi e sistemare tutte le piccole cose .. Ho bisogno di una strategia globale. Ho scritto alcuni script per riordinare i rientri, rimosso il codice commentato ovunque e ho trasformato il progetto in un repository, ma ora è il momento di fare il vero.

Ho una specie di idea vaga ma non sono sicuro di come procedere. Potrei in qualche modo lasciare il codice corrente da solo e scrivere su di esso uno strato di software che astrae tutto l'orribile. Sarebbe bello se il nuovo livello fosse una sorta di architettura MVC. Allo stesso tempo, andrei nel codice corrente, rimuoverò le ridondanze perché altrimenti il nuovo livello userebbe comunque codice cattivo, quindi il codice potrebbe rallentare ancora di più.

Come puoi vedere .. hai bisogno di alcuni indizi / suggerimenti / consigli / consigli / esperienze!

Grazie mille:).

    
posta ale 13.01.2012 - 13:11
fonte

1 risposta

13

Ingegneria inversa testata

  1. Reverse engineer alcuni user epics; non tutte le storie, ma le suite di funzionalità "big picture" che compongono il sistema.

  2. Stabilisci priorità in base a qualità, sostituibilità, valore, ecc. ecc. Questo è soggettivo, ma devi scegliere un pezzo su cui lavorare.

  3. Scrivi i test delle unità nel modo migliore possibile per passare il codice precedente.

  4. Scrivi un nuovo codice solo per quello.

Ora arriva la parte difficile. Ponti.

Devi implementare la nuova parte e mantenere l'eredità mentre stai andando avanti. Dovrai "collegare" i dati da legacy a nuovi (e nuovi da legacy).

Dovrai anche scrivere una serie di regole di riscrittura di Apache per reindirizzare le richieste al nuovo in modo che gli URL non sembrino cambiare troppo o in modo troppo disordinato. Alcuni cambiamenti sono inevitabili come la tua riscrittura. Alcuni cambiamenti sono dirompenti per gli utenti e richiedono mod_rewrite o 304 reindirizzamenti o entrambi.

Una volta che hai realizzato la prima epica (serie di storie) distribuita in produzione, devi ripensare alle tue epopee e alla decomposizione di ciò che è rimasto nell'eredità che è ancora prezioso. Reprioritize.

Scrivi i test unitari per la prossima epopea. Riscrivi il codice. Crea e rivedi i ponti. Distribuisci il blocco successivo.

Ripeterai il ciclo "partizione, priorità, test, refactoring, deploy" fino a quando ciò che rimane come legacy è di così poco valore che non avrai più bisogno di bridge. Quindi decolli il vecchio. Elimina il codice. Brucia i ponti. Non tornare indietro.

    
risposta data 13.01.2012 - 13:23
fonte

Leggi altre domande sui tag