Ich bin sehr dagegen, eine Anwendung neu zu schreiben, wenn dies vermieden werden kann. Ich verstehe die Regel, dass es besser ist, 9 von 10 zu refaktorieren, aber ich bin in einer Situation, in der es das eine Mal in 10 sein könnte, und ich suche nach dieser Zeile.

Die aktuelle Situation ist:

Ich habe die Wartung einer VB6 / SQL-Anwendung übernommen. Die Gesamtzahl der Codezeilen beträgt 75-100 KB (Code-Behinds, Module und Klassen).Der ursprüngliche Entwickler ist gegangen, also bin ich es nur, und es gibt keine Möglichkeit, das Team zu erweitern, zumindest nicht für ein paar Jahre. Es gab keine Architektur für das Programm (nur direkte SQL-Aufrufe im Klartext in der Form code-behinds). Versucht nicht, den DRY- oder OAOO-Grundsätzen zu folgen.Datenbank hatte einige Primärschlüssel, aber keine Fremdschlüssel.Bevor dieses System eingeführt wurde, wurde alles in großen Tabellenkalkulationen verwaltet, so dass dieses System wirklich eine enorme Verbesserung gegenüber dem darstellt, was es hatte, aber nicht das tut, was es sich vorstellt.Ich konnte mir einige Tools schreiben, um alle Literalinstanzen von Tabellennamen und Spaltennamen durch Konstanten und Lookups zu ersetzen, und ich schrieb ein schnelles Code-Gen-Skript, um diese Konstanten und Lookups aus der Datenbank zu generieren kann sicher Datenbankänderungen vornehmen und überall sehen, was kaputt ging. Ich habe angefangen, die Datenbank "an den Rändern" zu normalisieren, aber es sind ungefähr 3% des Weges dorthin.Es gibt keine Komponententests, daher muss ich jedes Mal, wenn ich die Datenbank ändere, die darauf befindliche Logik neu schreiben und die beiden Versionen verwenden, um die Funktionalität zu vergleichen und sicherzustellen, dass sie gleich ist. So weit, ist es gut Ich habe zunächst nur versucht, kritische Fehler zu beheben, um die Blutung zu stoppen, und ich kann mit Sicherheit sagen, dass dies größtenteils der Fall ist. Jetzt trete ich einen Moment zurück, um das Gesamtbild zu betrachten.Management ist unterstützend und vernünftig in ihren Erwartungen.Das langfristige Ziel ist es, es trotzdem nach .NET zu konvertieren ...

Also, ich wiege diese Optionen:

Normalisieren Sie die Datenbank weiter und ändern Sie die VB6-App, während ich fortfahre (am Ende wird es Stück für Stück neu geschrieben) Versetzen Sie den VB6 one in einen Nur-Wartung-Status (keine neuen Funktionen), wählen Sie jeweils ein Funktionsmodul aus und schreiben Sie diesen Teil in .NET auf eine normalisierte Datenbankstruktur.

Meine Meinung ist, dass ich, wenn ich Option 1 wähle, am Ende nur eine VB6-App habe, die immer noch auf .NET aktualisiert werden soll. Ich habe mir das angeschaut und es ist kostspielig und zeitaufwendig und sogar mit den Tools Sie werden immer noch etwas bekommen, das ein bisschen wie ein Frankenstein ist. Wenn ich mich für Option 2 entscheide, bin ich der Meinung, dass ich schneller fertig bin und direkt zur Zieltechnologie springen kann.

In den kleinen Teilen, die ich während meines Normalisierungsprozesses bereits umgeschrieben habe, ist das Ergebnis ein verbessertes Modul im Vergleich zu dem, was bereits vorhanden war, sodass während des Umschreibens ein Mehrwert erzielt wird.

Die vorhandene App ist trotz aller Mängel ein guter Diskussionspunkt. Die Leute, die es benutzen, können mir sagen, was für sie funktioniert und was nich

So, qualifiziert sich dies als eines dieser "eins zu zehn" Male oder nicht?