Come riparare un progetto praticamente senza struttura?

Ora che è nel controllo del codice sorgente, puoi eliminare il codice commentato.

Ho iniziato qui in una situazione simile (80KLOC VB6 app senza controllo del codice sorgente, nessuna struttura reale, quasi tutto fatto nei gestori di eventi).

In circa 2 anni ho ottenuto più della metà di convertiti in C # (solitamente quando sono richieste nuove funzionalità significative). Tutto il nuovo codice C # ha una copertura di test unitaria. Tuttavia, ci vuole decisamente più tempo per convertire in C #. Se non aggiungi nuovi moduli significativi, non andrei su questa strada.

Una cosa che ho fatto è stata creare un livello di accesso ai dati rudimentale che si è auto generato dal database. Questo almeno ha colto problemi dove il nome di una colonna di tabella è cambiato e non ho trovato tutti i posti nel codice. Inoltre, ho spostato lentamente la logica aziendale in moduli, fuori dai gestori di eventi del modulo.

I, tuttavia, aveva il vantaggio che l'applicazione era solo interna. Dal momento che ho avuto solo un sito in cui distribuire, potrei correre rischi maggiori di quanto potresti. Se ho fatto un errore, di solito non era un grosso problema risolverlo. Sembra che tu non abbia quel lusso.

Credo che la cosa migliore da fare sia adottare il seguente approccio:

1. Impara tutti i dettagli in modo straziante. Questo rende meno probabile che tu spezzi qualcosa inavvertitamente.
2. Refactare senza pietà per migliorare la separazione e la struttura, ma non provare a calzare una nuova metodologia come la programmazione orientata agli oggetti, dato che VB6 fa solo schifo.
3. Tratta come un'esperienza di apprendimento. Come faresti a sapere che un modo diverso è meglio se non hai mai visto il modo inferiore?
4. Non preoccuparti di riscrivere in un nuovo linguaggio / framework / piattaforma a meno che tu non abbia un modulo principale da scrivere. Anche allora, considera attentamente.

Ricorda, l'obiettivo del programma è di essere un prodotto che rende i soldi della tua azienda. Non deve essere un'opera d'arte impeccabile (e io sono un perfezionista quindi per me è veramente difficile ammetterlo). A volte è meglio abbracciare il pragmatismo.

Ci sono presumibilmente molti programmatori COBOL che mantengono enormi quantità di codice legacy. Dubito che stiano faticosamente lavorando a riscriverlo in una nuova lingua. :)

Quello che devi fare è refactoring. Il refactoring è quasi impossibile in una situazione del genere senza test unitario che ti dia la sicurezza di non aver infranto nulla. Pertanto, inizia con la creazione di test unitari. Documenta il comportamento del codice - ma non (solo) su carta, ma in più codice - i test dell'unità. Una volta che hai eseguito i test, puoi iniziare a ristrutturare il codice.

Viene in mente una regola di " Debug " di David Agan: smettere di pensare e guardare. Ti capita di avere a tua disposizione una macchina in grado di elaborare grandi quantità di testo. Usalo per capire esattamente quale codice non è più in uso e rimuovilo senza pietà. Se commetti un errore, è a questo che serve il controllo del codice sorgente.

Questa è la parte facile. Quello che devi pensare dopo è come mangi un elefante? Un morso alla volta. Prendi " Refactoring " di Martin Fowler e prendilo per funzione, file per file. Non eliminare completamente qualcosa e riscrivilo da ciò che ritieni siano i requisiti. Lavora come un alpinista, senza mai rimuovere la tua sicurezza precedente fino a quando il prossimo è a posto.

Aveva già abbastanza metafore? Il punto è che se lo fai lento e costante, con molti miglioramenti semplici come rinominare o dividere una funzione, puoi migliorare le parti cattive del codice senza distruggere le parti buone di esso create in anni di debug e richieste di funzionalità . Vuoi che il codice rimanga sempre disponibile. Se è possibile farlo mentre esegui il porting su un linguaggio più moderno, provaci.

Odio dirlo ma andrei con "completamente senza speranza" oltre il solo continuare a fare un ciclo infinito di patch / migliorare e sperare che non si rompa nulla. Ho visto troppi progetti VB6 come quello che descrivi e tenta di rifattorici / riscrivi / ripristini in C # /. NET falliscono terribilmente, spesso con le persone incaricate del tentativo di essere licenziato.

Il fatto è che prima o poi sarà necessario riscrivere completamente da zero. Le versioni VB6 e Windows che supportano bene sono in declino. Trovare sviluppatori che conoscano le stranezze di VB6 e che sono disposti a lavorare su programmi come questo stanno diventando più rari. I limiti interni di VB6 saranno colpiti da enormi programmi come questo, causando strani errori.

Se c'è un buon consenso e impegno per un totale, ground-up, riprogettazione e riscrittura a questo punto, iniziare a lavorare su di esso e delegare la manutenzione continua a qualcun altro (appaltatori, programmatori junior, qualunque cosa funzioni per te). Se le persone non sono abbastanza convinte per iniziare ancora, aspettate solo che il dolore diventi abbastanza grande o passate ai pascoli più verdi.

Alcune buone risposte qui già, vorrei aggiungere una cosa. Invece di provare a riscrivere tutto, forse avrai la possibilità di portare almeno alcuni di questi moduli per lo più da 1: 1 a VB.NET (ovviamente, devi fare molta attenzione quando lo fai)? Secondo la mia esperienza, tale porting può essere eseguito con circa 5-10 volte meno sforzo rispetto al tentativo di ricostruire da zero tutte le funzionalità esistenti. E dopo averlo portato, poi puoi iniziare a refactoring - con tutti gli strumenti disponibili nel mondo .NET, come buoni strumenti di test delle unità, strumenti di refactoring automatico, OOP reale ecc.

Ero stato in una situazione simile, dove dovevamo migrare un vecchio programma C ++ a 16 bit (150k LOC) nel mondo a 32 bit, in cui il framework GUI originale in uso non era più disponibile. Ci è voluto del tempo per capire che la riscrittura non era realistica, ma dopo aver deciso di portarla sul mondo .NET, usando C ++, C ++ / CLI e C #, avevamo bisogno di circa 9 mesi per farlo (con circa 1 dev a tempo pieno lavorando su quel progetto). E non abbiamo avuto test unitari per la parte GUI disponibile, fatto tutto quel test di quelle parti manualmente.

Anche se mette molta enfasi sul test delle unità della tua applicazione che, sebbene sia una cosa molto importante da fare, è qualcosa di abbastanza difficile da fare in VB6, Steven McConnell ha scritto un libro eccellente su come affrontare un progetto del genere.

Dai un'occhiata a questo:

Steven C. MCCONNELL: Working Effectively with Legacy Code, Second Edition. Microsoft Press, june 2004.

Fondamentalmente, il suo punto è prenderlo lentamente, un po 'alla volta. Raccomanda anche di iniziare usando tecniche di refactoring che sono molto improbabili per rompere qualsiasi cosa, a volte peggiorando nel breve periodo, e iniziare a usare tecniche più avanzate man mano che il codice si sta facendo più pulito e ha test unitari per supportarlo.