Legacy-Code: Abbau technischer Schulden

Hin und wieder haben Unternehmen mit Code zu tun, den andere geschrieben haben. Dies sind die geerbten Codebasen, die nicht mehr als optimal für die Organisationen gelten und als Legacy-Code bezeichnet werden. 

Der Umgang mit solch alten Codebasen ist eine große Herausforderung für die Teams. Und wenn sie nicht richtig gehandhabt werden, bergen diese Codebasen viele versteckte Risiken. 

Dieser Artikel behandelt die Feinheiten von Legacy-Codebasen und die besseren Möglichkeiten, diese mit größtmöglicher Leichtigkeit zu handhaben.

Beginnen wir zunächst mit der Definition von Legacy-Code.

Was ist Legacy-Code?

Die klassische Definition von Legacy-Code ist Code, der von jemandem gewartet wird, der ihn nicht geschrieben hat. Dies bedeutet, dass der Code funktioniert, obwohl niemand wirklich weiß, warum.

Mit der Modernisierung des Anwendungsentwicklungsprozesses wurde auch die Definition von Legacy-Code aufgrund der damit verbundenen Herausforderungen überarbeitet.

Die formale und neueste Definition von Legacy-Code definiert ihn als "fremden" Code, der im Hinblick auf das aktuelle Entwicklungsszenario schwer zu verstehen und schwer zu ändern ist. Solche Codes werden von einem alten Team, anderen Entwicklungsagenturen, Programmierern oder von älteren Softwareversionen übernommen.

Spaghetti-Code und technische Codebasis-Schulden sind andere Namen, die dem Legacy-Code gegeben wurden. 

Herausforderungen im Zusammenhang mit Legacy-Code

Legacy-Code ist alt, er hat funktioniert, aber was macht ihn unfähig? Was ist so schlimm daran? Lesen Sie weiter.

#1 Verwirrung in Schleifen: Früher war der Legacy-Code sinnvoll, er funktionierte so, wie er sollte. Aber je älter er wird, desto unübersichtlicher wird er und bringt viel Verwirrung für die Teams, die ihn warten. 

Schließlich entsteht das Szenario, dass niemand weiß, wie man solche Codebasen wartet oder überarbeitet. Niemand will sich mit einer solchen Codebasis anlegen, da sie mit so vielen Abhängigkeiten verbunden ist. Außerdem wissen die Entwickler möglicherweise nicht, wo sie mit der Behebung solcher Codebasisprobleme beginnen sollen, da die Gefahr besteht, dass sie etwas Grundlegendes in der Codestruktur zerstören, wenn sie es versuchen.

#2 Stabilitätsillusionen: Zum Zeitpunkt seiner Erstellung wurde der Legacy-Code erprobt und getestet, wodurch er für die Arbeitsumgebung sicher war. Aber mit der Entwicklung von Programmiersprachen, Praktiken und Verständnissen verliert der Legacy-Code seine Stabilität. Jedes neue Feature-Update macht ihn noch komplizierter und beeinträchtigt so die Qualität des Codes negativ. 

#3 Refactoring ist entmutigend: Wenn ein Code alt oder veraltet ist, ist es sehr schwierig, ihn an die neuesten Codierungsstandards anzupassen. Die Risiken und Kosten der Aktualisierung von Codes sind recht hoch. Wenn in irgendeinem Fall ein Problem auftritt, wird es schwieriger, es kostengünstig und schnell zu beheben. Dies bedeutet, dass Legacy-Code ein Unternehmen mit seiner Unfähigkeit zur Integration in neue Technologien zurückhalten kann. 

#4 Geld- und Ressourcenausbeutung: Ein Legacy-Code ist eine Art Inventar, und da das Inventar veraltet ist, muss es regelmäßig aktualisiert werden. Da es sich um eine ältere Codebasis handelt, benötigt ein Legacy-Code auch ältere Hardware und Systeme, um zu laufen. Dies beschleunigt die Kosten, da die Integration und Wartung veralteter Systeme oder Hardware teuer ist. 

#5 Prominente Cyberangriffe: Die sich ständig weiterentwickelnden Sicherheitsbedrohungen sind die nächste Gefahr für die Legacy-Codes. Cyberangreifer verfügen über Kenntnisse der Schwächen in älteren Systemen, die ausreichen, um das voll funktionsfähige System lahmzulegen. Wenn das System nicht mit den aktuellen Codierungsstandards übereinstimmt, ist es ein leichtes Ziel für Cyberkriminelle. 

Wenn der Code Ihr Inventar ist, dann müssen Sie ihn bei Bedarf aktualisieren und löschen, wenn er nicht benötigt wird, um mit dem aktuellen Entwicklungsszenario Schritt zu halten. 

