Unsere Lösungen,
ob Start-Up oder etabliertes Unternehmen

Business Process Management

Java

Testautomatisierung

Agile Methoden

Mobile- und Weblösungen

Business-Intelligence

vivir

IT-Sicherheit

Künstliche Intelligenz

viadee Themen

In unserem Blog finden Sie Fachartikel, Success-Stories, News, Messeberichte und vieles mehr... vor allem aber hoffentlich wertvolle Informationen, die Ihnen in Ihrem konkreten Projekt und in Ihrem Business weiterhelfen. Bei Fragen und Anregungen nehmen Sie gerne Kontakt zu uns auf. Bitte benutzen Sie dazu die Kommentarfunktion unter den Blogbeiträgen.

Hilfe, wir sinken! – Über Refactoring in Wartungsprojekten

05.09.17 17:11

Quellcode altert. Ob neue Anforderungen die ehemals schlanke Anwendung immer weiter aufblähen, ob Bugfixes oder provisorische Umbauten für die neue REST-Schnittstelle das tun, Code von genutzten Anwendungen ist fast nie statisch. Aus Clean-Code-Sicht ist daher kontinuierliches Refactoring nötig, um Lesbarkeit und Wartbarkeit des Codes zu erhalten, doch wie geht man damit im Projektalltag um? Wäre der Quellcode ein Schiff, das man mit dem gesamten Team segelt, so wäre allen klar, dass ständig Reparaturmaßnahmen stattfinden müssen, damit es nicht sinkt.

refactoring
Mir sind in vielen Projekten im Laufe der Zeit einige Patterns und Antipatterns zum Umgang mit diesen Reparaturmaßnahmen aufgefallen.
  • Refactorings als U-Boote: die Entwickler führen nötiges Refactoring „unsichtbar“ für den Product Owner (oder Projektleiter) und nebenbei durch. Das reduziert die sichtbare Produktivität des Teams und bringt „unsichtbares“ Risiko ein, da es an Tests vorbei laufen kann.
  • Refactorings als Geldvernichter: Product Owner (oder Projektleiter) definieren Refactorings als unnütz, da nur neue Features einen Mehrwert darstellen. In dieser Sicht sind Refactorings lediglich Belastung des Budgets, weil sie Zeit kosten und keinen Mehrwert schaffen und werden daher nicht (sichtbar) durchgeführt.
  • Refactorings als zeitliche Lückenfüller: Im Projekt hat sich die Ansicht durchgesetzt, Refactorings könne man durchführen, „wenn Zeit übrig ist“. Wegen zunehmendem Zeitbedarf für Bugfixes und kritische Fehlerbehebungen durch sich verringernde Qualität bleibt aber niemals Zeit übrig.
  • Refactorings als Mahnmale technischer Schulden: Es gab einmal eine Erhebung von Refactoring-Bedarf. Leider ist man im Projekt nie dazu gekommen, ihn abzuarbeiten, aber dafür gibt es uralte Tickets oder Aufgaben.
  • Refactorings als PAL: Das Team definiert die technischen Schulden, für die Refactorings durchgeführt werden müssen als „Problem anderer Leute“. Wenn jemand anderes zuständig ist, belastet es das Projekt ja nicht.
Der Clean Code-Ansatz fordert eine andere Herangehensweise ein: die Beachtung der Pfadfinderregel: „Verlasse den Zeltplatz stets sauberer, als du ihn gefunden hast!“. Doch wer sich als Entwickler streng daran hält, verliert sich im Klein-Klein von Refactorings in großen Mengen Legacy-Codes und kommt sich schnell vor, als würde er mit einem Piekser auf einer Müllkippe stehen.

Ich empfehle einen transparenteren Umgang mit Refactorings, der darauf basiert, sie als notwendige Wartungsmaßnahmen für den Quellcode zu betrachten:
  • Entwickler sollten ein Kanban-Board für „technische Schuld“ einrichten und damit transparent machen, was aus ihrer Sicht an technischer Schuld im Quellcode vorhanden ist.
  • Die erfassten Refactoring-Bedarfe müssen mit dem Product Owner (oder Projektleiter) diskutiert und die Bearbeitung geplant werden. Nur dann ist sichergestellt, dass auch die „richtigen“ Refactorings durchgeführt werden und nur dann ist auch die Akzeptanz garantiert.
  • Stellt ein Entwickler im Code Refactoring-Bedarf fest, hält er diesen auf einem Ticket fest, was ins Backlog des Boards eingestellt wird. Der Umfang sollte ad-hoc vom Entwickler (idealerweise von 1-2 Entwicklern) geschätzt und im Ticket festgehalten werden
