Home Strukturiertes Refactoring

Strukturiertes Refactoring

der Wandel von Legacy Code zu Clean Code

Strukturiertes Refactoring
Teilen

Die Entscheidung zum Refactoring des Quellcodes einer Software wird oft in die untere Schublade gelegt –  denn warum sollte man Zeit und Ressourcen investieren, um Teile oder Bereiche des Backend einer Software zu verbessern, die für den Endnutzer ohnehin unsichtbar sind? Man möchte sich eher auf wesentliche Funktionserweiterungen oder auf Maßarbeit für wichtige Kunden konzentrieren, die letztendlich auch einen wirtschaftlichen Beitrag zur Liquiditätsplanung eines Unternehmens leisten könnten. Das würde jeder zweite erfolgreiche Unternehmer in der IT-Branche behaupten und er hätte recht damit!

Die Praxis beweist jedoch, dass nicht nur der unternehmerische Erfolg oder die visuelle Darstellung eines Produkts die Entscheidung für oder gegen das Refactoring bestimmen. Die Hauptargumente für eine grundlegende Entscheidung zur weiteren Aufarbeitung einer Software kommen von dem Produktmanager und/oder dem Entwicklungsleiter und betreffen solche Themen wie Qualität und Effizienz. Als Organisation ist man sich dessen bewusst, dass man während der ursprünglichen Entwicklung eines Software-Produkts bestimmte Kompromisse eingegangen ist, um beispielsweise zum damaligen Zeitpunkt wichtige Deadlines einzuhalten, oder Kundenanforderungen umzusetzen. Früher oder später muss man seinen Verpflichtungen nachkommen und die ausstehenden „technischen Schulden“ vergüten.

Was ist Refactoring?

Refactoring –  ist die Umstrukturierung von Software unter Beibehaltung des ursprünglichen Funktionsumfangs mit dem Ziel, die Leistung der Software zu steigern und die Weiterentwicklung zu erleichtern.“

Pragmatisch betrachtet, ist Refactoring die produktive Zeit Ihrer Entwicklungsmannschaft, die Sie in die Verbesserung der Qualität einer (Legacy-) Software anstatt ihrer Funktionserweiterung investieren müssen. Die Theorie unterscheidet sich von der Praxis, aus diesem Grund werden wir uns weiterhin von der Theorie distanzieren und unsere Analyse ausschließlich auf Praxisbeispiele aus unserer eigenen Projekterfahrung stützen.


Möchten Sie vorher wissen, welche Merkmale eine Legacy-Software eigentlich haben muss, um als solche anerkannt zu werden? Dann empfehlen wir Ihnen als erstes den Artikel „Überholte (Legacy) Software im Digitalisierungs-Zeitalter“ unter diesem Link zu lesen. Eine Verlinkung zurück finden Sie zum Ende des Artikels.


Jedem Product Owner sollte bekannt sein, welche Risiken zu erwarten sind, wenn Refactoring zu lange Zeit vernachlässigt wird. Es obliegt der Verantwortung der technischen Leitung einer Entwicklungsabteilung, die Refactoring-Pläne dem Management vorzulegen und die daraus entstehenden Aufgaben gemeinsam mit dem Entwicklungsteam zu spezifizieren und entsprechend zu priorisieren. Eine wichtige Rolle dabei spielen QA (Qualitätssicherung) und Testing, da sie als untrennbarer Bestandteil der Entwicklung in einem Softwareprojekt die Hauptquelle für die verbesserungsbedürftigen kritischen Funktionen einer Software darstellen.

Wie beginnt man nun mit einem Refactoring-Projekt, um den benötigten Aufwand realistisch einzuschätzen und die Umsetzung fristgerecht einzuplanen? Diese Frage stellten unsere Kunden jedes Mal, wenn es leider bereits zu spät war. Nachfolgend zählen wir 5 Fallen auf, die in mehr als 90% der Fälle zu versagten Software-Refactoring-Projekten führen können.

1. Unstrukturierte Zielsetzung und Planung

Auch wenn von Refactoring in der Regel keine neuen Funktionalitäten erwartet werden, bedeutet das nicht, dass die Endresultate nicht messbar sind. Refactoring ist effektiv und führt immer zu merkbaren Ergebnissen, wenn ein klares Verständnis über das Endziel vorliegt. Hier ein paar Beispiele von Fragen für Ihre Entwicklungsabteilung, die Ihnen dabei helfen können, Ihr Endziel zu bestimmen:

  • Welches Problem möchten wir in erster Instanz durch Refactoring lösen?
  • Welche Vorteile wollen wir erzielen und für wen?
  • Welche Risiken gehen wir dabei ein und wie können diese minimiert werden?

