Wartbarer Code: Chancen und Grenzen automatisierter Migrationen

Mit zeitgemäßen Plattformen in die Zukunft – dank automatisierter Migrationen wird das immer einfacher. Wie sieht es allerdings mit technischen Schulden aus?

Die Wartbarkeit des Legacy Codes wird immer schlechter und die Betriebskosten steigen? Probleme, die sich durch den Umstieg auf eine zeitgemäße Plattform lösen lassen.

Im Folgenden möchte ich Ihnen aufzeigen, was eine automatisierte Migration leisten kann.

Wartbarer Code und automatisierte Softwaremigration

Im Prinzip lässt sich „wartbarer Code“ als Programmierstil beschreiben – entscheidet dieser letztendlich doch über die gute oder schlechte Wartbarkeit der Anwendung. Das umfasst auch die Programmierparadigmen (objektorientiert, strukturiert etc.). Dabei wirken drei Aspekte zusammen:

  1. Die Vorschrift: Die Definition von Regeln oder Konventionen/Standards. Im Sinne von (Software-)„Qualität“ (= „dem Erfüllen von Anforderungen“) sind dies Anforderungen.
  2. Die Handlung: Das Umsetzen/Berücksichtigen dieser Regeln.
  3. Das Ergebnis: Der Quelltext mit seiner Struktur und seinem Erscheinungsbild ist im Rahmen der Qualitätssicherung auf Einhaltung der Vorschriften überprüfbar.

Übertragen auf eine automatisierte Softwaremigration heißt das:

  1. Die Vorschrift: Die Regeln werden intelligent und mit Hinblick auf die aktuellen Konventionen/Standards der Zielsprache definiert.
  2. Die Handlung: Die Migration erfolgt nach fest definierten Regeln für die einzelnen Programmbefehle. Hier ist der Roboter gegenüber dem Menschen klar im Vorteil: Er kennt lediglich die festgelegten Regeln und befolgt diese eisern. Die Berücksichtigung des vorgegebenen Stils ist somit sichergestellt.
  3. Das Ergebnis: Resultat ist eine Software entsprechend der definierten Regeln und damit per Definition wartbarer Code. Das Erscheinungsbild kann zusätzlich mit einem Code Beautifier angepasst werden.

Einmal Spaghetti Code, immer Spaghetti Code?

Eine automatisierte Softwaremigration führt zu wartbarem Code – und das zuverlässiger als bei einer manuellen Vorgehensweise. Allerdings gilt: Ausnahmen bestätigen die Regel. Die Herausforderung beginnt immer dann, wenn verschiedene Paradigmen von Sprachen aufeinandertreffen. Ein gutes Beispiel ist die Anweisung GOTO, die einen Sprung an eine andere Stelle des Programms bewirkt. In „alten“ Sprachen wie COBOL ein gängiges Mittel zur Steuerung des Ablaufes, stuft die objektorientierte Programmierung den Befehl als „böse“ ein und nutzt stattdessen Kontrollstruktur-Befehle. Grund dafür ist die sinkende Wartbarkeit des Programmcodes. Es ist zwar möglich, die alten Konstrukte im Rahmen einer Migration umzusetzen, allerdings leidet darunter die Codequalität und damit auch die Wartbarkeit. Einmal Spaghetti Code, immer Spaghetti Code?

Legacy Code mit Schuldschein besser zuerst sanieren

Nein, nicht zwingend. Basierend auf unseren Erfahrungen im Bereich der Sprachmigration haben wir unsere Migration Factory um eine Komponente erweitert: die „Refaktorierung“. Damit sind wir in der Lage, unleserliche Codestrecken zu analysieren und zu verändern – das heißt, schlecht wartbaren in modernen Programmcode umzuwandeln. Allerdings gilt: Je mehr Spaghetti Code, desto größer der Sanierungsaufwand und desto höher die Kosten. Zumal so auch „tote Codestrecken“ migriert werden.

Eine automatisierte Softwaremigration ist kein Allheilmittel gegen schlechten Programmierstil. Ich empfehle, technische Schulden im Idealfall vor einer Migration zu begleichen. Das erfordert z.B. Code-Reviews, die Erfassung von Code-Metriken, eine sorgfältige Analyse der Dokumentation sowie daran anschließend eine Sanierung des Quellcodes. Danach steht einem erfolgreichen Plattformwechsel nichts mehr im Weg.

Bildquelle: Shutterstock

Schreibe einen Kommentar