Come gestire una base di codice di grandi dimensioni senza requisiti e la persona responsabile che lascia l'azienda presto [duplicato]

Ho portato diverse vecchie applicazioni VB6 al framework .NET, tutte quasi senza documentazione, da quella esperienza posso darti alcuni consigli. In primo luogo, lasciatemi dire, sbarazzarsi di VB6 è IMHO un obiettivo legittimo, tuttavia, se si elimina il vecchio codice VBA (utilizzando Excel o Word come piattaforma VBA) vale la pena è discutibile, poiché VBA è ancora ben supportato per questi piattaforme.

Ad ogni modo, se stai davvero seguendo questa strada, consiglio vivamente i seguenti punti:

1. Non riscrivere, invece: port!

Hai scritto "Posso ridurre i loc di almeno il 50%, semplicemente usando le moderne librerie e le funzionalità linguistiche (C #)" . Con questo, hai già commesso l'errore tipico che ho visto così tante volte, anche da sviluppatori esperti, che renderanno il tuo tentativo fallito se non cambierai le tue tattiche. Anche se il 50% fosse vero (il che è IMHO troppo ottimista), si sottovaluta il tempo per ottenere queste linee del 50% di codice prive di errori come il codice originale. Secondo la mia esperienza, se si riscrive il programma da zero, si sarà circa 10 volte più lenti del porting del programma in modo 1: 1. Vedi anche questo vecchio post sul blog di Eric Nelson , che dice essenzialmente la stessa cosa. Assicurati di leggere anche il famoso post sul blog di Joel Spolsky sulle riscritture .

Porting significa che porti il codice sorgente originale con il minor numero possibile di modifiche alla nuova piattaforma. Per questo, fai un favore a te stesso e non usare C #, usa VB.NET , anche se sei sicuramente convinto che C # sia la lingua più "cool". Fact is, C # e VB.NET sono quasi ugualmente potenti e ugualmente supportati da MS, ma VB.NET è molto più adatto come porting target da vecchi VB6 o VBA. Il porting ti permetterà di trasferire la maggior parte del programma correttamente trasferito nel nuovo ambiente con una frazione di nuovi bug, anche se non capisci tutti i dettagli non documentati nel vecchio codice.

Raccomando anche di attenermi alle "libs moderne" quando sono disponibili libs più vecchie e mature che sono molto più simili a quelle che il tuo vecchio programma usa ora. Ad esempio, il porting di una GUI VB6 a Winforms è di ordini di grandezza più semplice che riscrivere la GUI usando WPF. E le librerie come DAO o ADO sono ancora disponibili per Windows, non è necessario passare immediatamente a ADO.NET molto diverso. Se pensi che il passaggio a una nuova libreria ti porti davvero dei vantaggi, fallo più tardi - segui la saggezza del vecchio programmatore - prima rendilo giusto, quindi rendilo piacevole.

2. Crea una buona suite di test di regressione per tutto ciò che ha senso, e costruiscila in anticipo, utilizzando il vecchio programma per produrre i dati di riferimento!

Questo può essere ottenuto anche se non conosci scopo completo del codice precedente . L'abbiamo fatto più di una volta prima di iniziare a port, e ci ha salvato così tante volte dall'introduzione di bug inaspettati che posso sicuramente dire che è sempre stato il primo sforzo.

3. Pianifica il porting a piccoli passi e sostituisci le parti del vecchio programma in produzione con il nuovo il prima possibile.

Con 250K LOC, sono sicuro che c'è la possibilità no di sostituire il vecchio programma con quello nuovo in un modo big-bang. Ovviamente, il modo per eseguire una sostituzione incrementale dipende in gran parte dalla struttura del vecchio programma e dai casi d'uso che supporta, ma in qualsiasi programma di tale dimensione, è molto probabile che si possano trovare parti che possono essere sostituite e distribuite separatamente. Lo stack DotNet supporta diverse funzionalità per rendere più fluida tale transizione, come lo sviluppo semplice dei componenti COM con il linguaggio .Net (in modo da poterli incorporare nel vecchio programma VBA in sostituzione delle parti già caricate).

