Come evitare che il tuo codice diventi obsoleto?

Question

Alcuni programmatori hanno sviluppato un progetto in VB6 e dicono che ora devono eseguire l'aggiornamento a vb.net se vogliono che le loro app vengano eseguite su sistemi più recenti/futuri poiché il vb6 sarà presto disponibile.

Quindi c'è questo enorme applicazione hanno lavorato su che stanno andando ad avere per ricostruire da zero (hanno cercato di utilizzare la procedura guidata di aggiornamento, ma ci sono stati troppi errori)

Il proprietario della società è Non troppo entusiasta di investire così tante ore in un progetto solo per dover girarlo e rifarlo da zero.

Questo non è il mio progetto e non so nulla di vb, sono un programmatore web.

Ma cosa possono fare questi ragazzi, in modo che questo non accada di nuovo, o cosa avrebbero dovuto fare in modo che questo non sarebbe stato un problema ora?

C'è un modo per assicurarsi che l'applicazione sia sempre scalabile e non diventerà obsoleta e deve essere riscritta?

Grazie!

Answer 1

No, non c'è niente intorno a questo, anche se Windows 7 può ancora eseguire programmi DOS, quindi non è come i loro programmi non saranno eseguibili. Il problema più grande a cui si imbatteranno non è un nuovo supporto o nuove funzionalità e una comunità di conoscenze sempre più ridotta sull'argomento.

La mia azienda sta attualmente eseguendo programmi in Fortran, Clipper, VB6 e FoxPro per citarne alcuni, alcuni dei quali sono in circolazione da oltre 20 anni e sono sopravvissuti indenni da tutti gli aggiornamenti di Windows. Di solito la cosa che rende inutilizzabile un vecchio programma è l'impossibilità di ricompilare il programma per correggere i bug.

Certamente aiuta a rompere la funzionalità dei programmi in modo che se decidete di migrare da VB6 a VB .Net è molto più facile individuare il codice riutilizzabile.

Answer 2

Considerando la rapida evoluzione delle tecnologie in ambito di programmazione, diventare obsoleti fa parte del normale ciclo di vita delle nostre applicazioni.

io non so davvero per le applicazioni desktop/server, ma, in web-sviluppo, diciamo che 5 anni è lungo, per esempio ^^

Naturalmente, è possibile aggiorna, correggi, correggi, correggi, qualsiasi cosa ... Ma farlo generalmente tende a degradare la qualità del codice e la qualità dell'applicazione stessa - il che significa che la manutenzione costerà sempre di più con il passare del tempo; alla fine, riscrivere tutto probabilmente significherà spendere meno denaro nella manutenzione.

Answer 3

Ottima domanda.

La risposta breve è No. Perché tutto il codice diventerà obsoleto.

Se hai scritto il codice nell'assembler x86, sarebbe durato un po 'di tempo. Anche il codice C avrebbe una lunga durata di conservazione. Ma il problema deriva dal fatto che più una tecnologia viene estratta dall'assemblatore più breve è la sua durata a causa di molti fattori.

Answer 4

Non mettere a fuoco il codice che non può essere reso obsoleto. È raro che lavori in una pila applicabile. Invece, rendi il tuo codice chiaro e conciso in modo da poterlo migrare quando sarà il momento. Invece, concentrati su non farti diventare obsoleto.Lavora per rimanere aggiornato e sapere cosa sta succedendo nel tuo stack e cerca di essere consapevole di ciò che sta accadendo, anche se non puoi dedicare del tempo per applicarti completamente a esso.

Considerando l'emulazione e le macchine virtuali, ho la sensazione che il codice "legacy" avrà in realtà una vita ancora più lunga di quanto immaginato prima. È più la strumentazione, al contrario del sistema operativo, che dovresti preoccuparti.

Answer 5

Dipende (forse) dal separare il codice dal design, specialmente nelle applicazioni web che sono spesso molto soggette ai capricci della moda. Ma la base di codice è eseguibile sulla tecnologia attuale, cioè il sistema operativo continuerà a funzionare, quindi non vi è alcun motivo per "aggiornare".

Il vero modo per garantire il codice dura per sempre anche se è quello di scrivere un'applicazione che diventa così indispensabile in uso, ma così costoso di riscrivere che tutto, tra cui non obsoleto sistema operativo e l'hardware è fatto per assicurare che continua a funzionare. Credo che un esempio di ciò sia che alcuni sistemi di base della Social Security statunitense/arena governativa sono ancora in corso di scrittura nei primi anni 60 COBOL e in esecuzione su vecchi mainframe IBM.

Answer 6

Come altri hanno già detto, non è "come può la mia applicazione non essere resa obsoleta". È più "quando la mia applicazione diventa obsoleta, come posso recuperare rapidamente". E davvero, questa è solo una versione diversa di altre domande:

