Sollten Sie Legacy-Code in C# neu schreiben? Ein tieferer Blick auf die Meinung von Derek Comartin

Das "Niemals Code neu schreiben"-Prinzip

Derek beginnt mit dem altbekannten Ratschlag, der in der Softwareentwicklung oft gegeben wird: Niemals Code von Grund auf neu schreiben. Dieser Ratschlag geht auf einen berühmten Blogbeitrag von Joel Spolsky mit dem Titel "Things You Should Never Do" zurück, in dem eindringlich davor gewarnt wird, Altsysteme neu zu schreiben.

Bei 0:32 weist Derek auf die wichtigste Idee aus Spolskys Beitrag hin:

"Sie haben den schlimmsten strategischen Fehler gemacht, den ein Softwareunternehmen machen kann: Sie beschlossen, den Code von Grund auf neu zu schreiben."

Derek erklärt, dass die wichtigste Erkenntnis lautet: Wenn man ganz von vorne anfängt, gibt es keinen Grund zu glauben, dass man es unbedingt besser machen wird als beim ersten Mal. Besonders bei großen, komplexen Systemen unterschätzt man leicht den versteckten Wert, der in der aktuellen Implementierung steckt.

Die Illusion der Einfachheit

Bei 1:07 reflektiert Derek über seine Anfänge als Juniorentwickler. Wie viele andere wollte er oft große Teile eines Systems neu schreiben, einfach weil er den Code für schlecht hielt. Später stellte er jedoch fest, dass diese Annahme oft darauf zurückzuführen war, dass er den Code nicht verstand, und nicht darauf, dass der Code selbst von Natur aus schlecht war.

Er teilt eine nachvollziehbare Wahrheit:

"Es ist einfacher, etwas von Grund auf neu zu beginnen, als sich wirklich in die Codebasis, die ganze Komplexität und die Randfälle einzuarbeiten - das ist wirklich schwierig."

Was wie ein "Reifenbrand" aussieht, könnte im Grunde genommen nur missverstandene Logik sein, die in jahrelange Entwicklung und Patches verpackt ist. Entwickler verwechseln oft Unkenntnis mit schlechtem Design.

Wann sind Neufassungen gerechtfertigt

Dennoch sagt Derek nicht, dass Neufassungen immer schlecht sind. Bei etwa 1:44 beginnt er, Nuancen einzuführen. Für Teams, die seit Jahren mit derselben Codebasis arbeiten, die die Komplexität der Domäne und die Systembeschränkungen kennen, könnte das Umschreiben eine gute Option sein.

"Wenn Sie schon sehr lange in einem System arbeiten... und dann kommt die Nuance ins Spiel. Sie können sagen: Ja, das Ding ist ein Reifenfeuer und hält uns zurück. Vielleicht ist es angebracht, den Text neu zu schreiben. "

"Schlechter ist besser" und die 80/20-Regel

Derek stellt bei 2:01 das Konzept "Schlechter ist besser" vor und bringt es mit dem Pareto-Prinzip (80/20-Regel) in Verbindung. Er argumentiert, dass oft 80 % des Wertes eines Systems aus nur 20 % der Codebasis stammen. Das Ziel beim Umschreiben sollte also nicht sein, alles zu wiederholen, sondern sich auf den Kern zu konzentrieren, der wirklich einen Mehrwert bietet.

"Es gibt einen Punkt, an dem weniger Funktionalität - schlechter - die bessere Option ist."

Er erklärt, dass Einfachheit und Praktikabilität oft wichtiger sind als Vollständigkeit. Ein begrenztes, aber nutzbares und wartbares System ist besser als eine ausufernde, aber schwer zu wartende Legacy-Plattform.

Kosten-Nutzen-Abwägung

Bei 2:47 schlägt Derek vor, dass die endgültige Entscheidung oft auf eine Kosten-Nutzen-Analyse hinausläuft. Umschreiben um des Umschreibens willen ist niemals gerechtfertigt. Wenn jedoch die Kosten für die Beibehaltung des alten Codes oder die Einschränkung durch die alte Technologie höher sind als die Kosten für eine Neuentwicklung, dann kann sich die Gleichung zugunsten einer Neufassung verschieben.

Er verweist auf Situationen, in denen Ihr Wettbewerbsvorteil behindert wird, weil Sie auf veralteten Plattformen oder Tools festsitzen. In solchen Fällen wird die technologische Lücke selbst zu einem triftigen Grund für einen Neuaufbau.

