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

Question

Vorrei riformattare un'applicazione legacy di grandi dimensioni originariamente scritta in Visual Basic 6.0 e successivamente portato su .NET. Per fare questo con fiducia, voglio avere dei 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 " Lavorare in modo efficace con il codice legacy " 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 lo abbia 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 propri stili senza standard.

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

Answer 1

Non si occupa solo di orientato agli oggetti (OO). Grandi sezioni riguardano come gestire il codice legacy in C.

Quindi sì, compralo!

---

C'è un intero capitolo (capitolo 19) chiamato:

  

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

Inoltre c'è vbUnit , un xUnit che può aiutarti a usare TDD con Visual Basic 6.0 .

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

Non posso davvero raccomandare di più questo libro.

Answer 2

Sì; i concetti del libro sono grandi e potenti e si estendono oltre 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 suddividere il codice, iniettare test o isolare o estrarre bit di funzionalità. Questo è solo uno dei concetti che si applica anche al codice procedurale.

Answer 3

Potresti voler rendere le domande più specifiche.

Sebbene VB6 non sia un linguaggio OO puro di per sé, ci sono abbastanza elementi di OO che le cose dovrebbero essere familiari; inoltre, vi sono numerosi plug-in di unit test per l'IDE VB6.

Ma consideriamo alcuni dei componenti VB6 di alto livello:

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

Inizia con le migliori pratiche di VB. Se l'app non è stata scritta pensando al codice delle best practice, penso che fare questo passo ti farà risparmiare un sacco di problemi lungo la strada.

Answer 4

Hai sicuramente del lavoro da fare, ma ecco una strategia da considerare prima di fare QUALSIASI lavoro .NET.

Spostare il maggior numero di codice FORM sottostante in una classe: un file di classe per modulo come inizio. In sostanza, i gestori di eventi form non dovrebbero fare altro che chiamate proxy a metodi in un'istanza di classe sottostante; tutti i metodi personalizzati possono ovviamente essere spostati nel file di classe.

Dopo aver letto la guida alle migliori pratiche (ecc.) di Microsoft e altri per aiutarti a prepararti alla migrazione di .NET, sei praticamente pronto per i piccoli inferni che dovrai ricodificare / rifattorizzare: Disturbi come gestione degli errori, ordinazione di eventi, oggetti / varianti in ritardo, raccolte, ecc.

Una parola sul codice di gestione degli errori: è soprattutto difficile duplicare gli spaghetti sugli errori, soprattutto perché il programmatore medio di Visual Basic ha una cattiva abilità nell'usarlo come logica del flusso di controllo . Vale quasi la pena dividere ogni blocco On Error in sotto-routine separate, se ne hai più di due in una routine.

Una volta che il codice è stato ripulito, puoi anche considerare di rifattorizzare il codice di Visual Basic in astrazioni sensibili (ad esempio, una singola classe di adattatore dati e connessione, ecc.), ma sarai il miglior giudice di che.

Questo approccio potrebbe non piacerti, quindi prova sicuramente le acque con una sola forma.

Answer 5

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

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

Ma, se come dici tu, il tuo codice viene portato su .NET non è più codice Visual Basic 6.0. .NET ha molti modi di Visual Basic / C # di lasciarti agganciare al tuo codice e testare. Detto questo, il libro ti fornirà una buona panoramica dei diversi modi in cui puoi collegarti a un'applicazione e delle strategie per tenere sotto controllo un vecchio progetto di grandi dimensioni.

Answer 6

Suggerirei di dare un'occhiata al Refactoring: migliorare la progettazione del codice esistente , che è un eccellente libro da leggere.

Potresti cercare qualcosa sulla falsariga di Refactoring professionale in Visual Basic . Non l'ho letto, ma sembra applicabile.

Answer 7

Penso che troverai i test di caratterizzazione il massimo beneficio. Dovrebbero essere automatizzati. Senza i test di caratterizzazione, ti verrà quindi lasciato testare manualmente l'applicazione / il codice eseguendolo effettivamente. È così facile perdere test delle funzionalità critiche quando si aggiunge un nuovo codice. Questo proviene dalla mia esperienza personale.

Il metodo Sprout e la classe Sprout sono importanti quando si aggiunge un nuovo codice.