• Quando esce la nuova versione di X, come posso utilizzare le nuove funzionalità?
• Quando cambiano le regole aziendali, come posso apportare modifiche all'applicazione?
• Quando questa applicazione qui vuole accedere ai dati, come posso esporre rapidamente i dati?
• Quando il client desidera passare da un client spesso a un client Web, come posso assegnargli la nuova piattaforma?

Questo è ciò che OO e SOA stavano tentando di rispondere. Crea un sacco di piccole applicazioni indipendenti e uniscile unendole usando un meccanismo standard. Quando è necessario eseguire l'aggiornamento per qualsiasi motivo, estrarlo, aggiornarlo e ricollegarlo.

Answer 7

Non sono a conoscenza di alcun metodo riconosciuto per impedire l'obsolescenza di un'applicazione non mantenuta.

Se si desidera impedire un prodottodi diventare obsoleto, quindi disegno che sia aggiornabile.

In .NET, almeno, avete molte, molte opzioni per la creazione di componenti riutilizzabili:

• assemblee separate, che possono essere utilizzati in qualsiasi progetto .NET, e può essere successivamente esteso per supportare COM interop in caso di necessità di utilizzare una tecnologia diversa.

• Servizi Web; questi possono essere esposti pubblicamente e utilizzati da quasi tutti gli ambienti.

• Le interfacce e l'Inversion-of-Control possono essere utilizzate per supportare componenti liberamente intercambiabili, che potrebbero teoricamente provenire da qualcosa che non è uniforme.NET (basta compilare un wrapper COM);

• Comunicazione tra processi - se tutto il resto fallisce, è possibile letteralmente solo creare un file mappato in memoria o una named pipe e iniziare la canalizzazione in dati da (o destinati a) un'applicazione nuova di zecca.

In effetti, un certo numero di queste cose probabilmente si applica al progetto VB corrente. Di solito ci sono una miriade di metodi diversi per estendere la vita utile di un prodotto esistente e gradualmente passare la funzionalità principale a una nuova tecnologia.

Non sono hardcore SOA, ma questo è esattamente il tipo di problema che SOA cerca di risolvere. Faccio molti servizi - in effetti, quasi tutto ciò che è significativo qui passa attraverso un qualche tipo di servizio web ad un certo punto - e mi sento abbastanza tranquillo sapendo che posso completamente strappare un servizio in qualsiasi momento e sostituirlo con un servizio su un piattaforma diversa. Tutto ciò che deve fare è sputare SOAP o JSON e i miei .NET client possono ancora consumarlo. Oppure, in alternativa, se devo sostituire i client, posso semplicemente collegarmi al modello di dominio ricco già esistente nei servizi.

In effetti, ho già fatto - l'architettura era costruita interamente su una piattaforma Delphi 7. Ora è tutto su .NET 3.5, e non c'è mai stato alcun taglio duro da un sistema all'altro. Abbiamo iniziato a costruire semplici servizi SOAP, quindi spostato gran parte della logica di business in-application ai servizi, e alla fine, quando l'applicazione non era molto più di una shell, l'abbiamo sostituita con diversi client .NET (ce ne sono alcuni applicazioni separate) e quindi ha iniziato ad aggiungere varie funzionalità di sicurezza e ottimizzazioni che potrebbero essere supportate solo su piattaforme più recenti. E così via e così via.

Quindi si può sicuramente fare, se si pianifica in anticipo. Naturalmente, ci sono un certo numero di persone qui che consiglieranno di non pianificare in anticipo, citando YAGNI ... e forse è vero, per alcuni progetti. Tutto dipende da quanto sia costoso/mission-critical il progetto. Se il prodotto ha bisogno di durare per 50 anni, allora potresti pensare di investire in una solida architettura e design che ti consenta di aggiungere e rimuovere facilmente i sottocomponenti.

Answer 8

Dovrebbero chiedersi perché hanno pensato che fosse una buona idea scrivere questo progetto in VB6 per cominciare! Non sapevano che era già non supportato e obsoleto? Se inizi a utilizzare tecnologie obsolete, cosa puoi aspettarti?

Si dovrebbe anche considerare di migliorare la struttura del proprio codice VB6 e renderlo più orientato agli oggetti. Ciò renderà più facile la transizione verso .NET. Tra le altre cose, potrebbero provare a separare la funzionalità in classi esterne accessibili tramite COM. Quelle stesse classi potevano quindi essere accessibili da VB.NET. Inoltre, questi pezzi più piccoli potrebbero essere più facili da migrare.

Answer 9

Il modo migliore è utilizzare strumenti e librerie di sviluppo multipiattaforma. In questo modo Microsoft non può deprecare le cose di cui si dipende (dato che non le controllano). Se dipendi da qualcosa di specifico da un singolo venditore, è probabile che ti rovini a un certo punto.

Answer 10

Open-source, o almeno costruire su una piattaforma open-source.

