Come avvicinarsi al modello BIG BALL OF MUD dal POV architettonico? [duplicare]

Che cosa significa in realtà un punto di vista architettonico ? Una definizione possibile è "il totale di tutte le decisioni di progettazione che sono difficili da modificare in seguito" - se sono facili da modificare in seguito, ad esempio sostituendo una propria classe di stringa in std::string , sono dettagli di implementazione. Le decisioni architettoniche tipiche sono la scelta del linguaggio di programmazione, la scelta del framework, la decisione su quale tipo di logica implementare in quale layer della vostra applicazione, o la struttura dei componenti di un sistema (o l'assenza di quest'ultimo).

Quindi la risposta alla tua domanda

are there any (low cost) strategies

se ovviamente no , poiché "low cost" significherebbe "facile cambiare", quindi in contraddizione con il significato di "architettonico".

Nota Non sto dicendo che non è possibile modificare o migliorare un'architettura di una base di codice legacy. Questo è perfettamente possibile, ma in genere richiede molto sforzo, come descritto qui . Un modo ovvio è di riscrivere il software o parti isolate di esso da zero (nota che non lo consiglio, tuttavia, ci sono situazioni dove questa è la tua unica opzione sensata ). La situazione

unclear division of GUI and Business Logic

è spesso più facile da risolvere. Si deve rifattorizzare le parti della logica aziendale non-GUI fuori dalla GUI - una finestra di dialogo / forma / schermo alla volta. Tuttavia, dal momento che hai scritto che gli utenti sono soddisfatti della GUI, ti consiglio di applicare questo tipo di refactoring solo per le parti della GUI che devi davvero modificare, e non "just in case".

Il mio approccio è di iniziare a suddividere le lezioni nelle proprie librerie. Scopri quali classi sono strettamente accoppiate e il grafico delle dipendenze per loro.

Elimina un corso e ricompila. vedere quali interruzioni, aggiungere la nuova libreria, ricompilare ... ecc.

Ciò ti consente di eliminare il sistema e ottenere blocchi gestibili che puoi ulteriormente ridefinire nei servizi o in qualsiasi altro momento.

Non penso sia possibile dare più quel consiglio generale. Non esiste una soluzione magica adatta a tutte le soluzioni per "modificare l'architettura di questo software da A a B"

La maggior parte degli sviluppatori tendono a vedere compiti come quelli architettonici, mentre sono di natura amministrativa. Per implementarlo correttamente, è necessario modificare il flusso di lavoro, non il codice! Considera, cosa succederebbe se, dopo tutte le tue correzioni, la vecchia squadra tornasse e continuasse i suoi vecchi modi? La maggior parte del tuo lavoro verrebbe sprecata immediatamente!

Nota che il tuo comando non sarà in grado di ottenere miglioramenti senza il supporto delle parti interessate. Nella maggior parte dei casi, ciò significa che stai chiedendo l'impossibilità, in quanto il capo squadra non è in grado di comunicare il concetto di debito tecnico al proprietario del prodotto. Il tuo compito come sviluppatore è quello di raccogliere prove obiettive, che l'architettura corrente diminuisce il valore del progetto del progetto rallentando il progresso e introducendo bug.

Non cambiare nulla senza una ragione. Non iniziare mai nessuna modifica solo perché non ti piace l'implementazione corrente.

Introduci le politiche applicate dal capo squadra e seguite da tutti:

• L'integrazione continua e la pre-convalida non sono un'opzione - lo sono supporto vitale.
• Revisione del codice: nessuna modifica deve essere unita fino a quando non viene completata passa l'intera suite di test e una revisione da parte di un altro sviluppatore.
• Ogni modifica dovrebbe migliorare le proprietà architettoniche del codice base. Ciò implica qualsiasi refactoring necessario per raggiungere un determinato compito, ma niente di più. I modi esatti per farlo potrebbero essere ottenuti da altre risposte, ma non dovrebbero. È responsabilità del tuo team sia migliorare la progettazione attuale sia mantenere un minimo di modifica. In particolare, la maggior parte dei test di integrazione non richiede una grande riscrittura, e il test non dovrebbe essere un motivo per toccare migliaia di file che introducono la testabilità dell'unità.
• Ogni cambiamento dovrebbe introdurre più esami rilevanti di passaggio (qualsiasi tipo di test automatici, non necessariamente unità).
• Ogni correzione di bug dovrebbe includere un test di regressione che fallisce prima di cambiarlo e passarlo dopo.
• Con ogni revisione del codice, discuti le decisioni più importanti prese e riutilizzate loro nelle revisioni seguenti. Non cercare di documentarli, non è così lavorare, basta sviluppare la sinergia del tuo team e propagarlo usando recensioni. Le decisioni possono includere alcune modifiche architettoniche proposte in altre risposte, il risultato esatto è irrilevante, cerca solo di usare la tua esperienza di membri rispettati.

