Come affrontare il refactoring di un'applicazione web esistente?

Più o meno allo stesso modo in cui ti avvicini a qualsiasi tipo di codice legacy. Puoi trovare un pezzo testabile, scrivere test per questo e refactoring.

Se non riesci a trovare un pezzo prontamente testabile, dovrai renderlo testabile senza l'imbracatura di sicurezza di una suite di test, nel qual caso cambierai molto attentamente una parte di codice quasi verificabile in modo che sia verificabile .

Codice che non rende le cose al browser - codice "infrastruttura", modelli, materiale che tocca il database - potrebbe essere un buon punto di partenza.

Modifica: test dell'interfaccia utente: con l'avvertimento che ho poca esperienza qui, un mio amico lo fa: esegue una parte del codice di generazione HTML. Quindi esegue l'hacking sul suo codice e confronta il codice appena generato con la vecchia versione (usando diff, non ha automatizzato fino in fondo). Le modifiche nel codice HTML indicano che il tuo refactoring si è rotto.

C'è un grande libro su questo argomento intitolato "Lavorare efficacemente con il codice legacy" di Michael Feathers. Ammettiamolo, abbiamo tutti un codice legacy.

L'importante è testare il nuovo codice che stai creando. Dato che devi toccare altri pezzi di codice, troverai le opportunità per ottenere anche quelli sotto test. È un processo lungo e lento, ma se lo fai sistematicamente, puoi davvero migliorare il prodotto nel tempo.

• Sì - Le applicazioni Web sono diverse dai siti Web

Li tratterei separatamente. Se hai una parte del tuo sito che è semplicemente una raccolta di documenti (che hanno lo stesso aspetto sia per gli utenti anonimi sia per gli utenti registrati), il metodo migliore per strutturarlo è molto diverso da un'app Web che serve pagine dinamicamente diverse a ciascun utente. Suddividi queste due parti del sito in due app / componenti e affronta ogni parte in modo diverso.

• Inizia a utilizzare il controllo della versione

Una volta che il tuo codice è sotto controllo di versione, puoi passare e, con sicurezza, rimuovere tutto il codice non necessario che avevi precedentemente conservato "nel caso" ecc. Non so come sono sopravvissuto senza il controllo della versione.

• Riduci gli infiniti

Se quattro diversi URL puntano tutti alla stessa risorsa, il problema è molto più grande. Finisci per gestire una quantità infinita di URL. Appena possibile, assicurati di avere una politica di normalizzazione degli URL in atto. Una volta fatto, puoi iniziare ad associare significati semantici agli URL ed essere in grado di fare ricerche inverse da resource-in-url. Ciò ti consente di separare la "impronta web" dalle "risorse" del sito.

Devi chiedertelo, "dato un URL qual è la sua forma normalizzata?". Una volta che ti sei bloccato. Quindi 500000+ url sul tuo sito possono essere ridotti a 2.000. che è molto più facile da comprendere e gestire nella tua mente.

vedi: link

• Inizia modellando "cosa è", non "cosa vuoi che sia"

Se stai riordinando un sito legacy, questo non è stato progettato fin dall'inizio con le migliori pratiche, quindi è tentato di passare da "un disastro" a "il design ideale". Credo che sia necessario farlo in almeno due passaggi: "mess" - > "codice legacy ben modellato" - > 'nuovo codice ideale con funzionalità aggiunte'. Smetti di aggiungere funzionalità. Concentrati sulla riparazione del casino o incapsulandolo dietro un livello anti-corruzione. Solo allora, puoi iniziare a cambiare il design in qualcosa di meglio.

Vedi: link

Vedi: link

• Metterlo sotto test è una buona idea.

Crea una suite di test / framework e inizia ad aggiungere test. Ma è abbastanza complicato testare qualche codice legacy. Quindi, non ti agitare troppo. Finché hai il quadro lì, puoi aggiungere test poco alla volta.

Vedi: link

• Abbi coraggio nelle tue convinzioni

La maggior parte della letteratura sulle migliori pratiche di sviluppo del software è centrata sul desktop / Enterprise App Centric. Mentre il tuo sito è in disordine leggi questi libri e puoi essere ammirato dalla saggezza che emana da loro. Ma, non dimenticare che la maggior parte di questa best practice è stata accumulata in tempi precedenti prima che il web / SEO diventasse importante. Conosce molto sul web moderno, più di quanto si pensi nei libri classici come POEA, Gof, ecc. C'è molto da imparare da loro, ma non abbandonare completamente la propria esperienza e conoscenza.

Potrei andare avanti. Ma quelle sono alcune cose che ho scelto quando refactoring un vecchio sito legacy in uno nuovo brillante.

Prima di fare qualsiasi cosa, è meglio avere il tuo progetto nel controllo del codice sorgente. In questo modo, puoi eseguire il rollback delle modifiche o lavorare sulle principali modifiche su un ramo separato, oltre che sui tag milestone.

Quindi, scrivi test per qualsiasi codice che intendi modificare. Non è necessario fare tutto in una volta, scrivere test per tutto. Proprio quello su cui pensi di lavorare immediatamente. La teoria dice che dato abbastanza tempo, la maggior parte della base di codice sarà coperta da test. Nota che alcuni refactoring sono "sicuri" da fare senza test: questi sono documentati nel libro Codice precedente menzionato prima, e senza dubbio altrove.

Con i test in atto per una sezione di codice, modificare il codice. Fai tutto il necessario, purché i test continuino a passare.

Anche con il codice legacy, puoi fare TDD se fai aggiunte o modifiche. Basta scrivere prima i test per le modifiche previste, vederli fallire e quindi apportare le modifiche.

Alcuni strumenti potrebbero essere utili qui. NDepend può indicare codice altamente accoppiato e altri odori. NCover tiene traccia dei livelli di copertura del codice. FxCop è essenzialmente un correttore di correttezza del codice, oltre a ciò il compilatore lo fa. Questi sono tutti strumenti utili da avere a portata di mano per un progetto di qualsiasi dimensione reale, specialmente la varietà legacy.

In definitiva, è un processo in più fasi. Non provare a farlo tutto in una volta, basta prenderlo un po 'alla volta.

Se è abbastanza brutto da farmi incazzare, è abbastanza brutto da cancellare l'intera faccenda e scrivere una goccia in sostituzione.

Troverete che il più delle volte, ci vuole la stessa quantità di tempo per farlo, come fa per sedersi lì e in punta di piedi intorno a un disordine non organizzato e non documentato e accarezzarlo dolcemente.