Avvio di un'architettura coerente in un'applicazione legacy

Ho anche lavorato in situazioni simili e posso darti il seguente consiglio.

1. Devi ridurre il debito tecnico . Adesso. Perché? Perché il debito tecnico è come il debito finanziario. Pagherai interessi su di esso.
2. Dato che non è fattibile refactoring dell'intero codice base, chiediti: cosa lo impedisce? È semplicemente troppo lavoro? Perché?
3. Crea un piano per ridurre il debito tecnico nel tempo. Ad esempio, impostando le regole come " ogni bit di codice che viene toccato dal team deve essere corretto / refactored al nuovo standard ". Tipicamente: i test unitari devono essere scritti, il codice deve essere spostato nei livelli corretti, ecc. Ciò consente di correggere un sacco di codice senza ricorrere a progetti di "refactoring" ridicolmente costosi e di basso valore.
4. Avvolgi la merda. Il disaccoppiamento è la chiave per il refactoring e la buona architettura. Se è possibile suddividere in qualche modo la base del codice, è possibile eseguire il refactoring dei bit più piccoli.
5. Non aumentare ulteriormente il debito tecnologico. Non aumentare ulteriormente il debito tecnologico. Non aumentare ulteriormente il debito tecnologico. Non ...

Hai ragione che non è opportuno refactoring dell'intera base di codice. Il refactoring è qualcosa che fai prima del nuovo sviluppo per rendere lo sviluppo più fluido. Se non hai intenzione di modificare tutto il codice nella tua base di codice, il refactoring sta dimostrando un uso inefficiente del tempo.

Alcuni consigli oltre a quello che dice Sklivvz:

1. Separa il codice in sezioni frequentemente e raramente modificate. Solo le sezioni modificate frequentemente devono essere inserite completamente nella nuova architettura. Integra il codice modificato di rado con la nuova architettura utilizzando il minor numero possibile di modifiche (o nessuna modifica se puoi farla franca). Resisti alla tentazione della riscrittura completa, costerà più di quanto ne guadagni. Apprezzo che il codice esistente funzioni, anche se è brutto.

2. Scopri qual è il tuo obiettivo di refactoring. Vuoi rendere più facile ottenere contenuti nel sito? Hai molti bug e vuoi migliorare la qualità percepita dagli utenti? Preferisci invece ridurre i tempi di sviluppo delle funzionalità? O vuoi principalmente un UX migliore? La tua architettura dovrebbe semplificare il codice refactoring per raggiungere gli obiettivi che hai impostato. Non dimenticare mai che il principale beneficiario del tuo refactoring dovrebbe essere il tuo utente / cliente / azienda. Il codice Cleaner non è un obiettivo di per sé, è un metodo per un fine e la fine coinvolge un utente.

3. Cerca di trovare il maggior numero possibile di architetture di riferimento e non aver paura di copiarle. Non reinventare la ruota. Se qualcun altro ha un'architettura che funziona bene per siti come il tuo, impara da loro.

4. Pensa al lato gestione delle cose delle persone. Nei miei progetti di migrazione la parte più difficile è stata far sì che le persone imparassero i nuovi modi e si attenessero a loro. Avrai bisogno di implementazioni di riferimento e un modo di insegnare l'architettura a tutti i membri del team (sia vecchi che nuovi). Per ridurre la resistenza al cambiamento, chiedere informazioni a tutti i membri del team prima di prendere decisioni. Assicurati che il nuovo design migliori effettivamente le cose dal punto di vista personale degli sviluppatori, e non è un grande salto che sentono fuori dalla loro profondità.

La cosa più importante che ho visto quando ho cercato di gestire un vecchio codice è NON continuare a cambiare per quello che stai girando. Cioè, scopri la tua architettura desiderata, poi MANCA CON QUESTO PIANO! Uno dei problemi più grandi della mia ultima posizione è stato il fatto che il codebase aveva diverse idee su come dovesse apparire nel tempo. Ogni volta che veniva provata una nuova idea, parte del codice veniva convertita, altre no, e poi qualcun altro aveva un'idea "migliore". È diventato sempre più incoerente nel tempo e alla fine è stato demolito.

C'è un bel libro / pdf gratuito sul reingegnerizzazione del software legacy: link

Dice OO nel titolo ma la maggior parte delle idee si applica a qualsiasi software. Discute da dove iniziare, come trattare le diverse parti di un sistema durante la ristrutturazione e molti altri argomenti.

Se non ha un'architettura coerente, è perché la gestione non capisce / cura del problema. Basta programmare via. Dovresti introdurre una nuova buona architettura mentre scrivi nuovo codice.

Dovresti ri-progettare le cose solo se iniziano a generare bug veramente gravi, devi estenderlo e semplicemente non possono, o semplicemente non corrisponde ai suoi requisiti.

In pratica sto dicendo che mi interessano solo i problemi ai quali i tuoi dirigenti si interessano veramente, non i problemi di cui si preoccuperebbero se avessero la tua conoscenza.

Se puoi vendere la re-architettura alla gestione, inizia con i test. Se non vogliono investire in test, i tuoi sforzi ti procureranno solo problemi.