2009-03-25 4 views
5

Ich arbeite an einer großen Codebasis mit einer großen Installationsbasis von Benutzern. Der Code wurde ursprünglich in vb6 mit einigen C++ COM-Modulen für Low-Level-Arbeit geschrieben.Wie entwickeln Sie weiterhin große (langfristige) Softwaresysteme mit altem und neuem Code?

Es ist völlig unmöglich, den gesamten Code, der bereits in vb6 geschrieben ist und von unseren Kunden täglich verwendet wird, neu zu schreiben, aber wir machen auch weiterhin Verbesserungen und Anpassungen an der Software (groß und klein).

Meine bisherige Lösung ist es, den größten Teil des neuen Codes in C# zu schreiben (winforms und sogar wpf jetzt) ​​und dann COM Interop zu verwenden, um die Module von vb6 aufzurufen.

Hat jemand Erfahrung mit langfristigen Software-Suiten wie diese (10+ Jahre), die nicht für eine komplette Neuschreibung gestoppt werden können, aber ständig neue Entwicklung zur gleichen Zeit brauchen. Auch in gemischten Systemen, wie ist der beste Weg, um die Module zu verbinden? Ich benutze COM jetzt, aber habe IPC mit getrennten Prozessen auch betrachtet.

Antwort

5

Es ist schwer, eine umfassende Antwort zu geben, aber der Ansatz auf hoher Ebene ist klar. Zumindest ist dies der Ansatz, den ich verwendet habe. Priorisieren Sie Ihre Ziele und versuchen Sie dann, die Kosten für das Erreichen dieser Ziele zu ermitteln. Ihre Kosten werden im Wesentlichen auf "Entwicklerzeit" reduziert.

Zuerst wollen Sie, was auch immer funktioniert, um weiter zu arbeiten. Wenn Sie etwas haben, das funktioniert, und es keinen Grund gibt, es umzuschreiben, behalten Sie es.

Wenn ein Teil Ihres vorhandenen Codes aktualisiert werden muss, um seine Aufgabe zu erfüllen, dann sehen Sie sich Wartungskosten an. An diesem Punkt müssen Sie feststellen, ob ein Neuschreiben die Wartungskosten so weit erhöht, dass es sich lohnt. Vergessen Sie nicht, das Testen und Debuggen neuer Fehler zu subtrahieren, da es neue Fehler geben wird. Verwerfen Sie den Arbeitscode nicht, nur weil er alt ist.

Wenn Ihr vorhandener Code ausreichend modular ist, können Sie ihn normalerweise Stück für Stück abschneiden. Schreiben Sie die wartungsintensiven Komponenten zuerst neu.

Wenn Sie eine neue Entwicklung in C# durchführen, sollten Sie mit den COM-Komponenten arbeiten, bis Sie genug Gründe haben, sie zu ersetzen.

0

Ich denke, Sie müssen Ihre Upgrade-Pfade für Ihre Kunden betrachten. Tatsache ist, dass Sie irgendwann, wenn sie 16 CPUs haben, Gleichlauf benötigen, um die Dinge zu beschleunigen. Sie haben also einen Business Case, um von VB6 in Richtung WCF zu wechseln. WCF hat Unterstützung für Parallelität und Synchronisierung integriert. Es kann sowohl für die lokale prozessinterne Kommunikation als auch für die prozessübergreifende und maschinenübergreifende Kommunikation verwendet werden. Es hat auch den Vorteil, dass Sie mehr AOP-Stil programmieren können.

3

Ich denke, Sie haben einen guten Plan. Dies wird schließlich den größten Teil des Codes in C# verschieben und den Vorteil des besseren Toolsets nutzen.

Umfasst der VB6-Code COM-Objekte?

Sie erwähnten, dass der Code "nicht für ein vollständiges Neuschreiben gestoppt werden kann". Aber du musst nicht aufhören. Einer nach dem anderen können Sie jeden Teil der VB6-Funktionalität durch den entsprechenden C# -Code ersetzen. Auf diese Weise können Sie jeweils eine Änderung vornehmen (vorzugsweise mit automatisierten Tests, um zu beweisen, dass Sie nichts kaputt gegangen sind).

+0

