Ho un pomeriggio per esaltare i vantaggi di .NET su VB6 ... cosa devo dire? [chiuso]

La mia azienda è una piccola società di ingegneria di vent'anni. Tutta la programmazione dell'applicazione qui viene eseguita in VB6 da due persone, che si sono insegnate VB6 da un background di assemblaggio mentre lavoravano qui negli ultimi 25 anni e me stesso.

Di conseguenza, il codice VB6 è pieno di odori di codice orrendi, come tonnellate di variabili tipizzate in modo stringente , funzioni terribilmente lunghe, centinaia di variabili globali pubbliche (alcune delle quali sono preferite al passaggio degli argomenti e alla restituzione di valori) e non un singolo oggetto classe. Il refactoring è pressoché impossibile e qualsiasi modifica richiede troppe ricerche nel codice e, una volta apportate, sembra sempre introdurre più buchi.

Il mio capo sta realizzando che VB6 è una tecnologia obsoleta ed è disposto ad ascoltare i miei motivi di trasferirmi in .NET per nuovi sviluppi. Stiamo passando a .NET, ma lo vede come un modo per mantenere la compatibilità con i nuovi sistemi operativi Windows, non come un modo per scrivere codice migliore.

Come posso spiegare al meglio i vantaggi del linguaggio .NET su VB6, al di là del semplice aggiornamento? Cosa posso dire per sottolineare meglio che il passaggio a .NET è una buona mossa ma anche che significa che anche il nostro attuale paradigma di programmazione dovrebbe iniziare a cambiare? Non appena il mio capo viene a sapere che Visual Basic .NET assomiglia a VB6, so che il suo primo istinto sarà semplicemente convertire il nostro vecchio pasticcio di codice in .NET.

Capisco che sarà impossibile cambiare la mentalità di qualcuno in un solo pomeriggio, ma come posso almeno convincere il mio capo addetto all'assemblaggio che cose come variabili fortemente tipizzate, classi personalizzate e campi privati ​​non sono una perdita totale di tempo ed energia?

Risposta breve: non è possibile fare nulla per cambiare idea in base ai criteri elencati nella domanda, tutti tecnici . Questo è l'equivalente di un dibattito religioso . La via più rapida verso il fallimento è presentare un argomento che non è dal punto di vista del pubblico, in questo caso i proprietari delle imprese .

Risposta più lunga: il cambiamento negli affari è guidato da una cosa e una cosa sola. Profitto alla linea di fondo.

... come posso almeno convincere il mio capo che lavora in assemblea che cose come variabili fortemente tipizzate, classi personalizzate e campi privati ​​non sono una totale perdita di tempo ed energia?

Non solo possono essere una perdita di tempo ed energia, ma soprattutto ti costano soldi ! Devi essere in grado di dimostrare quantitativamente che i tuoi suggerimenti porteranno a un sostanziale profitto nel tempo. Affermare che il codice pulito sia "migliore" non è sufficiente, perché il codice pulito costa molto di più da produrre.

Se riesci a capire come porterà il costo dell'utilizzo della tecnologia moderna ($COST + X) * TIME = $PROFIT, dove Xc'è un numero postativo non banale ed TIMEè relativamente breve, puoi creare uno scenario avvincente.

Un altro modo per calcolare il ROI (Return On Investment)

Se questo ROI / ROR è un numero insignificante, specialmente per un lungo periodo di tempo, non hai neanche molto di un business case.

In che modo la tua azienda guadagna davvero?

quante righe di codice? quanti clienti? quante entrate all'anno produce questo software? le entrate sono principalmente contratti di supporto? o nuove licenze? il mercato di riferimento è stabile? in espansione? amministrazione? è il software un leader di perdita per qualche altro prodotto molto più redditizio?

È difficile per un bravo uomo d'affari ignorare il denaro steso sul tavolo.

Ovviamente devi essere in grado di eseguire il backup delle tue dichiarazioni con fatti concreti. Ciò significa che devi essere in grado di fornire numeri reali che ti mostrino davvero capire il business reale e non solo i dettagli tecnici accademici.

Non solo i professionisti

Fornire anche un'analisi dettagliata dei rischi e quali sarebbero questi rischi $COSTse si verificassero, contribuirebbe a convincerli che hai un caso realistico e non stai solo lamentando che non vuoi più fare VB6.

Insegnare ai vecchi cani nuovi trucchi