Die nächsten Abschnitte beschreiben die Überlegungen und Ansätze für den Umgang mit Legacy-Codes. 

Überlegungen vor dem Umgang mit einem Legacy-Code

Planen Sie, den Legacy-Code zu überarbeiten?

Die folgenden Dinge müssen berücksichtigt werden, bevor weitere Änderungen daran vorgenommen werden.

• Alter des Codes: Technologien, Sprachen und Frameworks werden im Laufe der Zeit tendenziell aktualisiert und verbessert. Wenn wir über die Legacy-Codes sprechen, ermöglicht das Aufkommen neuer und besserer Sprachalternativen den Ersatz von Alt durch Neu. Dies macht es schwierig, Entwickler zu finden, die bereit und in der Lage sind, den Code in seiner Originalsprache zu warten. Die Kenntnis des Alters der Codebasis hilft bei der Entschlüsselung der Grundlagen oder bei der Gewinnung einer Vorstellung von den Anfängen des Codes. 
   
• Anzahl der Iterationen: Veränderung ist die einzige Konstante, wenn es darum geht, konsistente Geschäftsziele und Funktionalitätsanforderungen zu erfüllen. Zahlreiche Iterationen häufen sich an, wenn Aktualisierungen oder Änderungen an den Codes vorgenommen werden. Mit jedem System-Upgrade sind die Entwickler nicht bereit, die alten Funktionen zu entfernen. Dies macht den Code kompliziert zu handhaben mit vielen doppelten Funktionalitäten und unerwünschten Bereichen.
   
• Ressourcenverbrauch: Die Hintergrundrecherche des Alters und der Codebasisänderungen bietet eine solide Grundlage für die Berechnung der Ressourcen für ein Projekt, z. B. die Hinzufügung von Funktionalität oder Wert, Kostensenkung, Leistungsverbesserungen usw. 

Schritte zur erfolgreichen Handhabung der Legacy-Codebasis-Vererbung

Die bestehenden Codebasen sind mit viel Inkohärenz und Unsicherheiten verbunden. Da solche Projekte mit engen Fristen verbunden sind, bleibt nur wenig Zeit, um das Projekt vollständig zu erfassen. Deshalb wird empfohlen, einen bewährten Ansatz zu verfolgen. Die folgenden Punkte beschreiben das schrittweise Vorgehen zur Handhabung einer Legacy-Codebasis: 

Vorbereitung / Hintergrundwissen

Bevor Sie mit Legacy-Code beginnen, wird immer empfohlen, sich einen Überblick über den Code zu verschaffen. Notieren Sie sich und verstehen Sie den Workflow, die Namenskonventionen, die Aufrufhierarchien, die Muster, die Codestruktur, das Backend usw. Dies gibt Ihnen eine grundlegende Vorstellung davon, was der Code tut. 

Lesen Sie außerdem die grundlegende Projektdokumentation und die README-Dateien, um sich ein Bild von den Anwendungsfunktionen und den erforderlichen Tests zu machen. 

Erstellen Sie Flussdiagramme, Diagramme, Skizzen usw., die Ihnen helfen, die einzigartigen Bereiche und Funktionen des Projekts zu identifizieren, die den Kontext klarer machen und letztendlich zu einer nahtlosen Projektabwicklungserfahrung führen. 

Im Folgenden sind die Vorteile dieses Schritts aufgeführt: 

• Ein klares Verständnis der Projekteinstiegspunkte und des Datenflusses.
• Vollständige Systemübersicht, die die internen und externen Abhängigkeiten und die Teams umfasst, die diese handhaben.
• Klare Kenntnisse der Datenbankstruktur.
• Verständnis des Bereitstellungsprozesses und des Automatisierungsgrades im Projekt. 

Treffen mit den alten Teams

Um eine Realitätsprüfung dessen durchzuführen, was bisher verstanden wurde, ist es unerlässlich, sich mit den zuvor beteiligten Codierungsexperten zu treffen und Zeit mit ihnen zu verbringen. Decken Sie die bekannten und unbekannten Dinge mit der Liste von Fragen und der Dokumentation auf, die durch das anfängliche Verständnis erstellt wurden. Folgende Dinge können in dem Treffen behandelt werden:

• Projektbereichsübersicht
• Konfiguration der Entwicklungsumgebung
• Endbenutzerseite der Anwendung
• Wie man das Projekt testet und bereitstellt
• Aktualisierungen der README

Im Folgenden sind die Ergebnisse des Treffens von alten und neuen Teams aufgeführt:  

