"Lavorare efficacemente con il codice legacy" aiuterà qualcuno che lavora con un'applicazione portata da VB6 a VB.NET?

Question

Mi piacerebbe refactoring una grande applicazione legacy originariamente scritta in Visual Basic 6.0 e successivamente portato su .NET. Per fare ciò con sicurezza, voglio avere test unitari attorno al codice esistente in modo da poter confrontare prima e dopo. Qual è il modo più semplice ed efficace per farlo?

C'è un libro chiamato "Working Effectively with Legacy Code" che sembra che potrebbe aiutarmi. Tuttavia, sembra che si occupi solo di linguaggi orientati agli oggetti e Visual Basic 6.0 non è necessariamente OO. Questo libro può ancora aiutarmi? Spero che qualcuno che ha letto possa garantirlo.

In particolare, questa applicazione non utilizza classi diverse dai moduli stessi. Accede al database direttamente dai moduli e non in modo coerente. C'erano diverse persone che lavoravano a questo progetto usando tutti i loro stili senza alcun standard.

Come ho detto, questo progetto è stato portato su VB.NET. Tuttavia, è solo trasferito nel senso che compila in Visual   Studio   2008. Tutti i concetti di codifica sono Visual Basic 6.0.

Answer 1

Non si occupa solo delle lingue object-oriented (OO). Grandi sezioni riguardano come gestire il codice precedente in C.

Quindi sì, compralo!

---

C'è un intero capitolo (Capitolo 19) denominata:

Il mio progetto non è orientato agli oggetti. Come posso apportare modifiche sicure?

Inoltre v'è vbUnit, un xUnit implementazione che potrebbero aiutarvi a utilizzare TDD con Visual Basic 6.0.

In realtà, ho letto erroneamente la domanda e ho pensato che fossi andando a porta, non che tu abbia già effettuato il porting. In questo caso, hai un sacco di codice "legacy" VB.NET che questo è totalmente il libro per te. Puoi sfruttare le funzionalità di OO di VB.NET e utilizzare il resto del libro.

Non posso davvero consigliare questo libro di più.

Answer 2

Sì; i concetti del libro sono grandi e potenti e si estendono oltre l'OOP. E VB6 può essere orientato agli oggetti, sebbene non sia un linguaggio completamente orientato agli oggetti come alcuni.

Tra i concetti più potenti del libro c'è quello di "cuciture", essenzialmente luoghi in cui è possibile rompere il codice, iniettare test o isolare o astrarre parti di funzionalità. Questo è solo uno dei concetti che si applica anche al codice procedurale.

Answer 3

Si consiglia di rendere le domande più specifiche.

Mentre VB6 non è un linguaggio OO puro in sé, ci sono abbastanza elementi di OO che le cose dovrebbero essere familiari; inoltre, ci sono un certo numero di plug-in di test delle unità per l'IDE VB6.

Ma prendiamo in considerazione alcuni dei componenti VB6 di alto livello:

• forme sono oggetti (è possibile creare nuove istanze).
• I moduli si comportano come classi con solo metodi statici.
• classi & UserControls sono il più vicino agli oggetti che si ottengono. La mancanza di costruttore rende le cose difficili, ma spero che lo sviluppatore originale sia rimasto con Initialize o abbia scritto un sub di Init coerente.
• Gli eventi in VB sono dispari; è anche quello che probabilmente ti farà inciampare di più. Il codice nascosto e di stato che dipende da un particolare ordine di eventi è senza dubbio sparsi ovunque.
• Pagine di proprietà. Bene, è quello che è.

Inizia con le migliori pratiche di VB. Se l'app non è stata scritta con il codice delle migliori pratiche in mente, penso che intraprendere questo passaggio ti risparmierà un sacco di problemi lungo la strada.

Answer 4

Suggerirei di dare un'occhiata a Martin Fowler's Refactoring: Improving the design of existing code, che è un'eccellente lettura obbligata.

Si potrebbe essere alla ricerca di qualcosa sulla falsariga di Professional Refactoring in Visual Basic. Non l'ho letto, ma sembra applicabile.

Answer 5

è sicuramente un po 'di bel da fare per voi, ma qui è una strategia di prendere in considerazione prima di fare qualsiasi lavoro .NET.

spostare fuori come gran parte del codice del modulo sottostante, come si può in una classe: Un file di classe per ogni forma come un inizio. In sostanza, i gestori di eventi del form non dovrebbero fare altro che chiamate proxy ai metodi in un'istanza di classe sottostante; tutti i metodi personalizzati possono ovviamente essere spostati sul file di classe.

Dopo aver letto la guida alle best practice (ecc.) Di Microsoft e altri per aiutarti a preparare la migrazione .NET, sei praticamente impostato per i piccoli frammenti di inferno che dovrai ricodificare/refactor: fastidi come come la gestione degli errori, ordinamento eventi, oggetti in ritardo legato/varianti, collezioni, ecc

una parola in caso di errore movimentate codice: E 'è soprattutto difficile da duplicare spaghetti su-errori, soprattutto dal momento che la media coder Visual Basic ha avuto un cattiva abilità per usarlo come logica del flusso di controllo. Vale quasi la pena rompere ogni blocco On Error in sotto-routine separate, se ne hai più di due in una routine.

Una volta che il codice è stato ripulito, si può anche considerare refactoring del codice Visual Basic in astrazioni sensibili (ad esempio, un adattatore di dati singola classe & connessione, ecc), ma sarete il miglior giudice di quella.

Potrebbe non piacere questo approccio, quindi testare le acque con una sola forma.

Answer 6

Possiedo una copia, che ho acquistato per provare ottenere il nostro progetto C/C++ sotto controllo. Come ho perso la funzionalità C#/.NET ha da offrire.

I libri sono molto C/C++ ish, ma, come dice John, c'è il capitolo del lavorare senza oggetti.

Ma, se come dici tu, il tuo codice viene portato su .NET non è più codice di Visual Basic 6.0. .NET ha molti modi di Visual Basic/C# per permetterti di collegarti al tuo codice e testare. Detto questo, il libro offre una buona panoramica dei diversi modi in cui è possibile agganciare un'applicazione e le strategie per ottenere un grande vecchio progetto sotto controllo.

Answer 7

Penso che i test di caratterizzazione siano i più vantaggiosi. Dovrebbero essere automatizzati. Senza test di caratterizzazione, ti verrà lasciato testare manualmente la tua applicazione/codice eseguendola effettivamente. È così facile perdere test di funzionalità critiche quando si aggiunge un nuovo codice. Questo deriva dalla mia esperienza personale.

Sprout Method e Sprout Class sono importanti quando si aggiunge un nuovo codice.