Questi requisiti rafforzano la propagazione dell'esperienza e facilitano la coerenza nella base di codice. Sfortunatamente si basano molto sull'esperienza personale dei membri del tuo team, quindi il successo del team sarà limitato dal tuo miglior senior. Questo è inevitabile, ma può essere alleviato un po 'imparando le migliori pratiche da fonti esterne come questo SE.

Questo non significa che devi lasciare il casino com'è. Per ogni richiesta di modifica del comportamento funzionale o di correzione di un bug, esaminare un ambito di modifica. L'ambito dovrebbe includere il necessario refactoring che lascerebbe uno stato più pulito e una buona copertura di prova. Tale ambito sarebbe grande fintanto che il codice base è un casino. Ridurrà di dimensioni se seguirai sempre il principio del boy-scout. La chiave del successo è riutilizzare le risorse già esistenti, introducendo il nuovo valore in modo incrementale.

Come detto non ci sono soluzioni "One Size Fits All" ma ci sono un paio di buone pratiche o CYA, cover your assets, punti da considerare prima di iniziare.

1. Ottieni o decodifica una specifica funzionale e prendi d'accordo per iscritto che è ciò a cui devi mirare tutti dei soggetti interessati. Non permettere a nessuno di farla franca "deve solo fare lo stesso del sistema esistente!"
2. Scrivi un, preferibilmente automatico , serie di test che dimostra che l'attuale implementazione soddisfa quei requisiti (o dove non lo fa). Cerca la copertura più vicino al 100% comportamentale possibile.
3. Identifica un insieme di strumenti che possono, di nuovo preferibilmente automaticamente , fornire metriche su cose come livello di accoppiamento, complessità del codice, ecc. e registrare quelle metriche per il tuo punto di partenza: il vecchio sistema. È bello se le metriche sono ampiamente utilizzate e hanno accettato livelli desiderabili che il tuo codice attuale non soddisfa, e.g. Ho un sistema per cercare di risolvere il problema con un McCabe massimo di 650 - il nostro standard di codifica dice che qualsiasi cosa su 10 è indesiderabile, oltre 15 devono essere giustificati e oltre 20 devono essere corretti.
4. Fai uno snapshot dell'implementazione esistente su cui puoi (ri) eseguire i test.
5. Fai sicuro sai dove tutto del sistema esistente è, ad es. facendolo funzionare su un nuovo hardware di test - su tali sistemi ci sono spesso parti nascoste, non documentate, di funzionalità - ad es. librerie di sistema patchate, utility o file di dati in posizioni non documentate e oscure, ecc.

Dato quanto sopra, puoi iniziare a rilassare la sfera di stringa e separare la logica di business dalla GUI con una certa certezza che:

a) Non stai cambiando il comportamento o che lo stai solo modificando in modi desiderabili .

b) Sarai in grado di dimostrare tramite i tuoi test e le tue metriche i miglioramenti che stai apportando.

c) Potresti anche essere in grado di focalizzare il tuo sforzo di refactoring su aree che l'attuale implementazione che rimuove indesiderate o implementa comportamenti desiderabili dall'implementazione esistente in questo modo le parti interessate percepiscono che tu stanno facendo qualcosa.

d) Quando, non se , qualcosa smette di funzionare esattamente come prima e interrompe un comportamento che qualcun altro stava contando su, "sapevamo che era un bug ma lo usavamo comunque" hai il set di comportamento concordato su cui puntare.

Continua a estendere la tua suite di test e riesegui la vecchia implementazione oltre a quella nuova.

Assicurati di seguire le pratiche di controllo della versione del codice sorgente veramente buono come se / quando interrompi qualcosa devi essere in grado di tornare al punto in cui ti trovavi prima di interromperlo in modo semplice e affidabile.