Avvio di un'architettura coerente in un'applicazione legacy

Ho la responsabilità di un grande sito Web basato su Asp.Net. Attualmente è un sito Web (non un'applicazione Web), alcuni servizi di Windows e una serie di librerie di classi.

Il livello dati utilizza una combinazione di LLBLGEN e Linq To LLBGen, nonché una serie di istanze di SQL inline legacy che non sono state refactored.

Esistono alcune implementazioni di tipo manager, ma in molti casi l'applicazione mostra l'anti-pattern Smart UI (ovvero troppa logica aziendale nel codice dietro le classi)

Il sito ha un traffico ragionevolmente elevato e le prestazioni vanno bene, ma stiamo aumentando la nostra capacità di sviluppo a un team di circa 10 persone, ed è sempre più evidente che abbiamo bisogno di un design a più livelli sovrapposto al middleware esistente.

La mia domanda è da dove iniziare? Abbiamo 10 anni di codice (alcuni dei quali sono ancora migrati in ASP Classic), molti approcci e stili diversi.

Il refactoring dell'intera base di codice non è realistico e, probabilmente, non è auspicabile

So che questa non è una situazione nuova, ci sono idee o concetti utili su come affrontare questo problema?

Ho anche lavorato in situazioni simili e posso darti i seguenti consigli.

1. È necessario ridurre il debito tecnico . Adesso. Perché? Perché il debito tecnico è come il debito finanziario. Pagherai interessi su di esso.
2. Dal momento che il refactoring dell'intera base di codice non è fattibile, 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 toccato dal team deve essere riparato / refactored secondo il nuovo standard ". In genere: i test unitari devono essere scritti, il codice deve essere spostato nei livelli corretti, ecc. Ciò consente di correggere molto codice senza ricorrere a progetti di "refactoring" ridicolmente costosi e di basso valore.
4. Avvolgere la merda. Il disaccoppiamento è la chiave per il refactoring e la buona architettura. Se puoi in qualche modo partizionare la base di codice, puoi forse refactificare 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 sul fatto che il refactoring dell'intera base di codice non è desiderabile. Il refactoring è qualcosa che fai prima del nuovo sviluppo per renderlo più fluido. Se non hai intenzione di modificare tutto il codice nella tua base di codice, il refactoring dimostrerà un uso inefficiente del tempo.

Alcuni consigli oltre a ciò che dice Sklivvz:

1. Separare il codice in sezioni modificate frequentemente e raramente. Solo le sezioni frequentemente modificate devono essere completamente integrate nella nuova architettura. Integra il codice modificato di rado con la nuova architettura utilizzando il minor numero possibile di modifiche (o nessuna modifica se riesci a cavartela). Resistere alla tentazione della riscrittura completa, costerà più di quanto tu guadagni da esso. Apprezzo che il codice esistente funzioni, anche se è brutto.

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

3. Cerca di trovare quante più architetture di riferimento possibile 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 della gestione delle persone. Nei miei progetti di migrazione, la parte più difficile era far sì che le persone imparassero i nuovi modi e si attenessero a loro. Avrai bisogno di implementazioni di riferimento e un modo per insegnare l'architettura a tutti i membri del team (sia vecchi che nuovi). Per ridurre la resistenza ai cambiamenti, chiedi il contributo di 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 salto così grande che si sentono fuori dalla loro profondità.

La cosa PIÙ importante che ho visto quando ho provato a gestire una vecchia base di codici è NON continuare a cambiare ciò per cui stai sparando. Cioè, capire la tua architettura desiderata, quindi STICK CON QUESTO PIANO! Uno dei maggiori problemi della mia ultima posizione era che la base di codice aveva diverse idee su come dovrebbe apparire nel tempo. Ogni volta che veniva provata una nuova idea, parte del codice veniva convertito, altri no, e poi qualcun altro aveva un'idea "migliore". È diventato sempre più incoerente nel tempo e alla fine è stato demolito.

Esiste un bel libro / pdf gratuito sul software legacy di reingegnerizzazione: http://scg.unibe.ch/download/oorp/

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

Se non ha un'architettura coerente, è perché il management non capisce / si preoccupa del problema. Basta codificare. Dovresti introdurre una nuova buona architettura mentre scrivi un nuovo codice.

Dovresti riprogettare le cose solo se iniziano a presentare bug davvero seri, devi estenderle e semplicemente non possono, o semplicemente non soddisfano i suoi requisiti.

In pratica sto solo dicendo che si preoccupano dei problemi che interessano davvero i tuoi manager, non di quelli a cui potrebbero interessare se avessero le tue conoscenze.

Se puoi vendere la re-architettura alla direzione, inizia con i test. Se non vogliono investire nei test, i tuoi sforzi ti daranno solo problemi.