Eine Lektion von Greg Young

Derek weist auf einen brillanten Beitrag von Greg Young bei 3:12 hin, in dem ein Prototyp, der es versehentlich in die Produktion geschafft hat, neu geschrieben wurde. Die Neufassung dauerte 9 Monate. Das Ergebnis?

"Nach neun Monaten schöner Architektur- und Code-Arbeit haben wir ungefähr 10.000 Dollar mehr im Monat verdient."

Greg kam zu dem Schluss, dass es besser gewesen wäre, 30 neue Prototypen zu erstellen, um neue Strategien zu testen, anstatt viel Geld in die Neuentwicklung dieses einen zu investieren. Derek liebt diese Schlussfolgerung, weil sie die Annahme in Frage stellt, dass technische Perfektion immer das Ziel ist.

Manchmal gewinnt die Software, die "gut genug" ist - vor allem, wenn sie bereits einen geschäftlichen Nutzen bringt.

Das Vorurteil "Alt gegen Neu"

Bei 4:20 spricht Derek die verbreitete Meinung an, dass alt schlecht und neu gut ist. Er bietet ein persönliches Beispiel: Er integriert zwei Dienste von Drittanbietern, die denselben Zweck erfüllen. Eine davon verwendet modernes JSON und ist wahrscheinlich in Python erstellt. Die andere gibt überraschenderweise XML zurück und wurde wahrscheinlich in ColdFusion in den 1990er Jahren erstellt.

"Sie sind beide gleichwertig. Sie sind stabil. Sie bieten mir und meinen Kunden den gleichen Nutzen. "

Dies unterstreicht, dass neuer nicht immer besser ist. Stabilität, Zuverlässigkeit und Nützlichkeit sind oft wichtiger als der technische Stack.

Dereks persönliche Rewrite-Erfahrung

Bei 5:31 erzählt Derek schließlich seine eigene Geschichte. Er war an einer groß angelegten Neufassung beteiligt, nachdem er über sechs Jahre im Bereich des ursprünglichen Systems verbracht hatte. Die Neufassung dauerte etwa 14 Monate und wurde hauptsächlich durch eine technologische Lücke verursacht, die die Fähigkeit des Systems zur Integration mit modernen E-Commerce-Tools und Online-Diensten einschränkte.

"Wir mussten für diesen Zweck wirklich etwas Neues aufbauen"

Es handelte sich nicht nur um einen "schlechten Code" - das System war grundsätzlich nicht entwicklungsfähig, so dass ein Neuaufbau der einzige gangbare Weg war.

Abschließende Gedanken

Am Ende des Videos, etwa bei 6:11, betont Derek, dass die Antwort nicht einfach "ja" oder "nein" lautet

"Ich denke nicht, dass die eindeutige Antwort nein lautet. Ich denke, man sollte bei dieser Entscheidung vorsichtig sein, denn es kommt auf den Kontext an, und da gibt es eine Menge Nuancen."

Das Umschreiben von altem C#-Code kann notwendig sein - aber nur, wenn der Kontext, das Fachwissen, die Wertschöpfung und die technischen Einschränkungen diese Entscheidung unterstützen.

Abschluss

Derek Comartins Video ist ein ausgewogener, erfahrungsbasierter Beitrag zu einem der meistdiskutierten Themen der Softwareentwicklung: Sollte man veralteten Code umschreiben? Seine Ratschläge sind nicht dogmatisch, sondern durchdacht, fundiert und reich an persönlichen Einsichten.

Indem er über historische Lektionen, Geschichten aus der Praxis und die Falle "neu ist besser" nachdenkt, hilft Derek den Betrachtern, einen ausgereiften Rahmen für eine der folgenreichsten Entscheidungen in der Softwarearchitektur zu entwickeln.

Wenn Sie in Ihrem eigenen C#-Projekt vor einer ähnlichen Entscheidung stehen, sollten Sie sich das Video von Derek noch einmal ansehen und Ihren Kontext sorgfältig abwägen. Manchmal ist Legacy-Code nicht der Feind - er wird nur missverstanden.

Weitere aufschlussreiche Videos finden Sie auf Dereks YouTube-Kanal. Besuchen Sie CodeOpinion.com für weitere Inhalte von Derek.