Ogni parte che hai portato con successo e portato in produzione è

• una parte per cui non devi più mantenere il vecchio e il nuovo codice in parallelo

• una parte per la quale dai tuoi utenti ricevi un prezioso feedback su come funziona bene con il nuovo stack tecnologico, che ti aiuta a trasferire la porzione successiva del codice in modo più corretto ea stimare meglio il lavoro rimanente.

Non.

Mentre una riscrittura dovuta a "tecnologia obsoleta" può sembrare una buona idea, non lo è!

Ogni anno arriva una nuova e fresca tecnologia. Pochi anni dopo, tutti lo considerano obsoleto.

Vuoi essere uno dei ragazzi che cambia le fondamenta del loro codebase ogni anno? O vuoi essere uno dei ragazzi che basano il loro codice su una tecnologia ben collaudata, non considerando la vecchiaia della tecnologia un inconveniente?

Se ci sono validi motivi per cui la tecnologia è fondamentalmente un modo sbagliato di fare le cose, posso vedere il valore in una riscrittura incrementale del codice. Ogni volta, è necessario conservare parte del codice, scrivere di nuovo la parte da zero.

La prossima volta, quando è necessario utilizzare le tecnologie esterne nel progetto, considera di accedervi tramite un wrapper che esponga le funzionalità minime richieste. In questo modo, se decidi che la base tecnologica diventa obsoleta, puoi semplicemente riscrivere il wrapper. Non è necessario riscrivere l'intera applicazione.

Se alcune tecnologie sono progettate per prendere il controllo dell'intera applicazione e progettate per essere difficili da accedere attraverso wrapper ben progettati, affermando di essere The One True Framework, basta dire di no, come si direbbe di no ai farmaci. Perché The One True Framework non lo è e causerà tanti problemi con l'uso di droghe.

Quindi, il mio consiglio sarebbe:

• Spiega al tuo capo perché una grande riscrittura è una cattiva idea.
• Proponi una soluzione alternativa, una riscrittura incrementale
• Spiega perché l'età di una tecnologia non lo rende automaticamente cattivo
• Spiega i vantaggi dell'accesso a tecnologie esterne tramite un wrapper
• Spiega gli svantaggi delle tecnologie che affermano di essere The One True Framework

Sono sicuro che il tuo capo sarà d'accordo sul fatto che la riscrittura dovrebbe essere fatta in modo incrementale, e il capo probabilmente capirà che quando il codice verrà riscritto, non accederà direttamente alla nuova e interessante tecnologia di quest'anno. Accetterà invece una vecchia tecnologia ben testata attraverso un wrapper. Quindi è probabile che probabilmente non dovrai mai riscrivere il wrapper a causa dell'accesso a una vecchia tecnologia ben collaudata. Ma se lo fai, il wrapper è ancora lì e puoi riscrivere solo il wrapper invece di riscrivere l'intera applicazione.

Nel caso in cui il tuo capo non sia d'accordo, fornisci una stima del tempo: 1-10 anni per la riscrittura a seconda del tuo livello di abilità e della complessità del codice. I programmatori molto esperti possono scrivere 20.000 linee di codice estremamente semplice al mese, portando alla stima bassa. Ma se non sei così abile e se il codice non è semplice, la cifra può essere inferiore a 2000 linee di codice al mese. In realtà, quando il bug-busting, la cifra può essere ancora più bassa, a partire da 200 linee di codice al mese.

Cerca di scoprire perché desiderano una riscrittura. Assicurati di dire che una riscrittura completa solo per riscriverlo non ha senso. Ci vorrà molto tempo e sarà pieno di bug. Fai anche notare che la maggior parte degli sforzi di riscrittura falliscono.

