Umschreiben oder reparieren?

Question

Ich bin mir sicher, dass Sie es alle schon einmal erlebt haben: Sie übernehmen ein Projekt, bei dem es eine veraltete Codebasis gibt, die kaum noch ihren Zweck erfüllt, und Sie müssen die Entscheidung treffen, sie entweder von Grund auf neu zu schreiben oder das, was bereits vorhanden ist, zu reparieren.

Die gängige Meinung besagt, dass Sie niemals versuchen sollten, den Text von Grund auf neu zu schreiben, da das Risiko eines Scheiterns sehr hoch ist.Was haben Sie angesichts dieses Problems getan, wie haben Sie die Entscheidung getroffen und wie ist sie ausgegangen?

Answer 1

Es kommt wirklich darauf an, wie schlimm es ist.

Wenn es sich um ein kleines System handelt und Sie es vollständig verstehen, ist ein Umschreiben nicht verrückt.

Wenn es sich hingegen um ein riesiges Legacy-Monster mit zehn Millionen Zeilen undokumentiertem Mystery-Code handelt, wird es Ihnen mit einer vollständigen Neufassung wirklich schwer fallen.

Punkte, die man beachten sollte:

• Wenn es für den Benutzer gut aussieht, ist es ihnen egal, welche Art von Spaghetti -Chaos das für Sie ist.Auf der anderen Seite ist es einfacher, sich zu vereinbaren (und Geduld) zu machen, wenn es auch schlecht für sie ist.
• Wenn Sie neu schreiben, versuchen Sie es jeweils jeweils zu tun.Eine unordentliche, unorganisierte Codebasis kann dies schwierig machen (dh nur ein Teil erfordert eine Umschreibung großer Eisbergs von Abhängigkeitscode), aber wenn möglich, erleichtert dies viel einfacher, das Umschreiben allmählich durchzuführen und auf dem Weg Feedback von Benutzern zu erhalten .

Ich würde wirklich zögern, ein riesiges Umschreibungsprojekt für ein großes System in Angriff zu nehmen, ohne die neue Edition Teil für Teil veröffentlichen zu können.

Answer 2

Bereinigen Sie einfach den Code jedes Mal ein wenig, wenn Sie damit arbeiten.Falls noch keins vorhanden ist, richten Sie ein Unit-Testing-Framework ein.Für jeden neuen Code sollten Tests geschrieben werden.Wenn Sie alten Code aufgrund von Fehlern reparieren, versuchen Sie, auch Tests einzubauen.

Während die Bereinigung voranschreitet, können Sie immer mehr schädlichen Code in gekapselte Behälter fegen.Dann können Sie diese in Zukunft einzeln auswählen.

Ein Tool wie Javadoc oder Doxygen kann ebenfalls dabei helfen, die Code-Dokumentation und -Verständlichkeit zu verbessern, sofern sie nicht bereits verwendet werden.

Die Argumente gegen eine komplette Neufassung sind ziemlich stark.Die Unmengen an „kleinen Fehlern“ und Verhaltensweisen, die im Laufe des ursprünglichen Projekts einprogrammiert wurden, werden sich sofort wieder einschleichen.

Answer 3

Siehe Joel Spolskys Aufsatz Dinge, die Sie niemals tun sollten.Zusammenfassend lässt sich sagen, dass Sie beim Umschreiben alle Lektionen verlieren, die Sie gelernt haben, damit Ihr aktueller Code so funktioniert, wie er funktionieren muss.

Siehe auch: Großer Schlammball

Answer 4

Es ist selten, dass das Umschreiben einer komplexen Sache erfolgreich ist.Es ist verlockend, aber eine Strategie mit niedrigem Prozentsatz.

Unterziehen Sie Legacy-Code Unit-Tests, überarbeiten Sie ihn und/oder ersetzen Sie bei Bedarf kleine Teile davon inkrementell vollständig.

Answer 5

Refaktorieren, es sei denn, es ist wirklich sehr schlecht.

Joel hat dazu viel zu sagen ...

Schreiben Sie den Code zumindest mit dem alten Code vor sich neu und fangen Sie nicht einfach von vorne an.Der alte Code mag schrecklich sein, aber er ist aus einem bestimmten Grund so, und wenn Sie ihn ignorieren, werden Sie am Ende dieselben Fehler sehen, die wahrscheinlich vor Jahren im alten Code behoben wurden.

Answer 6

