Ti darò la nostra esperienza refactoring LedgerSMB. Abbiamo preso la decisione di fare le cose in modo diverso all'inizio e stiamo ancora facendo esattamente quello che descrivi ma senza molti metodi di incollaggio (abbiamo alcuni metodi di incollaggio, ma non molto).
Vita con due Codebase
LedgerSMB è sopravvissuto con due codebase per circa 5 anni e sarà diverso ancora prima che il vecchio codebase venga eliminato. Il vecchio codebase è un vero orrore da vedere. Bad db design, Perl costruisce come IS->some_func(\%$some_object);
insieme al codice che mostra esattamente il motivo per cui la metafora degli spaghetti viene talvolta usata (percorsi di esecuzione che si snodano tra moduli e back, e tra lingue, senza rima o motivo). Il nuovo codebase lo evita spostando le query db in stored procedure, con un framework più pulito per la gestione delle richieste e molto altro ancora.
La prima cosa che abbiamo deciso di fare era provare a refactoring modulo per modulo. Ciò significa spostare tutte le funzionalità in un'area specifica in un nuovo modulo e quindi agganciare il vecchio codice nel nuovo modulo. Se la nuova API è pulita, questo non è un grosso problema. Se la nuova API non è un problema, è un invito a lavorare un po 'di più sulla nuova API ....
La seconda cosa è che ci sono molte volte in cui il nuovo codice deve accedere alla logica nel vecchio codice. Questo deve essere evitato nella misura del possibile perché porta a metodi di incollaggio che sono brutti ma non sempre è possibile evitarlo. In questo caso i metodi di colla dovrebbero essere minimizzati ed evitati nella misura del possibile ma usati quando necessario.
Per fare questo lavoro devi impegnarti a riscrivere le funzionalità tutte in un'area specifica. Se è possibile, ad esempio, riscrivere tutto il codice di tracciamento delle informazioni dei clienti in una sola volta, significa che il codice che chiama questo dal vecchio codice non è difficile da utilizzare e l'invio al vecchio codice dal nuovo codice è ridotto al minimo.
La seconda cosa è che se hai astrazioni ragionevoli al tuo posto, dovresti essere in grado di scegliere quale livello dell'API chiamare e come mantenerlo pulito. Tuttavia, dovresti pensare a riscrivere le parti che chiamano la tua API in modo che siano anche un po 'più pulite.
Esistono molte aree di strumenti aziendali irriducibilmente complessi. Non puoi liberarti di ogni complessità. Ma puoi gestirlo concentrandoti sulle API pulite che fanno specificamente ciò che devi fare e sui moduli che utilizzano questa API in modo costruttivo. La colla dovrebbe essere l'ultima risorsa solo dopo aver considerato che la riscrittura del resto del codice chiamante potrebbe essere più veloce.