Entropia nei sistemi software su larga scala [duplicato]

È necessario applicare il principio Separation of Concerns per separare il sistema in moduli che comunicano tra loro solo tramite interfacce ben definite. Ciò riduce notevolmente la complessità a causa di molte ragioni:

• Alcuni possono lavorare su una parte del progetto senza comprendere le altre parti;
• Puoi facilmente migliorare il sistema aggiungendo un altro modulo;
• Accoppiamento lento: i moduli sono collegati solo tramite interfacce;
• Alta coesione: i dati di un modulo vengono utilizzati in quasi tutte le parti di quel modulo.

Ah sì, questo problema.

La prima cosa che devi fare è coinvolgere il management con l'idea che il software debba essere evolvibile (il mio termine). L'idea qui è che al posto di un sistema di progettazione fissa e di requisiti in continua evoluzione, devi metterli a bordo con l'idea di modificare il design al variare delle esigenze. Altrimenti si finisce invariabilmente con sistemi mostruosi che è impossibile mantenere.

La seconda cosa (una volta che hai la gestione a bordo) è che devi impegnarti dai programmatori per separare contratto dall'implementazione . Quindi devi essere disposto scrivere test unitari contro i contratti, non contro l'implementazione.

Ora se questo è un sistema su larga scala (e suona come uno) la fase successiva è in realtà quella di costruire un nuovo framework. Il nuovo codice entra nel nuovo framework e alla fine il vecchio framework sarà ritirato. Dovresti farlo in un modo che ti consenta di preservare i vecchi contratti (con app esterne) nel nuovo framework il più a lungo possibile.

Da lì, la soluzione è ciò che io chiamo "refactoring with a chainsaw" e rimuovo i blocchi di funzionalità ben definiti dal vecchio framework e spostarlo nel nuovo framework. Su un sistema su larga scala questo può richiedere anni per spostarsi su tutto.

Ora, se hai dei test unitari sui contratti, puoi rifattorizzare le tue implementazioni mentre cammini senza preoccuparti tanto di rompere le cose.

Non puoi. Come già ammesso, ogni nuova funzionalità costruita su basi deboli rende quella funzionalità più debole, perpetuando il ciclo.

Quello che devi fare è dedicare del tempo al refactoring delle cose per non richiedere gli hack per nuove funzionalità. Forse questo significa un cuore a cuore con la gestione del debito tecnologico e / o dei costi di manutenzione. Forse significa avere stime elevate per essere sicuro di avere il tempo di farlo nel modo giusto. Forse significa avere l'orgoglio per il tuo mestiere di prendersi il tempo per farlo bene, anche se non viene fatto 'in tempo'.

Ma tu sei quello che sta scrivendo il codice, quindi sei tu a doverlo aggiustare. In che modo puoi variare da luogo a luogo.

Una ragione per cui i sistemi entrano in questo stato è che non c'è stato nessuno che guida i cambiamenti. Molti progetti di successo a lungo termine hanno associato comitati direttivi e tabelle di marcia per guidare lo sviluppo. Sono particolarmente utili quando sono coinvolti più team di sviluppo e parti interessate.

Il mio suggerimento è che il tuo team sviluppi una roadmap per il refactoring del sistema. Innanzitutto, definisci un obiettivo. Nel tuo caso, definisci l'architettura ideale per il sistema. Ricorda, non deve essere perfetto , solo fattibile e migliore di quello con cui stai lavorando. Prendi in considerazione software, strumenti di sviluppo, piattaforme hardware, nuove importanti funzionalità che possono essere aggiunte al sistema. Fai un'analisi dei costi. Se si dispone dell'architettura desiderata, quali sono i vantaggi tangibili dell'esecuzione del refactoring? (I vantaggi includono tempi di test ridotti, prodotti software più affidabili, cicli di sviluppo più prevedibili, ecc.) Se si riescono a mostrare sufficienti vantaggi nell'effettuare il refactoring, è possibile ottenere supporto gestionale.

Una volta che hai una roadmap e un supporto gestionale, sviluppa una serie di passaggi che devi compiere per arrivare a questo stato desiderato. Potrebbe essere una buona idea mettere insieme un comitato direttivo che mantenga la tabella di marcia, formi e istruisca i team di sviluppo sulla tabella di marcia, e riveda periodicamente le modifiche per l'integrità architettonica.

Le tabelle di marcia sono davvero utili e forse la 13a domanda sul test di Joel dovrebbe essere "Hai una roadmap?"

Ecco un video della prima ora di una recente roadmap di Red Hat Linux .

Devo dire che non mi piace molto il test delle unità, e lo vedo ancora come una patch parziale che non risolve un buon design, un debito tecnico o uno dei problemi di multi-threading. Ma, penso che il test delle unità potrebbe essere l'unico modo per risolvere il problema.

Dopo che le cose si mettono davvero male, solo i test unitari possono aiutarti a tenere sotto controllo le cose.

O una riscrittura con sviluppatori esperti, ma questo perderà funzionalità, alcune delle quali potrebbero essere bug che i clienti percepiscono come funzionalità.