Non conosco alcun sistema proprietario degli anni '70 che stiamo utilizzando in un modo compatibile con il loro vecchio utilizzo, ma conosco molti sistemi open source.

Non è un meccanismo perfetto: tutte le lingue cambiano, anche se leggermente, in questi intervalli di tempo, quindi è necessario apportare aggiornamenti al codice per ottenere le novità. Ma conosco molti server con codice in esecuzione da decenni senza modifiche.

Meglio ancora, open-source, o il più possibile. Ancora meglio che essere in grado di fare nulla è essere in grado di non fare nulla mentre altre persone lo aggiornano per te. Ci vuole del lavoro per far iniziare la community, ma una volta avviati possono essere difficili da fermare!

L'utilità di qualsiasi programma non open source scende a zero dopo un tempo limitato. Non è garantito che l'open source farà sì che rimanga diverso da zero, ma c'è almeno una possibilità.

Answer 11

Non utilizzare un linguaggio proprietario. Certo, le librerie e la piattaforma potrebbero cambiare, ma è interessante il fatto che lo stesso linguaggio sia diventato obsoleto. Attenersi a C, C++ o qualsiasi cosa con una vasta base di utenti che è open source. Probabilmente saranno in giro per un po 'anche se i manutentori smetteranno di supportarlo - questo significa Python, Ruby, Java, e possibilmente C#. La mia sfera di cristallo non è così buona al di fuori di C e C++, ma ci sono motivi convincenti per uno degli altri a durare 20-50 anni.

Visual Basic era divertente, ma il mescolarsi di codice e interfaccia utente che promuove è terribile da un punto di vista architettonico. Un buon design dovrebbe rendere fattibile (non necessariamente super facile) cambiare backend, GUI toolkit e OS.

Sei un po 'bloccato con una lingua, quindi scegli uno che non sia limitato a un venditore che lo modifica costantemente.

Prova a leggere Fire and Motion di Joel.

Answer 12

Scrivere su definizioni standard (ANSI o ISO, eviterei ECMA) che sono attualmente in uso grave. Evita qualsiasi cosa che dipenda da una compagnia, o dove l'unica implementazione completa provenga da un'azienda. Non utilizzare le estensioni della lingua del fornitore. Fare attenzione a evitare ipotesi sulla lingua, come la dimensione del tipo di dati: se si utilizza int per contenere le dimensioni della memoria anziché size_t, è possibile rendere più difficile l'esecuzione su un sistema a 64 bit.

Ricordare che Microsoft è notevole tra le aziende per preservare la compatibilità con le versioni precedenti e che hanno rotto VB6 per te. Qualsiasi altra compagnia sarà probabilmente peggio.

In qualsiasi applicazione significativa, ci saranno parti che dipendono dalla piattaforma. Segregale, per limitare ciò che deve essere riscritto se la piattaforma cambia.

Ovviamente, ci sono dei costi in questo. Ho raccomandato, ad esempio, che le applicazioni Windows vengano eseguite in Visual C++, con MFC utilizzato attraverso un livello di astrazione, poiché C#, .NET, VB.NET e F # non soddisfano i miei criteri. Tuttavia, questo è come creare un programma di lunga durata, se questo è il tuo obiettivo.

Answer 13

Devo essermi perso questa domanda a febbraio, mi dispiace. Per quanto posso vedere, nessuno ha risposto alla conclusione dei colleghi che dovranno ricostruire [la loro app VB6] da zero per migrare a .Net.

Questo è sbagliato : essi non devono riscrittura, ci sono metodi alternativi e di solito sono di gran lunga più facile e meno costosa di una riscrittura completa.

Ecco il parere ufficiale del Microsoft UK:

Esecuzione di una riscrittura completa a.NET è molto più costoso e difficile da fare [rispetto alla conversione] ... raccomandiamo questo approccio solo per un numero limitato di situazioni.

Da un blog post da un ragazzo di Microsoft che ha consultato sulla riscritture:

Molte aziende con cui ho lavorato nei primi giorni di .NET guardò prima riscrittura guidato in parte da un forte desiderio di migliorare la architettura e strutture di codice sottostanti contemporaneamente al loro spostamento su .NET. Sfortunatamente molti di questi progetti sono stati messi in difficoltà e molti non sono mai stati completati. Il problema che stavano cercando di risolvere era troppo grande. [Questo è il punto in cui i suoi colleghi sarebbero in guai seri con il loro capo - le persone vengono licenziati a questo punto]

Dì ai tuoi colleghi di controllare le Microsoft UK advice con un screencast spiegare le 5 opzioni di base per VB6 -> Migrazione VB.Net. Dovrebbero scegliere la strada da seguire in congiunzione con il loro capo. Potrebbe riscrivere, ma dovrebbero entrarci con gli occhi aperti.

E probabilmente non dovrebbero scrivere nient'altro in VB6 ...