Die Antworten auf diese Schlüsselfragen bestimmen Ihren Anforderungskatalog im weiteren Verlauf. Das Entwicklungsteam sollte sich mit der QA-Abteilung und dem Management zusammensetzen, um die Zielsetzungen und die Projekt-Timeline zu definieren. Diese sind häufig branchenunabhängig und universell anwendbar für beliebige Softwareprodukte auf dem Markt, dabei unterscheiden sich lediglich der gewählte Tech-Stack oder die Schnittstellen zu bereits vorhandenen Systemen.


Eine Liste möglicher Zielsetzungen für Ihr Refactoring-Projekt stellen wir Ihnen zum Ende dieses Artikels unverbindlich und kostenlos als PowerPoint-Präsentation zur Verfügung!


2. Fehlendes QA/Testing

Refactoring ohne vernünftige QA-/Test-Prozesse wird mit Sicherheit einen Quellcode erstellen, der im Vergleich zum alten zahlreiche neue Fehler aufweisen und daher nicht wie erwartet (oder gar nicht) funktionieren wird. In seiner Ursprungsdefinition ist Refactoring ein Prozess, der Verbesserungen durch nicht-funktionale Änderungen bringen soll. Werden dabei Fehler hinzugefügt, sind die vorgenommenen Änderungen doch funktional (auch wenn sie nicht beabsichtigt wurden), da sie die Funktionalität der Software beeinträchtigen.

Wenn der Quellcode nur wenig oder überhaupt kein Unit Testing enthält, sollte dies der erste Schritt in Vorbereitung auf die bevorstehende Arbeit sein. Unit Tests dienen dazu, eine angemessene Test-Abdeckung zu gewährleisten, bevor man mit dem Umschreiben der Software angefangen hat. Selbstverständlich verlangsamt sich dadurch der Prozess, da Tests nicht nur geschrieben, sondern später auch zusammen mit dem überarbeiteten Code angepasst werden müssen. Für Entwickler ist es eine strapazierende Aufgabe, die sich aber mittel- und langfristig insbesondere durch die Verkürzung der Go-Live-Zeit, Fehlerminimierung und positives Kundenfeedback rentieren wird.

Manchmal kann der Quellcode so schlecht aufgebaut oder undurchsichtig sein, dass der Aufwand für Testing den Aufwand für dessen Neuentwicklung übertreffen kann. In solchen Fällen baut man sich am besten ein Gitternetz aus automatisierten funktionalen Tests, um den Quellcode vor und nach etwaigen Änderungen beurteilen zu können.

3. Ein stets wachsender Product-Backlog

Um zügig voranzukommen, ist man manchmal verleitet, einen großen Block von Quellcode in einem einzigen Sprint umzuschreiben. Der Ausgang ist in der Regel immer gleich: die ersten 2-3 Sprints ist man hochmotiviert, Lieferungen erfolgen rechtzeitig oder mit nur kleinen Verspätungen. Da Refactoring ein andauernder Prozess ist, kann jederzeit Bedarf an Änderungen oder Fehlerbehebung bestehen. Plötzlich arbeitet man auf zwei Baustellen gleichzeitig, es treten Verzögerungen auf und man kommt weder mit dem neuen Quellcode in der Produktionsumgebung noch mit dem Alten zurecht.

Eine vernünftige Lösung in solchen Fällen ist es, den Quellcode während des Refactoring in kleine abgrenzbare Blöcke aufzuteilen, damit Ihr Entwicklungsteam die vorgenommenen Korrekturen und Anpassungen rechtzeitig umsetzen kann. Auch wenn der Gesamtaufwand dadurch größer werden kann, setzen Sie hiermit nur einen kleinen Teil Ihrer Software möglichen Risiken aus, bekommen hingegen einen stabilen Fortschritt und ein durchschnittlich ausgelastetes Entwicklungsteam. Blöcke sind leichter einzuschätzen, können kurzfristig eingeplant und bei Bedarf je nach Priorität umgetauscht werden. In Kombination mit einem agilen Entwicklungsmodell bekommt Ihr Projekt schnell Struktur und einen prognostizierbaren Ausgang.

4. Mangelhafte Quellcode-Dokumentation