Als Faustregel hat sich für den Umfang eine Größe von maximal 1-3 PT bewährt (inklusive vorheriger Test-Absicherung, falls nicht vorhanden).
  • Gemeinsam mit Team, Product Owner (oder Projektleiter) werden zu jedem Sprint oder in regelmäßigen Intervallen Tickets zur Bearbeitung ausgewählt und eingeplant.
  • Entstehen während der Bearbeitung zusätzliche Aufgaben, können diese als neue Tickets auf dem Board erfasst werden.
Mit dieser Herangehensweise stellt man sicher, dass eine kontinuierliche Beachtung und Abarbeitung der nötigen Refactorings im Wartungsprojekt stattfinden kann.

So kann das Projekt-Schiff in ruhiger See weitersegeln.

Abschließend noch zwei Fragen, die mir die Kollegen im Zusammenhang mit dem Artikel und dem Umgang mit technischer Schuld gestellt haben.

Frage: „Wie geht man mit der Gefahr um, dass das vorgeschlagene Kanban-Board nicht genau dieses Mahnmal technischer Schuld wird?“

Antwort: Das ist in der kontinuierlichen Abarbeitung und Berücksichtigung des Boards explizit enthalten. Indem bei jedem Sprint (oder in regelmäßigen Intervallen) auf die technischen Schulden geschaut und – passend zur Projektsituation – einzelne Themen herausgegriffen und bearbeitet werden, passiert eine stetige Beachtung und erneute Diskussion der Refactoringbedarfe. Ich muss allerdings auch einschränken, dass die Abarbeitung von technischen Schulden eine Kulturfrage ist und nur durch die rein technische Erfassung noch lange keine Abarbeitung stattfindet.


Frage: „Was ist zu tun, wenn der Product Owner (PO) in der Diskussion die Refactorings als unnütz klassifiziert und sie nicht eingeplant werden?“

Antwort: Auch hier geht es um eine Mentalitäts- bzw. Kulturfrage und die ist in dieser Situation schwer zu lösen. Es besteht ein Interessenskonflikt zwischen PO und dem Team und aus meiner Sicht hilft in dieser Situation am besten das Sammeln von (beweisbaren) Argumenten für die Notwendigkeit der Reduktion der technischen Schuld. Das könnte beispielsweise durch die Erhebung von passenden Kennzahlen geschehen, etwa „Anzahl der Prio 1 Fehler“, „Anzahl der Fixes und Hotfixes“, „Verwendete Zeit für kritische Fehlerbehebungen“ oder ähnliches.

Diese Kennzahlen müssen regelmäßig erhoben und gemeinsam mit dem PO diskutiert werden. Dadurch erzeugt man Klarheit über die steigenden Aufwände für Beseitigung von technischen Schulden im Team und das kann zu einem Mentalitäts- oder Kulturwandel beitragen.

Jetzt Blog abonnieren!
zum Blog
Christoph Meyer

Christoph Meyer

Diplom-Wirtschaftsinformatiker Christoph Meyer ist Senior Berater und Softwarearchitekt bei der viadee IT-Unternehmensberatung und seit 2006 in Kundenprojekten im Bereich Handel, Banken und Versicherungen unterwegs. Er ist Clean Code Evangelist und Kanban-Fan und hat mit den Schwerpunkten Backend-Security, Batchverarbeitung vom Host bis Spring und DevOps immer neue Seiten seiner Java-Leidenschaft entdeckt. Bewältigung von Legacy-Software mit Herstellung von Testbarkeit und großen Refactorings findet er spannend. Christoph gibt sein Wissen gerne in Workshops an Kunden, Kollegen und Studenten weiter. Christoph Meyer auf Twitter