... Cosa posso dire per sottolineare meglio che il passaggio a .NET è una buona mossa se e solo se anche il nostro attuale paradigma di programmazione inizia a cambiare? ...

Cambiare o non cambiare Il paradigma di programmazione per essere il più idiomatico possibile della nuova tecnologia fa parte dell'analisi del rischio. Ma questo è un argomento separato solo dopo aver dimostrato che ci sono soldi significativi da fare apportando una modifica in primo luogo.

Gli uomini d'affari tendono ad ascoltare casi aziendali, proprio come i tecnici tendono ad ascoltare casi tecnici. Tutti i tuoi casi nella tua domanda sono meriti tecnici che sono accademici nella migliore delle ipotesi nella tua situazione.

Predizione

Sto facendo alcune ipotesi qui l'app VB6, un piccolo negozio, pochi sviluppatori, 2 sviluppatori / proprietari di aziende più anziani stanno indicando un'app di nicchia di mercato che è probabilmente matura (sono noti bug e soluzioni alternative), abbastanza funzionalità completa e relativamente stabile, indipendentemente del "disordine" che è la base di codice. Questo mi porta a credere che la piccola base di utenti non stia crescendo drammaticamente di anno in anno, il che mi porta alla seguente conclusione.

Che non ci sarà davvero alcun motivo commerciale convincente per cambiare direzione tecnica con questa applicazione. E il porting su VB.Net è anche una perdita di tempo perché avrai solo il pasticcio ma ora con più di esso, e 2/3 del team di sviluppo non si dedicano all'apprendimento di qualcosa di nuovo. In bocca al lupo.

Ho un cliente il cui prodotto di punta è scritto in VB6 e gestito da 3 persone. Sono venuto per aiutarli perché avevano un partner che voleva che chiamassero un servizio web. È molto difficile da fare da VB6, ma facile da VB.NET o C #, e ho scritto loro un assembly .NET che sembrava VB6 come un componente COM in modo che potessero chiamarlo. Quindi avevano bisogno di offrire un servizio web a qualcuno. Quindi volevano scrivere una piccola utility autonoma e avrebbe dovuto crittografare e decrittografare alcune informazioni e analizzare alcuni XML. Ho insegnato loro a scriverlo in .NET. Negli ultimi 5 anni circa, sempre più del loro codice è in .NET anche se il prodotto di punta non si è affatto ridotto. Ci sono parti che odiano - ogni app li ha - e dove possono stanno estraendo queste parti (ora inizia la riduzione) e le mettono in servizi o utilità separate. Il resto verrà convertito in holus-bolo in .NET. Sì, nomi di variabili errati e tutto il resto - a mio avviso, ci sono molti vantaggi nel passare a .NET anche se non cambiano il loro attuale paradigma di programmazione. Questi includono:

• puoi usare l'ultimo Visual Studio con una ricerca migliore, Intellisense migliore, build più veloci, ecc
• puoi integrarti con un discreto sistema di controllo del codice sorgente (cioè non VSS)
• ci sono librerie che vengono fornite gratuitamente con .NET che rendono il lavoro breve di cose come la crittografia, l'analisi XML, l'elaborazione delle immagini e altro
• l'internazionalizzazione e la localizzazione sono molto più facili su un progetto .NET (questo, con una richiesta da un enorme cliente canadese che avrebbe bisogno di versioni sia in francese che in inglese, potrebbe aver rovesciato il saldo per il mio cliente)
• librerie di controllo economiche (Telerik, Infragistics, ComponentOne ecc.) offrono incredibili funzionalità a costo quasi zero
• sarà molto più facile trovare un aiuto temporaneo, come uno studente estivo, in circostanze in cui il tempo speso per insegnare loro VB6 non ne vale la pena (non discutere di come ti senti a insegnarlo a un nuovo noleggio a tempo pieno)
• l'applicazione sarà a conoscenza del controllo dell'account utente, quindi funzionerà meglio su Vista, 7 e 8. Non dovrà essere eseguito in modalità compatibilità XP

C'è di più, ma sicuramente è abbastanza?

La questione dei paradigmi di programmazione, della tipizzazione forte, il compilatore è tuo amico, l'incapsulamento è tuo amico e così via è nella mia mente (e vengo pagato per avere queste opinioni) completamente separato. Se vuoi morire su quella collina, vai avanti, ma morirai con una copia di VB6 aperta.