Ein Grund für das Umschreiben bei einem meiner früheren Jobs war die Unfähigkeit, Entwickler mit ausreichend Erfahrung für die Arbeit an der ursprünglichen Codebasis zu finden.

Es wurde beschlossen, zunächst die zugrunde liegende Datenbankstruktur zu bereinigen und sie dann in etwas umzuschreiben, das das Auffinden von Vollzeitmitarbeitern und/oder Auftragnehmern erleichtert.

Ich habe noch nicht gehört, wie es geklappt hat :)

Ich denke, die Leute neigen dazu, sich für Neufassungen zu entscheiden, weil es oberflächlich betrachtet mehr Spaß zu machen scheint.

Wir können von Grund auf neu aufbauen!

Wir machen es richtig diesmal!

usw.

Answer 7

Es erscheint ein neues Buch, Brownfield-Anwendungsentwicklung in .NET von Baley und Belcham.Das erste Kapitel ist kostenlos und behandelt diese Themen aus einer überwiegend plattformunabhängigen Perspektive.

Answer 8

Reparieren oder, was noch wichtiger ist, Refactoring.Beides, weil Joel hat es gesagt und auch, weil Sie, wenn es sich um Ihren Code handelt, wahrscheinlich eine Menge mehr gelernt haben, seit Sie diesen Code das letzte Mal berührt haben.Wenn Sie es in .NET 1.1 geschrieben haben, können Sie es auf 3.5 SP1 aktualisieren.Sie können hineingehen und den gesamten alten auskommentierten Code löschen.Als Entwickler sind Sie jetzt 100-mal besser als damals, als Sie diesen Code zum ersten Mal geschrieben haben.

Ich denke, die einzige Ausnahme besteht darin, dass der Code wirklich veraltete Technologien verwendet. In diesem Fall ist es möglicherweise besser, eine neue Version zu schreiben.Wenn Sie sich eine VB6-App mit 10.000 Codezeilen und einem Access-Datenbank-Backend ansehen, das offensichtlich von jemandem eingerichtet wurde, der nicht viel über die Funktionsweise von Datenbanken wusste (was durchaus auch Sie vor acht Jahren sein könnten), dann können Sie wahrscheinlich darauf zurückgreifen Erstellen Sie eine schnellere, C#/SQL-basierte Lösung in einem Bruchteil der Zeit und des Codes.

Answer 9

Es ist nicht so schwarz und weiß...Es hängt wirklich von vielen Faktoren ab (der wichtigere ist: „Was verlangt die Person, die Sie bezahlt), von Ihnen?“

Wo ich arbeite, haben wir ein Entwicklungsframework neu geschrieben, und andererseits modifizieren wir ständig einige alte Systeme, die nicht migriert werden können (aufgrund der Technologie und der Zeitbeschränkungen des Kunden).In diesem Fall versuchen wir, den Codierungsstil beizubehalten, und manchmal müssen aufgrund der Art und Weise, wie er erstellt wurde, viele Problemumgehungen implementiert werden

Answer 10

Abhängig von Ihrer Situation, Sie könnte habe noch eine andere Möglichkeit:Einlizenzierter Code von Drittanbietern.

Ich habe mich bei einigen Unternehmen beraten lassen, bei denen dies die vernünftige Wahl wäre, obwohl das scheinbare „Wegwerfen von geistigem Eigentum“ eine große Hürde für das Management darstellen kann.In meinem jetzigen Unternehmen haben wir ernsthaft darüber nachgedacht, unser Kern-Framework durch Code von Drittanbietern zu ersetzen, aber diese Idee wurde letztendlich eher aus geschäftlichen als aus technischen Gründen abgelehnt.

Um Ihre Frage direkt zu beantworten, haben wir uns schließlich entschieden, das alte Framework neu zu schreiben – eine Entscheidung, die wir nicht leichtfertig getroffen haben!14 Monate später bereuen wir diese Entscheidung überhaupt nicht.Allein wenn man den Zeitaufwand für die Behebung von Fehlern bedenkt, hat sich unser neues Framework fast amortisiert.Der Nachteil ist, dass der Funktionsumfang noch nicht ganz vollständig ist, sodass wir uns in der wenig beneidenswerten Lage befinden, zwei separate Frameworks parallel zu verwalten, bis wir die letzte unserer „Front-End“-Anwendungen portieren können.

Answer 11

Ich empfehle dringend, „Working Effectively with Legacy Code“ von Michael Feathers zu lesen.Es handelt sich um Coaching-Ratschläge, wie Sie Ihren Code so umgestalten, dass er Unit-testbar ist.