Legacy-Software hat einen einzigen großen Nachteil – Legacy-Quellcode, der leider nur von Legacy-Entwicklern verstanden und bearbeitet werden kann. Ist der Legacy-Entwickler in den wohlverdienten Ruhestand eingetreten, oder zu einem anderen Unternehmen gewechselt, dann steht für Ihr Entwicklungsteam als Nächstes „das Erlernen einer Fremdsprache“.

Einige Refactoring-Aufgaben verlangen nicht unbedingt eine gründliche Kenntnis des Quellcodes (z.B. beim Refactoring für bessere Testbarkeit), während andere Aktivitäten (z.B. Refactoring für bessere Leistung) möglicherweise ein hohes Maß an Vertrautheit mit der Business-Logik und den Prozessen hinter den Kulissen einer Anwendung erfordern.

Wird das Refactoring der kritischen Komponenten oder sogar im Kern einer komplexen Geschäftslogik benötigt, dann sollten dafür nur erfahrene Entwickler die Verantwortung übernehmen. Werden Aufgaben an Praktikanten oder Junior-Entwickler delegiert, die zuvor nur wenig oder gar keine Erfahrung mit Legacy-Quellcode gesammelt haben, findet ein „learning on the job“ statt, was oft zu Fehlern führen kann, die das Projekt zum Scheitern bringen können.

5. Unregelmäßige Erfolgsmeldungen

Das Ende des Refactoring-Projekts ist in Sicht! Nach vielen mühevollen Entwicklungssprints bekommen die letzten Tickets in Jira den Status „Done“. Das Entwicklungsteam und die QA-/Testing-Mannschaft sind sich alle einig – gemeinsam hat man bemerkenswerte Ergebnisse geliefert. Der Quellcode

  • ist gut lesbar
  • hat eine ausgezeichnete Test-Abdeckung
  • hat deutlich an Komplexität abgenommen
  • entspricht den gängigen Standards der Branche
  • lässt sich sehr gut in moderne Versionskontrollsysteme samt Dokumentation und Tests ablegen.

Wie bringt man diese Erfolgsmeldungen der Geschäftsführung verständlich zur Kenntnis? Schließlich sollten diejenigen, die in dieses Refactoring-Projekt investiert haben, die Ergebnisse in einer zugänglichen Form durch starke Argumente präsentiert bekommen. Darunter zählen:

  • Hunderte von zukünftig eingesparten Support-Stunden für Kunden und Mitarbeiter
  • Niedrige Fehlerrate dank einer erfolgreich umgesetzten „Clean Code“-Strategie
  • Reibungslose Skalierung und flexible Anpassung der Software an die Marktgegebenheiten
  • Einfaches Rollout in beliebige Kundenumgebungen
  • Kurzfristige Umsetzung von spezifischen Anforderungen seitens potenzieller und bestehender Kunden

Der Fortschritt sollte iterativ und auf einem geschäftlich begreifbaren Weg kommuniziert werden, damit Entscheidungsträger im Unternehmen die Bemühungen der Projektteilnehmer objektiv bewerten können und dadurch die Qualität der vollbrachten Leistungen ersichtlich wird.

Auf diese Art und Weise sichert man sich zukünftig eine bedenkenlose Budgetfreigabe, wenn die Zeit für das nächste Quellcode-Refactoring wieder fällig wird, das können wir Ihnen garantieren!

Begriffe


Leave a Reply

Your email address will not be published. Required fields are marked *

Welche Zielsetzungen sind für ein Refactoring-Projekt relevant?

Die Antwort auf diese Frage stellen wir Ihnen nun unverbindlich und kostenlos als PowerPoint-Präsentation weiterhin zur Verfügung!

Siehe die Entwicklung von Technosoft

1977 Heute
1998
Projektmanagementsoftware
1983
Markenregistrierung Technosoft
1984
Start der Entwicklung CAD Software
2000
Übernahme der Tätigkeiten von Brunel und Niederlassung in Deventer
2007
Technosoft Deutschland
2009
Technosoft Moldawien
2015
Technosoft Rumänien
1993
Von DOS zur Windows-Plattform
2001
Start Verkauf AxisVM Software
2014
Einführung 3Muri Erdbebensoftware + erste KOMO Zertifizierung
2013
Start Business Unit Qualitätssicherung & Testing
2011
Übergang zu Eurocodes
2012
Start von Nearshoring unter dem Markennamen In-shore
2006
Technosoft von Brunel verkauft durch ein Management Buy Out
2016
Integration der Business Units in eine einzige Geschäftseinheit
2017
Zusammenfügung aller Aktivitäten unter dem Namen Technosoft
2018
Technosoft ist aktiv in 6 europäischen Länder