Ich stimme dem vollkommen zu. Das schrittweise Überschreiben Ihrer VB6-Module über viele Releases hinweg ist der richtige Weg. Es gibt nichts, was Ihr Team daran hindern könnte, neue Funktionen zu entwickeln, während einige von Ihnen langsam den älteren Code umgestalten. –

+0

... aber OTOH, inkrementelle Umschreibungen erfordern auch viel Koordination, großzügige Instrumentierung und ausgereifte Teststrategien, wenn Sie Qualität und Kosten unter Kontrolle halten wollen. Ich habe viele monolithische VB6-Lösungen gesehen, die dem Refactoring aktiv widerstehen! –

+0

Aber wenn Ihre Anwendung "resistent" ist, dann haben Sie auf jeden Fall Probleme. Dies könnte ein guter Grund sein, umzuschreiben. –

3

Neuschreiben auf Bedarfsbasis, wenn ein Motivationsfaktor vorhanden ist.

Ein altes Windows-Projekt, an dem ich arbeitete, hatte eine in C geschriebene Regel-Engine, die funktionierte, so dass wir sie einfach als Black-Box-DLL belassen.

Wir bauten ein neues Frontend und die Benutzerbasis war beeindruckt von dem einfach zu bedienenden neuen modernen Look der Anwendung. Nichts in den Interna hatte sich wirklich verändert.

Die Datenbankzugriffsebene verwendete SQL Server-DBLIB und wurde erst wieder aktualisiert, als wir SQL Server aktualisierten.

0

Ich bin derzeit einer von mehreren Entwicklern, die an einem großen Legacy-System arbeiten, das als Kombination aus C und C++ mit Win32 und später MFC mit einer kleinen Ansammlung von Back-End-C-Code begann. Wir haben kürzlich von VC++ 6 nach Visual Studio 2005 gewechselt (und seitdem auf 2008 aktualisiert) für die neueste Version des Projekts, an dem wir gerade arbeiten. Seit dem Upgrade des IDE/Compilers haben wir das Look-and-Feel aufgeräumt und haben nun C++ mit WinForms und jetzt C# mit WCF hinzugefügt.

Während die Grundlagen unseres Systems, einschließlich des Backends, fast definitiv in C bleiben werden (zumindest in absehbarer Zukunft), wird alles, was im Frontend neu ist, höchstwahrscheinlich in C#/WCF gemacht. Wenn wir Zeit und/oder Bedarf haben, wollen wir damit beginnen, ältere Teile des Frontends durch gleichwertigen C#/WCF-Code zu ersetzen.

1

Wir haben mehrere Systeme dieser Art. Der störende Teil von all dem ist der lifecycle support status of VB6. Es besteht ein Risiko (wie klein auch immer), dass Sie keine Hilfe von Microsoft mit einem Showstopper-Problem mit z. ein zukünftiges Server-Upgrade, und wird nicht in der Lage sein, es selbst zu reparieren (sagen wir aufgrund von Inkompatibilitäten zwischen den VB6-DLLs und dem gepatchten Server O/S). Dies ist ein Risiko, an dem Ihr Management interessiert sein könnte. Aber wenn Sie jetzt keine Support-Vereinbarungen haben, sind sie vielleicht damit einverstanden?

Wir schauen uns tatsächlich an, einige der kritischeren zu überarbeiten und neu zu gestalten. Wir haben inkrementelle Evolution versucht, und es kann funktionieren, macht aber eine (sagen wir mal) interessante Betriebs- und Wartungssituation. Ich empfehle dringend, alles (alten und neuen Code) mit reichlich konfigurierbarer Protokollierung zu versehen, falls Sie es nicht bereits sind, um die Fehlerisolierung zu unterstützen.

COM klingt wie eine vernünftige Schnittstelle zwischen Alt und Neu. Wenn Sie nicht sehr einfache Interaktionen zwischen Komponenten haben, kann ich nicht wirklich sehen, warum Sie zurück zu einem einfacheren IPC-Mechanismus möchten. COM hat seine Komplexitäten, aber es bietet auch eine Menge nützlicher Abstraktionen für z.B. Dateneingabe und Versionierung, die Sie neu erfinden und pflegen müssten ...

Verwandte Themen