Würden Sie unter .NET vollständig neu gestalten?

Question

Eine sehr umfangreiche Anwendung begann als Zugriffssystem (für Datenbankspeicher). Die Formulare wurden in VB5 und/oder VB6 geschrieben. Da .NET zu einem festen Bestandteil der Entwicklungsgemeinschaft wurde, wurden bestimmte Module neu geschrieben. Dies scheint sehr unangenehm und potenziell kostspielig zu sein, um aufgrund der Civioltechnologien und zusätzlichen Arbeiten zu erhalten, um die beiden Technologien miteinander zu beschäftigen. Natürlich verwendet die Anwendung eine Mischung aus ODBC OLEDB und MySQL.

Würden Sie denken, dass die Zeit und die Ressourcen für die vollständige Entwicklung der Anwendung unter .NET kostengünstiger sind? Würde es nicht sinnvoll sein, .NET zu verwenden, um eine stabilere Anwendung zu entwickeln? Oder verfolgen Sie weiterhin Zugriffsfehler, fügen neue Funktionen in .NET hinzu (die möglicherweise neue Fehler zwischen .NET und Access erzeugt oder nicht) und schreiben alte Zugriffsmodule in .NET -Module unter Zeitbeschränkungen um, die eine ordnungsgemäße Gestaltung und Entwicklung verhindern?

AktualisierenDie Anwendung verwendet OLEDB und MySQL - ich habe meine vorherige Anweisung korrigiert.

Auch um das Umschreiben weiter zu unterstützen: Ich habe seitdem herausgefunden, dass wenn der "Porting" Für .NET begann der existierende VBA/VB6 -Code, der im Grunde genommen in das .NET -Äquivalent übersetzt wurde. Nach meinem Verständnis wurde nichts unternommen, um die Leistung zu verbessern oder neue Bibliotheken oder Technologien zu nutzen.

Meiner Meinung nach schafft dies eine sehr fragile und instabile Anwendung. Mit jedem neuen Update wird dies immer sichtbarer. Als Helpdesk -Techniker habe ich eine Zunahme der gemeldeten Probleme festgestellt. Die Kunden, die die Software verwenden, haben eine Zunahme der Probleme festgestellt und kommentieren sie.

Answer 1

Viele Menschen entmutigen eine Anwendung von Grund auf neu und manchmal stimme ich der Argumentation zu. Aber in den meisten Fällen finde ich die App die am wenigsten schmerzhafte Lösung, und alles, was in Zugriff geschrieben wurde, muss auf .NET -Periode portiert werden. Verstehen Sie mich nicht falsch, der Zugang hat seinen Platz und kann einer Organisation eine Menge Funktionen liefern. Wenn er jedoch zu einer vollwertigen App wird, auf die sich die Leute verlassen, hat sie den Zugang ausgewachsen.

Es würde wahrscheinlich nicht viel Zeit in Anspruch nehmen, die Extisting -VBA in eins für eine Konvertierung zu portieren. Aber das ist vielleicht keine großartige Lösung, wenn die VBA zunächst nicht sehr gut ist. Das Schreiben dauert länger, um eine Neugestaltung/Umschreibung zu schreiben, aber auf lange Sicht ist es viel einfacher zu pflegen.

Ich bin fast immer im Lager, es von Grund auf neu zu schreiben, wo der Zugang betroffen ist und es nicht einmal bereut habe.

Answer 2

Ich stimme dem Refactoring -Ansatz zu. Es ist sehr wahrscheinlich, dass dies ein langsamer Prozess sein wird, der viele Monate dauern kann, aber indem ein Feature / einen Abschnitt zu einem Zeitpunkt bewegt wird, hat jedoch große Vorteile, einschließlich:

1. Produktmerkmale werden beibehalten.
2. Die Fähigkeit, eine neue Version zu liefern, wird beibehalten.
3. Zeitdruck wird entfernt.

Viel Glück

Answer 3

