Legacy-Code wird mit dem Alter schlechter

Legacy-Code reift nicht wie Wein. Er wird jeden Tag schlimmer, an dem man ihn ignoriert.

Letzte Woche habe ich drei Stunden damit verbracht, ein Problem zu debuggen, das eigentlich nur 20 Minuten dauern sollte. Der Übeltäter war ein Validierungsmodul aus dem Jahr 2019. Die Leute haben es in Ruhe gelassen, weil es funktionierte. Es funktionierte nicht. Ich fand einen „TODO: refactor this“-Kommentar aus dem Jahr 2020.

Viele behandeln Legacy-Code als optionalen Schuldposten. Sie denken, sie werden ihn zurückzahlen, wenn sie Zeit haben. Legacy-Code wirkt wie Schimmel. Er breitet sich aus. Er infiziert alles um sich herum. Je länger man wartet, desto teurer wird die Bereinigung.

Der Zyklus ist vorhersehbar:

  • Man erbt ein unordentliches, aber funktionierendes Feature.
  • Man fügt ein weiteres „if“ hinzu, damit es funktioniert.
  • Sechs Monate später macht jemand anderes dasselbe.
  • Ein Jahr später hat die Datei 800 Zeilen und null Tests.

Diese versteckten Kosten schlagen sich auf drei Arten nieder:

  • Die Geschwindigkeit sinkt. Man verbringt mehr Zeit damit, den Kontext zu verstehen, als Code zu schreiben.
  • Die Anzahl der Bugs steigt. Ein Fix macht etwas anderes kaputt, weil die Logik verstrickt ist.
  • Das Onboarding scheitert. Neue Entwickler haben Schwierigkeiten zu verstehen, warum dieselbe Logik an sieben verschiedenen Stellen existiert.

Achten Sie auf diese Warnsignale:

  • Nutzlose Kommentare wie „HACK: do not touch this.“.
  • Doppelte Geschäftslogik in verschiedenen Dateien.
  • Zirkuläre Abhängigkeiten, bei denen Dienste voneinander abhängen.

Schreiben Sie nicht alles neu. Vollständige Neuschreibungen scheitern in 80 % der Fälle. Nutzen Sie stattdessen inkrementelles Refactoring mit Characterization Tests.

Folgen Sie diesem Prozess:

  • Erfassen Sie das aktuelle Verhalten mit Tests, auch die seltsamen Teile.
  • Refactoren Sie den Code, ohne dieses Verhalten zu ändern.
  • Wiederholen Sie dies, bis der Code lesbar ist.
  • Ändern Sie das Verhalten erst, wenn Sie echte Tests haben.

Regeln, die man befolgen sollte:

  • Refactoren Sie niemals ohne Tests.
  • Vermeiden Sie Verbesserungen, die das Verhalten des Codes ändern. Ein Bug könnte ein Feature sein, auf das sich ein Kunde verlässt.
  • Lassen Sie „stillen“ Code in Ruhe. Wenn sich ein Modul seit drei Jahren nicht geändert hat und keine Probleme verursacht, rühren Sie es nicht an.

Konzentrieren Sie Ihre Energie auf den Code, den Sie häufig anfassen.

Quelle: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h