Wann ist die Zeit für Refactoring gekommen?

Jetzt. Wenn Du schon fragst, vermutlich gestern. Insbesondere Agile Projekte sind darauf angewiesen, dass man ständig refactored. Es entsteht sonst innerhalb von kürzester Zeit komplett unwartbarer Code. Doch wie sieht das aus?

Entwickler

Sagen wir, wir haben gerade festgestellt, dass wir es cooler finden, keine Pointer mehr zurückzugeben von unseren DB Funktionen wie in diesem Artikel beschrieben. Jetzt könnte ich als Entwickler einfach sagen “Ha, so mache ich das ab jetzt” und alle zukünftigen Funktionen so bauen. Das Ergebnis: zumindest schon mal zwei unterschiedliche Arten DB Funktionen zu schreiben in einer Codebase. Das ist Unschön. Was semantisch gleich ist, sollte strukturell gleich sein.

Also macht man ein kurzes Meeting, beschließt, “Ok, das wollen wir” und dann wird jede DB Funktion angepasst, so dass hinterher wieder alles aus einem Guss ist. Der Aufwand hält sich in Grenzen und man merkt auch sofort, ob die neue Implementation denn auch für alle im Code vorkommenden Fälle funktioniert.

Oder anders: Wenn ich auf Code gucken kann und mit einem Blick sagen kann, “Das war Entwickler XY”, läuft was schief oder es gibt nur einen Entwickler.

Business

Ihr habt mal eben für eine Messe dieses total wichtige Häkchen in die Anwendung eingebaut, die irgendwer in der Pressemitteilung schon mal versprochen hat, bevor jemand mit der IT geredet hat? Und da ihr im Wesentlichen hilfsbereit seid und ja auch idealerweise ein gewisses Interesse an dem Erfolg der Firma habt, habt ihr das mal eben gemacht? Und jetzt sagt Euch der PO, “Wozu sollte ich Euch Zeit geben, das ordentlich zu implementieren, es funktioniert ja”? Und ihr könnt nicht mehr schlafen, weil ihr jeden Tag damit rechnet, dass doch mal einer einen Firmennamen hat, der unglücklicherweise genau dieses Flag triggert, den ihr erstmal einfach als unsichtbares Zeichen im Firmennamen gespeichert habt?

Was soll ich sagen, Euer PO hat unrecht. Meuterei kommt meistens nicht so hervorragend an, von daher ist die beste Option das Refactoring einfach auf die nächsten Ticket Schätzungen aufzuschlagen.

Fazit

Kommentare wie “TODO”, “HACK” oder mein Liebling “Ändere ich nie” sollten regelmäßig aufgearbeitet werden. Je mehr man die Welle vor sich herschiebt, desto größer wird sie. Technical Debt und so, nä…

In einem agilen Umfeld, ändert sich ständig das Ziel, wenn ich nicht die Architektur entsprechend anpasse, geht die Firma früher oder später unter. Der Erfolg eines Softwareprojekts hängt nicht unwesentlich damit zusammen, wie schnell sich der Code an neue Anforderungen anpasst. Je mehr Hacks im Code, desto schwerer sind Zielanpassungen.