Ci sono validi motivi per riscrivere. Se utilizza hardware che non è possibile riparare, o modificare l'architettura in modo da ridurre il costo complessivo.

Detto questo, proverei a usare il software corrente come riferimento, costruisco una suite di test per scrivere su entrambi i vecchi software e la riscrittura per confermare che la riscrittura si sta comportando allo stesso modo.

Idealmente, vorrei solo riscrivere il più piccolo possibile. In questo modo puoi isolare le modifiche e continuare a fornire servizi mentre la riscrittura è in corso.

Buona fortuna.

La prima cosa da chiarire con il tuo capo è il lasso di tempo in questione. Riscrivere 250.000 righe di codice ti porteranno anni. Lo capiscono? Ma poi sembrano esserci cose nell'applicazione a cui nessuno importa, potrebbero esserci caratteristiche che nessuno nemmeno sa, quindi questo ti farà risparmiare tempo.

Concorda con il tuo capo riguardo il lasso di tempo. E non sarai in grado di riscrivere ma cambiare l'app un po 'alla volta. In questo modo puoi sedere con il cliente, trovare il loro primo bit di requisiti, sostituire la parte dell'app che implementa tali requisiti e poi fare il prossimo passo.

A meno che il tuo capo non si sia reso conto di quanto lavoro sia, e il progetto viene abbandonato.

PS. Alcune osservazioni pratiche:

Ci sono dei requisiti. Hai 250.000 linee di requisiti :-( Posso garantire che i tuoi utenti saranno molto infelici se il comportamento dell'applicazione cambierà.

Il "Big Rewrite" - che significa che si scrive un'applicazione completamente nuova da zero - finirà in caso di fallimento. Prendi l'app esistente e modificala un po 'alla volta, in modo che tutto il tempo che i tuoi utenti hanno un'app funzionante.

Utilizza il tempo con il vecchio sviluppatore per assicurarti di poter creare l'applicazione senza problemi. Prima che se ne vada, dovresti essere in grado di prendere una macchina nuova di zecca, installare su di essa tutto il software necessario, scaricare tutte le fonti, premere un pulsante di costruzione e costruire. Lo stesso vale per il processo di distribuzione. Non vuoi fare scherzi con gli script di build che funzionano solo sulla macchina di quel ragazzo, o peggio con gli script di compilazione che esistono sulla macchina di quel ragazzo, una volta che se ne è andato.

La cosa più importante è capire come combinare le 250.000 linee esistenti di codice sorgente con codice moderno, possibile in un linguaggio di programmazione diverso, e farle coesistere.

Per quanto riguarda lo sviluppo, la tua azienda sembra avere problemi molto più grandi e più pressanti di una base di codici LOC 250K. Le cose corrette da fare in questo caso sono le seguenti:

Evita la riscrittura (da zero) a tutti i costi.

Cerca di far capire al tuo datore di lavoro che questa è un'idea terribile per diversi motivi:

1. La tua domanda sembra implicare che sarai solo ad occuparti di questo pasticcio . Questa è una configurazione per il fallimento e il burnout. Una base di codice OO con una media di 100 righe di codice per classe ha bisogno di 2500 classi per avere dimensioni di 250K LOC. Dubito che un sistema legacy sia OO-through-through. E come altri hanno sottolineato, anche se sei un programmatore di prim'ordine avrai ancora bisogno di molto tempo per quella riscrittura. Può funzionare solo se il tuo datore di lavoro ha abbastanza pazienza (misurata nell'ordine degli anni).

2. Ti verrà chiesto di applicare patch e aggiornare il vecchio codebase durante la riscrittura (perché la gestione dice sempre che non succederà, ma sappiamo tutti che lo fa). A causa dei limiti di risorse (vedi 1.) probabilmente "dovrai" applicare queste modifiche senza documentazione o test adeguati. Ciò creerà più problemi di quanti ne risolva e tutte le modifiche alla vecchia base di codice impiegheranno più tempo di quanto pensiate, il che rallenterà la vostra riscrittura fino alla scansione e inciderà sulle scadenze.

