Distanza tra la base del codice e l'applicazione di produzione

Naviga le tue risposte
2

Sfondo

Sono entrato in un'azienda come architetto di soluzioni meno di un anno fa, con il compito principale di consolidare e modernizzare il codice legacy derivante da oltre 90 acquisizioni di aziende negli ultimi 20 anni.

Una di queste applicazioni legacy, è un'applicazione desktop scritta in VB 6.0 che accede a un database di SQL Server e ha logiche di business incorporate nel lato client. Questa era la buona notizia!

La cattiva notizia è che la versione di produzione di questo client che risiede sui computer degli utenti finali è di due rilasci dopo l'ultimo controllo del codice nel nostro sistema di controllo del codice sorgente (che è un intervallo di 5 anni).

Cosa ho fatto fino ad ora

Ho installato Enterprise VB 6.0 IDE e ho tentato di caricare il codice sorgente più recente e ho provato a trasferire l'applicazione nei moduli principali, basandomi su voci di menu definite nel modulo principale.

Ho usato una sorta di mappa mentale come un diagramma per elencare quelle voci di menu e identificato la funzione principale di ciascuno di questi elementi, in termini di accesso e elaborazione dei dati.

Fortunatamente, 8 voci di menu su 162 elementi sono decorazioni inutili, ma il resto indica la reale logica aziendale e l'accesso ai dati.

Che cosa intendevo fare dopo

  1. Identifica le tabelle del database accessibili da ciascuna voce di menu
  2. Identifica le relazioni tra quelle tabelle in termini di trigger, chiavi referenziali e procedure memorizzate possibili
  3. Costruisci un'applicazione web .NET scheletro
  4. Tentativo di dedurre alcuni diagrammi del flusso di lavoro per uno dei moduli principali di questa applicazione
  5. Estrai la logica del modulo identificato e implementala nell'applicazione .NET con gli hook al database originale
  6. Convinca gli utenti a utilizzare le nuove schermate fornite.
  7. Iterare sui passaggi precedenti fino a quando tutte le funzioni coperte dall'applicazione legacy vengono migrate nella moderna applicazione Web.
  8. Dopo aver migrato tutte le schermate e la logica di business, dovrei iniziare a refactoring gli oggetti del database.

La mia domanda

IL piano sopra è realistico? è sub-ottimale? Qualche consiglio su un modo più pratico di affrontare questa bestia?

Grazie e scusa per la lunga domanda

    
posta A.Rashad 24.08.2017 - 20:16
fonte

1 risposta

4

Quindi sembra che tu stia pianificando di riscrivere l'applicazione originale passo passo e sostituirla con una nuova applicazione. A seconda della logica dell'applicazione, un approccio "passo-passo" è possibile o meno possibile e potrebbe essere un approccio ragionevole.

Tuttavia, per un'applicazione a 100k LOC, se la nuova implementazione sarà più o meno delle stesse dimensioni del vecchio, il mio istinto mi dice che dovresti aspettarti uno sforzo totale di qualcosa tra 2 e 4 anni (all'incirca). Naturalmente, questa è solo un'ipotesi e dipenderà da una dozzina di fattori come il team coinvolto, dalla necessità di migrare l'intera applicazione o solo parti di esso, dalla capacità di analizzare la logica aziendale sconosciuta e così via . Ma dovrebbe darti un'idea dei costi che devi aspettarti, così tu o la tua azienda potete considerare se ne vale la pena o meno. Dovresti anche avere familiarità con gli argomenti in l'avvertimento di Joel Spolskie contro grandi riscritture , tuttavia, questo articolo presuppone che tu abbia alcune alternative basate sull'evoluzione e il refactoring del codice sorgente originale.

Prima di percorrere questa strada, potrebbe valere la pena considerare alcune alternative che potrebbero rivelarsi più economiche:

  • prova a tenere traccia di dove vivono gli ex sviluppatori e se qualcuno di loro potrebbe avere una copia archiviata dell'origine di produzione effettiva (o almeno una versione più recente di quella che hai). Uno stipendio di due settimane per un investigatore professionista sarà probabilmente molto meno di uno stipendio di 2 anni di uno sviluppatore, quindi potrebbe valerne la pena.

  • analizza quanto è grande il divario di funzionalità effettivo tra il codice sorgente disponibile e il rilascio di produzione corrente e fai una stima se potrebbe essere meno costoso reimplementare le differenze mancanti sul codice VB6 disponibile.

  • prova a utilizzare uno dei decompilatori VB6 esistenti. Anche se non produce codice manutenibile o compilabile, potrebbe aiutarti a eseguire il passaggio precedente o a eseguire la migrazione della vecchia applicazione in

Alla fine, questo si riduce a una decisione di gestione. Riscrivere la vecchia cosa potrebbe essere anche una decisione strategica per sbarazzarsi del vecchio codice legacy VB6. Un altro fattore chiave qui è anche quanto sia importante la vecchia applicazione per la tua azienda, o quanto sia importante che l'evoluzione e la correzione dei bug possano aver luogo.

    
risposta data 25.08.2017 - 09:49
fonte

Leggi altre domande sui tag

Fornisce un'implementazione predefinita di fallback per le buone pratiche dei bambini? OLTP vs OLAP - MongoDB