Es ist im Allgemeinen eine entmutigte Praxis, eine Anwendung von Grund auf neu zu schreiben (was ein normaler Drang ist, den die meisten Programmierer mindestens ein paar Mal in ihrem Leben empfunden haben), da Sie von einer App mit bekannten Funktionssatz (und auch bekannte Fehler!) Entwesen werden! zu einer App mit höchstwahrscheinlich weniger Funktionen und vor allem - unbekannten Fehler. Benutzer könnten frustriert werden usw.

Sie wären wahrscheinlich besser dran, wenn Sie Ihre App über einen bestimmten Zeitraum langsam neu ausfüllen würden, wodurch sich die Architektur über einen längeren Zeitraum weiterentwickelt.

Answer 4

Eine große Herausforderung, die ich mit einem Umschreiben dieser Skala erlebt habe, besteht darin, zwei Codebasen gleichzeitig zu verwalten. Wenn Sie einen Fehler im Legacy -System beheben, müssen Sie sicherstellen, dass die Funktionalität im neuen System korrekt funktioniert, und umgekehrt. Das Upgrade eines Moduls gleichzeitig minimiert diese Wartungskopfschmerzen.

Eine vollständige Regressionstestsuite, die sowohl auf den Legacy- als auch auf den Ersatzsystemen ausgeführt wird, wäre ebenfalls hilfreich.

Answer 5

Ich stimme Jas zu, schreibe Apps nicht nur zum Umschreiben von Sake. Sie müssen vielleicht nie debugged oder verbessert werden. Warum also Zeit verschwenden? Wenn Sie jedoch der Meinung sind, dass sich das Fachwissen Ihres neuen Entwicklers nicht zu einem Zugang zu .NET abhebt, müssen Sie möglicherweise migrieren, bevor es zu spät ist. Das erscheint unwahrscheinlich, aber eine mögliche Überlegung.

Wie verbreitet sich die Ausbreitung von Benutzern jedoch nicht rentabel aus Entwicklungsstandpunkten, obwohl es sich um die Ausbreitung von verschiedenen Anwendungen ausbreitet? Benötigt es mehr Benutzertraining? Machen sie mehr Fehler? Erhöht es die Anzahl der Support -Anrufe, weil sie nichts finden können?

Answer 6

"Würden Sie denken, dass die Zeit und die Ressourcen ausgeben, um die Anwendung unter .NET vollständig neu zu entwickeln, kostengünstiger?"

Dies ist keine Frage, die hier beantwortet werden kann.

Von der Spitze der Anforderung Pyramide: Jemand hat eine Entscheidung getroffen, die er hoffentlich mit einem Geschäftsplan rechtfertigen kann. In diesem Geschäftsplan sollte angeben, wie viele Stunden+zusätzliche Kosten für die Umwandlung des Antrags und in demselben Geschäftsplan die Vorteile auch in Bezug auf Geld angegeben werden.

Das ist der Weg, es zu tun. Wenn es keinen Geschäftsplan dafür gibt. Anschließend besteht die Antwort darin, zuerst an einem Geschäftsplan zu arbeiten, der auf einige hochrangige Anwendungsfälle nachgefolgt ist, um die Impact -Analyse durchzuführen, um den Beginn des Projekts zu überprüfen.

Wenn der ursprüngliche Fahrer des Geschäftsziels, der zur Änderung führt, nicht einmal auf Geld basiert, ist diese Person wahrscheinlich diejenige, die dafür bezahlt, also muss es getan werden.

Wenn es keinen Geschäftsplan gibt, aber "es ist einfach fertig", versuchen Sie, einen zu machen und ihn dem oberen Management zu präsentieren. Einbeziehen Sie mit hoher Nutzung von Fällen, Kosten, Stunden für Neugestaltung, Build, zusätzliche Kosten für den Betrieb, neue Schulungen für Administrator und Enduser, Projektmanagement und potenzielle Risiken.

IMHO Das ist keine technische Frage.