Was ist eigentlich Refactoring? Refactoring beschreibt grob gesagt die Anpassung und Vereinfachung von Software um diese leichter verständlich und leichter wartbar zu machen.
An verschiedenen Stellen erlebt man, dass Software größeren Refactorings unterzogen wird, um diese wartbarer zu machen. Dies ist oft eine gute Entscheidung. Die Frage, die man sich dabei stellen sollte ist immer: ist es notwendig zum aktuellen Zeitpunkt dieses Refactoring durchzuführen?
Ich möchte hierbei auf den Begriff fachlich getriebenes Refactoring etwas näher eingehen. Fachlich getriebenes Refactoring beschreibt den Umstand Software zu refactoren, wenn neue Features von der Fachabteilung angefordert werden. Es soll nur eine Refactoring durchgeführt werden, wenn wirklich auch ein neues Feature an der Stelle entwickelt wird. – Im Idealfall wird hierbei auch die Produktroadmap mit betrachtet, um auch strategische Features bereits in die Überlegungen mit einfließen zu lassen. Wichtig hierbei soll vor allem sein Refactoring aus der fachlichen Brille zu Betrachten um mit kleinem Aufwand den größten Value zu erreichen und keine Verbesserungen zu machen, die fachlich nicht notwendig sind. Die Schwierigkeit bei rein technischem Refactoring liegt vor allem darin, dass Softwarestrukturen angepasst werden können um zwar die Entwicklung an der Stelle zu vereinfachen. Es ist jedoch nicht immer klar, ob diese Flexiblität wirklich gebraucht wird, wenn die Strategie im Produkt nicht beachtet wird.
Ist die genaue Roadmap des Produktes nicht bekannt, hilft der Austausch mit dem Fachabteilung. Ein regelmäßiger Abgleich der strategischen Anforderungen als auch eine Vision des Produktes bringt die Möglichkeit schon frühzeitig auf neue Anforderungen zu reagieren und Refactorings an neue Anforderungen auszurichten. Ziel sei es durch das Refactoring ein Rahmenwerk entstehen zu lassen, das sich an fachlichen Gegebenheiten orientiert.
Gegenübergestellt kann man Vor- und Nachteile von fachlich getriebenem Refactoring gegenüber technischem Refactoring abgewinnen. Hier möchte ich die einzelnen Punkte aufführen und dazu motivieren, sich bei zukünftigen Refactorings eher an der Fachlichkeit zu orientieren, als ein technische Refactoring durchzuführen.
Vorteile von fachlich getriebenem Refactoring:
- keine Änderung ohne neue Anforderung
- weniger Anpassungen, wenn die Produktstrategie bekannt ist
- wenn der Code läuft fehlerfrei läuft, muss er nicht angepasst werden
Nachteile von fachlich getriebenem Refactoring:
- Wenn man für eine Stelle bewusst technische Schulden aufgenommen hat, werden diese erst abgebaut wenn ein neues fachliches Feature an der Stelle ansteht
- unter Zeitdruck werden Refactorings potentiell verschoben