• Ein klareres Verständnis der Funktionsweise des Projekts.
• Detailliertere Dokumentation des Projekts.
• Verständnis der heiklen und kniffligen Teile des Systems.
• Liste und Details der technischen Schulden, wie z. B. die Probleme, ihr Auftreten und der Ansatz zu ihrer Lösung.
• Die Entscheidungshistorie, die angibt, wie und warum eine bestimmte Entwicklungsentscheidung getroffen wurde. Dies verschafft den neuen Teams einen Vorteil, um die kommenden Herausforderungen fundierter zu bewältigen.
• Die Liste der Anwendungsbeschränkungen, um zu überprüfen, was zu befolgen ist und was nicht.

Projekt-Kickoff

Nachdem genügend Informationen über das Projekt gesammelt wurden, wird empfohlen, die Teams durch eine kleine Veranstaltung oder ein Treffen an Bord zu holen. Die Teilnehmer hier sind die Produktverantwortlichen, Entwickler aus dem neuen Team und andere wichtige Rollen, die für die Entwicklung einer Anwendung verantwortlich sind. 

Solche Zusammenkünfte bieten:

• Demonstration der Funktionen des aktuellen Projekts.
• Code-Walkthrough mit den bestehenden Abhängigkeiten im System. 
• Vision und Ziele der neuen Anwendung.
• Produkt- und technologiebezogene Bedenken.
• Details zur Teamzusammensetzung und zu den Verantwortlichkeiten.
• Key Performance Indicators (KPIs) zur Messung des Erfolgs des Projekts.
• Listen der kommenden Backlogs.

Parallele Entwicklung

Nach der erfolgreichen anfänglichen Onboarding-Sitzung können dem Projekt Funktionen hinzugefügt werden. Bevor Sie mit dem Hinzufügen neuer Funktionen fortfahren, wird empfohlen, zu wissen, wie ähnliche Funktionen implementiert wurden und wie sie tatsächlich funktionieren. 

Sowohl die alten als auch die neuen Teams arbeiten parallel an der Implementierung der neuen oder ähnlichen Funktionen im Projekt. Es wird empfohlen, die Entwicklungspraktiken und -prozesse des bestehenden Teams beizubehalten, um unnötige Reibungsverluste zwischen den alten und den neuen Teams zu begrenzen. Dies führt zu einem reibungslosen und stabilen Übergang des Projektentwicklungsprozesses. 

Wenn es um das Testen geht, sollte eine Hintergrundprüfung des Test-Setups durchgeführt werden, um sich ein Bild vom Testprozess einer ähnlichen Funktion zu machen. Weiterhin gefolgt von der Projektfreigabe und -bereitstellung. Diese Phase stellt sicher, dass das neue Team mindestens eine Produktionsbereitstellung durchführt und auch die kommenden Probleme löst. 

Später wird ein zweites Treffen mit dem alten Team durchgeführt, um den Projektfortschritt, die Fragen zum Projekt und die technischen Schulden zu überprüfen und zu prüfen, ob alle aus dem neuen Team auf dem gleichen Stand des Entwicklungsprozesses sind. 

Endgültige Übergabe

Sobald das neue Team den größten Teil der Codebasis verstanden hat und dem Antrag kontinuierlich Funktionen hinzufügt. Nun kann die geerbte Codebasis in Übereinstimmung mit der bestehenden Umgebung aktualisiert werden. 

Probleme mit den Funktionen werden von dem neu zugewiesenen Team behoben, das die vollständige Kontrolle über das Projekt übernimmt. Somit wird das Team nun die vollständige Wartung des Systems durchführen und Folgendes überprüfen:

• Gibt es Probleme mit dem bestehenden Code?
• Ist es an der Zeit für das Abhängigkeitsupdate?
• Funktionieren die Muster nach der Aufrüstung des Projekts noch?

Es wird empfohlen, den geerbten Code wie den "eigenen" Originalcode zu behandeln. Nehmen Sie bei Bedarf Änderungen vor und löschen Sie die unerwünschten Teile. Alles in allem hält diese Phase den Zustand des gesamten Systems fest und stellt sicher, dass es in Topform ist. 

Fazit

Die Vererbung von Legacy-Codebasen fällt unter die alten Methoden des Entwicklungsprozesses. Da sie jedoch viele funktionale Anforderungen erfüllt, wird sie immer noch широко verwendet. Der Umgang mit Legacy-Code ist eine Herausforderung. Es muss ein gut geplanter Ansatz und eine gut geplante Technik verfolgt werden, um den Prozess der Vererbung und Übergabe zu erleichtern. 

Was halten Sie von der Legacy-Code-Vererbung? Teilen Sie Ihre Meinung auf unseren Social-Media-Kanälen: Facebook, LinkedIn und Twitter. 

Senden Sie uns eine E-Mail an [email protected], wenn Sie noch andere Dinge über die Wartung von Legacy-Code gelernt haben.