3. Questo vecchio codebase non ha documentazione. Sospetto che non abbia anche test . Questo è un male da solo, ma una volta che l'ex sviluppatore responsabile esce, la conoscenza del dominio va con loro. Le modifiche che farai molto probabilmente causeranno nuovi bug o regressioni, perché non hai la conoscenza del dominio o la sicurezza delle suite di test. Ciò contribuirà a rallentare anche tu.

4. È estremamente difficile, se possibile, stimare con precisione il periodo di tempo richiesto per un lavoro di queste dimensioni . In assenza di una stima accurata da parte tua, la direzione probabilmente tenterà di imporre un periodo di tempo assolutamente irragionevole che ha senso solo quando non stai guardando il codice.

Se possibile, chiedi al tuo collega di aiutarti a creare una suite di test di caratterizzazione (che fungono anche da specifiche / requisiti). Procedi con una riscrittura incrementale da lì.

Avrai bisogno di un ambiente separato in cui i test possano essere eseguiti (non eseguire test di caratterizzazione contro gli ambienti di produzione!), ma il vantaggio di farlo è che puoi:

• continua a fornire le modifiche a un singolo codebase (meno il cambio di contesto);
• acquisire simultaneamente la necessaria conoscenza del dominio;
• evita di impegnarti in un compito impossibile: potrai impiegare la maggior parte del tuo tempo a riscrivere e a refactoring parti dell'applicazione con l'aiuto della suite di test. Se ti fermi a lavorare su funzionalità / bug attuali, non è un grosso problema. Cambia i test di caratterizzazione e modifica il codice legacy. Una volta fatto, puoi continuare il refactoring, possibilmente iniziando con la funzione appena introdotta o i moduli relativi al bug appena risolto.

Inoltre, guarda le domande collegate / correlate e altre risposte date dove ci sono riferimenti a specifici libri / articoli sull'argomento (cioè lavorando con e rifattando il codice legacy).

Infine, potresti chiederti alcune domande, a tuo vantaggio (e forse anche dell'azienda):

• perché una società consentirebbe a un singolo sviluppatore di "possedere" 250K LOC?
• perché non stanno provando (o non possono provare) a mantenere questo sviluppatore?
• perché non stanno imparando qualcosa da questo (indicato chiedendo ad un altro singolo sviluppatore di ripetere l'impresa)?

Quelle sono tutte bandiere rosse nel mio libro. Se il ragionamento con la tua gestione fallisce, considera l'opportunità di aggiornare il tuo curriculum.

I requisiti sono codificati nel comportamento dell'applicazione corrente.

Leggi il codice, sperimentalo e produci documentazione del comportamento corrente. Per tutto ciò che non capisci, chiedi chiarimenti allo sviluppatore originale e aggiungi commenti esplicativi direttamente nel codice sorgente.

I know how to deal with legacy code, my question is can i get away with not having to deal with it at all.

No, mi dispiace. Poiché i requisiti sono codificati nel vecchio codice sorgente e non sono stati documentati da nessun'altra parte, non c'è modo di utilizzare il codice legacy come punto di partenza. hai per approfondire e familiarizzare con esso, che ti piaccia o no.

Sebbene i requisiti possano in qualche misura esistere nello sviluppatore originale, la memoria umana è fallibile e ti dimenticherai facilmente dei punti chiave se proverai a documentare i requisiti dalla loro memoria.

Se conosci VB, cerca di convincere il tuo datore di lavoro a consentirti di rifattorici prima e, dopo di ciò, entrambi sarete in una posizione migliore per sapere se è necessaria una riscrittura.

Il refactoring sarà l'unico modo per capire veramente cosa fa il codice. Per questo, ti raccomando "Lavorare efficacemente con il codice legacy" di Michael C. Feathers.