Blogpost vom 02. Oktober 2019
Refactoring: Wie Sie technische Schulden vermeiden
Die Vorstellung, dass Software sich abnutzt, erscheint manchen zunächst als abwegig. Handelt es sich doch um ein nicht-materielles Konstrukt – wo sollen da bitte Gebrauchsspuren oder gar Verschleiß auftreten? Und auch Bugs lassen sich schließlich ohne Folgeschäden oder Materialermüdung entfernen … oder nicht? Ein Blick auf technische Schulden und wie sie sich mit Refactoring vermeiden lassen.
Refactoring in der Softwareentwicklung
Denn ganz so einfach ist es nicht. Software ist nämlich längst nicht so unverwüstlich, wie es scheint. Vielmehr befindet sie sich in einem ständigen Fluss. Nicht nur durch die Behebung von Fehlern ist sie Änderungen unterworfen, auch und insbesondere durch neue Anforderungen und notwendige Anpassungen verändert sich ihr Zustand fortlaufend.
Auf die Bausubstanz kommt es an
Was wir deshalb brauchen, ist ein solides Fundament. Denn Softwareentwicklung lässt sich gut mit dem Bau eines Hauses vergleichen: Stellen wir uns vor, es wird ein Gebäude errichtet: Ein Bauunternehmen erfasst die Wünsche der Bauherren und setzt sie in ein Bauwerk um. Aber was ist zu tun, wenn plötzlich mehr Platz benötigt wird, weil die Bewohnerzahl gewachsen ist? Soll dann ein weiteres Stockwerk aufgesetzt oder doch ein Anbau gemacht werden? Und wenn man schonmal dabei ist: Wie wäre es mit einem Swimmingpool im Keller?
All das wirft Fragen nach der Statik des Gebäudes auf, und nach seiner Bausubstanz. Bei Software verhält sich das ganz ähnlich – auch wenn diese nicht aus Stein und Mörtel, sondern aus Programmcode gefertigt wird. Hält dieser Code Veränderungen nicht stand, ist die ganze Anwendung auf Sand gebaut. Hinzu kommt, dass Software, anders als ein Haus, fast ständig weiterentwickelt wird, sich also in einem kontinuierlichen Prozess des Um- und Weiterbaus befindet.
Was ist Refactoring?
Doch was geschieht dabei mit dem Code? Unterstellen wir mal, es liegt zu Beginn eine ideale und weitgehend fehlerfreie Version 1.0 der Anwendung vor. Werden auf dieser Basis neue Anforderungen umgesetzt, reicht es nicht, diese bedarfsgetreu umzusetzen. Wir sollten dabei auch das Fundament und das Ökosystem der Software im Blick zu behalten:
- Haben sich die Abhängigkeiten verändert? Sind auf einmal mehr Komponenten der Software miteinander verbunden? Denn das beeinflusst die zukünftige Erweiterbarkeit.
- Sind die Bestandskomponenten noch den neuen Anforderungen gewachsen? Oder müssen sie ihrerseits erweitert werden? Vernachlässigen wir das, können Performance- oder Speicherengpässe entstehen.
- Müssen auch die automatisierten Tests angepasst werden? Denn nur so können wir eine dauerhaft hohe Qualität sicherstellen.
- Ist die Dokumentation – sowohl im Quellcode als auch auf dem Papier – noch auf dem aktuellen Stand? Denn das brauchen wir für ein schnelles Verständnis des Codes.
Anhand dieser Fragen wird deutlich, dass neben der eigentlichen Anforderung noch weitere Tätigkeiten unbedingt notwendig sind, die wir als Refactoring bezeichnen.
Das sind die Ursachen technischer Schulden
Manchmal führt allerdings kein Weg daran vorbei, das Refactoring zu einem späteren Zeitpunkt durchzuführen – sei dies der Priorisierung der Aufgaben geschuldet oder einem engen Zeitplan. Der Grund ist aber immer Ressourcenknappheit – im Budget, im Scope oder beim Personal. Oft wird dann ein Rückstand beim Refactoring in Kauf genommen. Kurzfristig stellt dies kein Problem dar, solange man diesen wieder abbaut. Problematisch wird es dann, wenn technische Schulden angehäuft werden.
Es gibt auch verdeckte Faktoren für einen Rückstand beim Refactoring: Beispielsweise, wenn eine implementierte Lösung nur das zu diesem Zeitpunkt vorhandene Problemverständnis widerspiegelt. Denn oft vertieft sich dieses mit der Zeit und sollte dann auch in die Software einfließen.
Ein weiterer Faktor ist der technische Fortschritt selbst, der bei der Digitalisierung besonders dynamisch voranschreitet und die Modernisierungen von Software unabdingbar macht. Unterbleiben diese Tätigkeiten auf Dauer, führt dies zu technischen Schulden und damit zu einer Abnutzung der Software.
Das sind die Folgen technischer Schulden
Die Folgen sind direkt spürbar: Deutlich steigende Aufwände bei der Implementierung neuer Funktionen. Erforderte eine Erweiterung zu Beginn des Projektes vielleicht noch zwei Tage, können es ein paar Monate später schon Wochen sein. In extremen Fällen führt das dazu, dass Softwareprodukte eines Tages gar nicht mehr wartbar bzw. Anpassungen nur noch mit einem immensen Aufwand durchführbar sind. Das ist dann der Punkt, an dem Rufe nach einer vollständigen Neuentwicklung laut werden.Mit Refactoring frei von technischen Schulden.
Oftmals werden Refactorings nicht als wertschöpfende oder auch nur werterhaltende Tätigkeiten wahrgenommen. Entwickler müssen diese gegenüber dem Kunden stets begründen und ernten dabei nicht selten Unverständnis. Besser wäre es, das Refactoring als einen wichtigen Erfolgsfaktor wahrzunehmen und entsprechend einzuplanen.
So vermeiden Sie technische Schulden mit Refactoring
Unsere Empfehlung: Planen Sie in Ihren digitalen Projekten standardmäßig 20 % der Zeit für ein sachgerechtes Refactoring ein. So vermeiden Sie technische Schulden und tragen substanziell zum Werterhalt Ihrer Software bei. Was außerdem hilft:
- Code-Kenner: Halten Sie Entwickler im Projekt, die den Code schon lange kennen.
- Know-how-Transfer: Sorgen Sie für die Weitergabe von Kenntnissen unter den Projektkollegen.
- Pair Programming und Code Reviews: Vertrauen ist gut, Qualitätssicherung ist besser!
- Tools: Nutzen Sie unterstützende Werkzeuge, wie z. B. SonarQube.
- Dokumentation: Dokumentieren Sie gewissenhaft! Überlieferungslücken sind Wissenslücken!
- Passende Technologien: Folgen Sie nicht blind dem Trend, sondern prüfen Sie, welche Technologien sinnvoll zu den Anforderungen passen.