Ho iniziato con un progetto VB6 alcuni anni fa (sistema ERP personalizzato dell'azienda) e lentamente l'ho migrato su .NET. È da qualche parte circa a metà.

Innanzitutto, la conversione da VB6 a VB.Net è quasi sempre una cattiva idea (e ho fatto molte ricerche su questo). C'è semplicemente troppo diverso. Inoltre, se il tuo capo pensa che VB.Net sia "proprio come VB6", allora si sbaglia completamente e devi cambiare rapidamente le sue prospettive.

La mia strategia era quella di mantenere separate le due basi di codice e gestirle separatamente e quindi spostare lentamente interi moduli da VB6 a .NET, ma solo quando si sarebbe verificato un cambiamento significativo in quel modulo, in modo da poter ammortizzare parte del costo. Anche così, la riscrittura è un compito costoso e rischioso.

Esistono due modi per integrare VB6 esistente con il nuovo codice .NET (e probabilmente lo farai per molto tempo, quindi è meglio abituarsi all'idea). Il primo modo in cui l'ho fatto è stato iniziare a scrivere piccoli moduli in .NET e quindi avviare l'applicazione VB6 principale lanciando l'eseguibile .NET passando alcuni parametri della riga di comando. Questo ha funzionato, ma tieni presente che .NET ha un tempo di avvio compreso tra 4 e 10 secondi, quindi sei limitato in ciò che puoi fare in questo modo.

Una volta che ha iniziato a diventare davvero doloroso, ho lanciato la strategia e ho usato il metodo di questo articolo di CodeProject per visualizzare i moduli VB6 esistenti nella mia applicazione .NET principale. Una volta seguito questo percorso, sono stato in grado di sostenere solo un colpo di avvio di .NET e utilizzare ClickOnce per la distribuzione, che era una manna dal cielo rispetto a come l'app VB6 era stata distribuita in precedenza.

Detto questo, ecco i vantaggi che trovo in .NET su VB6:

• Migliori framework di persistenza (NHibernate, EntityFramework, Linq2Sql ecc.)
• LINQ (Non posso sottolineare abbastanza quanto sia importante)
• Generics!
• Sintassi lambda (risolve un'intera classe di problemi come "buco nel mezzo" elegantemente)
• Allo stesso modo Actione Functipi
• Riflessione (qualcosa che usi raramente, ma quando lo fai è enorme)
• Supporto per test di unità molto migliore (ovviamente, dubito che convincerai i tuoi altri dipendenti a test di unità, ma dovresti)
• ReSharper (e altri strumenti di refactoring / profiling) (10 volte meglio di MZ-Tools)
• Fare clic su Progetti e / o Setup / Installer
• Progetti di servizio di Windows
• Vero supporto orientato agli oggetti (VB6 si basa su COM ed è davvero pessimo in questo reparto.)
• Digitazione statica
• Cotto nel supporto XML
• WPF e Windows Form (i controlli di VB6 sono molto limitanti)
• WCF
• Molto più esempio di codice online
• Eccezioni (la gestione degli errori di VB6 è assolutamente terribile in confronto)
• Integrazione del controllo del codice sorgente di Visual Studio
• Decimal type (VB6 non ha mai avuto un tipo decimale di prima classe, anche se ha CDec)
• Supporto di prima classe per Guid
• Supporto di prima classe per numeri interi a 64 bit
• Migliori librerie di raccolta
• ReportViewer
• Multithreading, libreria parallela di attività

Svantaggi di VB6:

• Noterai un'esibizione. Potrebbe non essere abbastanza preoccuparsi, ma fidati di me, lo noterai. VB6 dopo tutto si compila in codice nativo.

Ad essere onesti, ecco alcuni svantaggi del mantenimento di una soluzione combinata VB6 / .NET:

• Mantenimento di due livelli di accesso ai dati (supponendo che l'app VB6 ne abbia effettivamente uno)
• Collegamenti extra per esporre servizi / moduli / ecc. da un lato all'altro
• Il doppio della complessità / architettura da tenere in testa

Ora, come hai accennato, dovresti davvero ricostruire la tua architettura da zero se inizi a scrivere codice in .NET. Tuttavia, sembra che nessuna delle persone della tua azienda abbia familiarità con il mondo della programmazione .NET e / o Java, da cui provengono molti dei modelli e delle pratiche comuni ai grandi framework aziendali.

Se prendi qualcuno che è abituato a trascinare un pulsante su un modulo, a fare doppio clic su di esso e a scrivere alcune stringhe SQL direttamente nel gestore dell'evento click, e questo ha funzionato per loro, è davvero difficile fargli vedere un vantaggio nel seguire SOLID principi di progettazione. D'altra parte, se mordi il proiettile e decidi che tutto il nuovo codice sarà coperto al 90% o più dai test unitari automatizzati, ti renderai presto conto che è davvero difficile da fare a meno che non adotti i principi di progettazione SOLID.

Quindi devi dare uno sguardo molto duro alla realtà della situazione. Nel mio caso, ero l'unico programmatore ed ero determinato a fare testare tutto il nuovo codice, anche se non ne avevo esperienza. Non posso sottolineare abbastanza quanto ciò abbia avuto un impatto negativo su ciò che avrei potuto fare nella prima settimana, anche nei primi mesi. Tuttavia, ero determinato a farlo e avevo acquisito dalla direzione. Molte persone non hanno quel lusso. Ora ho un sacco di codice e ho appena finito un grande refactoring senza quasi problemi.

Realisticamente, non farai test unitari, il che significa che è più difficile giustificare principi come l'iniezione di dipendenza ai tuoi compagni di squadra. Dovrai vendere .NET per meriti diversi dai vantaggi architettonici. Devi concentrarti su un migliore supporto della biblioteca e strumenti migliori. Questa è l'unica cosa che risuonerà. Suggerirei quanto segue nella tua demo:

• Crea un progetto Windows Form (stai lontano da WPF e xaml - è troppo sorprendente)
• Connettersi a un database SQL (alcuni database di test)
• Utilizzare Linq2Sql o EntityFramework per generare un modello di dati per esso
• Creare una classe di repository che ha un metodo per restituire un elenco di entità
• Scrivi una query in quel metodo usando linq, indica l'intellisense
• Fai notare che linq funziona su tutti gli oggetti, non solo sulle entità
• Mostra che se si modifica il database e si rigenera il modello, si ottiene un errore di compilazione
• Rilascia un DataGridViewnella finestra principale
• Dimostrare il databinding popolando la griglia con le entità dal repository
• Sottolinea tutte le cose interessanti sulla griglia che è molto meglio di VB6
• Creare un file .rdlc (report)
• Crea un semplice report all'interno di Visual Studio
• Rilascia un visualizzatore di report nella finestra e visualizza il report all'interno del visualizzatore di report
• (Ovviamente hai bisogno che ReportViewer sia installato e che tu abbia praticato tutto questo per primo)
• Trova un problema "buco nel mezzo" e poi dimostra di risolverlo creando un metodo che accetta un Actionparametro. Per prima cosa, passa un altro metodo come parametro, quindi fai saltare la testa passando un delegato anonimo usando la sintassi lambda
• Dimostrare generici usando le classi List<T>e Dictionary<T1,T2>collection e mostrare come crea codice fortemente tipizzato (VB6 ha elementi simili, ma è tipizzato dinamicamente)
• Scrivi un foreachciclo imbarazzantemente parallelo, usa System.Diagnostics.Stopwatchper misurare il tempo necessario per eseguire, quindi usa la libreria di task paralleli per cambiare il ciclo in un Parallel.Foreachciclo e dimostrare l'accelerazione, supponendo che tu sia su una macchina multi-core.
• Dimostrare la possibilità di aggiungere un gestore di eccezioni globale (questo è qualcosa che VB6 non può fare)

Questo è quello che vorrei fare.

Mi sembra che questa sia una situazione in cui dovrai indossare il tuo cappello politico anziché quello di programmazione. Devi essere molto consapevole di come fai la tua discussione e di non opporsi al tuo pubblico. Assicurati di mostrare i vantaggi di .Net invece di mostrare gli svantaggi di VB. Discutere sugli svantaggi di VB metterà i tuoi colleghi in una posizione in cui devono difendere le loro decisioni e costringerli ad ammettere che una lingua in cui hanno un investimento pesante è una cattiva lingua. Invece, mostra loro come il passaggio a .NET aumenterà gli strumenti a loro disposizione e renderà la loro vita più semplice.

Il mio modo ideale di fare questo argomento sarebbe trovare un'attività o un pezzo di codice di cui tutti si lamentano costantemente e risolverlo usando .NET. Non conosco particolarmente VB, ma ecco un breve elenco di attività fastidiose che probabilmente sarebbero state semplificate usando .NET invece di VB.

• Manipolazione delle stringhe
• Analisi XML
• Ricerca / corrispondenza / Regex
• Matematica (le lingue più recenti di solito hanno librerie matematiche più veloci e complete)
• Costruzione / progettazione della GUI

Scegli una delle attività di cui sopra o qualche altra attività specifica per i progetti su cui di solito lavori, e siediti con loro e in realtà scrivi del codice, da zero, che gestisce il problema in modo rapido e semplice. Mostrare effettivamente il processo di scrittura del codice metterà in mostra gli strumenti che le nuove versioni di VS mettono in campo e dimostreranno che il passaggio a .NET non renderà la vita di nessuno più difficile.

Entrando in questo, devi assolutamente, positivamente fare i compiti. Se ti mostri incerto su come funzionano gli strumenti o se hai un codice che non funziona correttamente, non sarai mai in grado di conquistarli dalla tua parte.

La prima cosa che dici è che VB6 non è più supportato da Microsoft. Mentre riesci a mantenerlo attivo, devi capire che le sue opzioni a lungo termine sono nulle. Non so nemmeno se le app VB6 funzioneranno su Windows8 o se l'IDE stesso funzionerà su Win8.

Quindi, alla fine, devi effettivamente riscrivere e, in tal caso, potresti anche iniziare ora piuttosto che dopo, dandoti un sacco di tempo per capire quale nuova tecnologia vuoi usare (mentre VB.NET sembra l'ideale, questa è la tua occasione per provare qualcosa di più all'avanguardia, come far funzionare l'app su iPad).

A breve termine, puoi mitigare un po 'il problema introducendo nuove sezioni come componenti COM da utilizzare per l'app esistente, speriamo che questi componenti rimangano quando si verifica l'inevitabile riscrittura.

Non mi preoccuperei di argomenti tecnici sul perché .NET sia migliore di VB6. Lì affronterai una discussione persa, la tecnologia in sé non risolve mai i problemi. Dipende da te come applicare questa tecnologia e se l'app VB6 ti sta risolvendo problemi, non c'è argomento a cui rispondere. Puoi parlare di facilità di manutenzione o disponibilità di personale esperto, ma una volta che lo fai ammetti che il tuo personale esistente non ha esperienza nella nuova tecnologia e dovrà essere addestrato, e quindi impiegare un po 'di tempo per mettersi al passo con la velocità con esso. Dovrai anche rispondere alle domande su come molte riscritture finiscano peggio del progetto originale (a volte a causa della mancanza di esperienza, a volte a causa di progetti troppo grandi).

Dagli l'analogia della "vecchia macchina nuova contro macchina":

Sì, entrambi ti porteranno probabilmente a destinazione. Tuttavia, la nuova auto non ha bisogno di una manovella , non ha bisogno di strozzatura , non ha bisogno di mappe , le sue ruote non si bloccano quando si frena bruscamente e alla fine è molto più probabile che ti allontani da un incidente d'auto .

• VB6 è legacy, è il nuovo COBOL
• .NET ha framework migliori
• .NET ha strumenti migliori
• .NET ha prestazioni migliori
• .NET ha un IDE migliore
• .NET ha un miglior supporto linguistico
• .NET ha funzionalità migliori
• .NET ha un miglior supporto per la comunità

Prima di tutto, penso che dovresti cambiare la domanda (non su stackexchange ma all'interno della tua azienda). Non è tanto il motivo per cui .Net è meglio di VB6, ma più simile a quando VB6 non è più supportato , è tempo di andare avanti, ma a cosa. Chiedi agli stakeholder quale dovrebbe essere questa "nuova" tecnologia? Forse non è .Net.

Ma sembra che tu debba passare a una nuova tecnologia E mettere in atto alcuni buoni schemi e pratiche di programmazione. La risposta alla seconda parte è molto più difficile. Probabilmente devi farlo in una piccola sezione dell'applicazione e dimostrarne la pena, ovvero è più stabile, più facile da mantenere, ecc.

Di 'ai tuoi capi di scrivere due annunci desiderati. Uno per gli sviluppatori C #. Uno per esperti VB6. Mettili li 'fuori. Confronta i risultati.