Refactoring – Ich sperr’ mich mal kurz ein

Ich bin vor ein paar Tagen über The Practical Dev auf den Artikel “How about a refactorthon?” gestoßen. In diesem schlägt der Autor vor, eine Gruppe von Entwicklern – ähnlich einem Hackathon – auf ein Stück produktiven Code loszulassen, um zu sehen, mit welchen Ideen des Refactorings (lies: Verbessern des Codes) die einzelnen Entwickler oder Entwicklergruppen aufwarten.

Dieser Ansatz könnte tatsächlich vielversprechend sein, jedoch bezweifle ich, dass wir in unserer Gegend genug Entwickler fänden, die sich dazu bereit erklärten – von den rechtlichen Dingen ‘mal ganz abgesehen. Allerdings hat mich dieser Artikel an zwei Aktivitäten erinnert, über die ich gerne berichten möchte.

In einem aktuellen Projekt entwickeln wir gerade Teile der Codebasis komplett neu: mit einer sauberen, geilen Architektur, fancy Konstrukten und State-of-the-Art Techniken der verwendeten Programmiersprache. Trotzdem hatten sich verschiedene Dinge eingeschlichen, die im Review der einzelnen Komponenten stark negativ auffielen. Das ist jedoch kein Problem, denn genau dafür gibt es ja Reviews. Uns war klar, dass wir an dieser Stelle ein großflächiges Refactoring ansetzen mussten, um die Qualität der neuen Strukturen weiterhin aufrecht halten zu können. Ebenfalls war uns klar, dass das nicht nebenher zum Tagesgeschäft laufen kann. Also sperrten wir uns zu dritt für eine Woche (abzüglich einiger Termine, die wahrgenommen werden mussten) in ein Besprechungszimmer ein, erweiterten die Liste aller Unsauberheiten in Upsource (großartiges Werkzeug für Reviews) und wühlten uns durch den Code. Das Ergebnis nach einer Woche: fast alle Beanstandungen waren beseitigt und das gesamte Team konnte weiter an neuen Features entwickeln. Gut, hätten wir Resharper (Ihr entwickelt für .NET? kennt ihr) nicht gehabt, hätte es vermutlich dreimal solange gedauert.

In einem anderen Projekt vor ein paar Jahren – wir hatten es hier mit sehr, sehr viel Legacy-Code zu tun – entschlossen wir uns, auf Grund von immer neu auftretenden Problemen, den gesamten Sourcecode gezielt nach Fehlern zu durchsuchen und diese zu beseitigen. Als Maß für Fehler wurde FindBugs gewählt, mit den maximal möglichen Einstellungen. Wenn ich mich richtig erinnere, kamen damals ca. 300-400 Fehler bzw. Findings zum Vorschein – eine beträchtliche Anzahl. Ca. 50 davon gehörten der Kategorie Scariest an, also der übelsten Kategorie. Auch hier war sich alle sofort einig, dass sich das nicht soeben mal nebenher erledigen lässt. In Absprache mit unserem Chef planten wir alle zwei Wochen einen reinen Bugfix-Tag für das gesamte Team ein – ohne Telefone, ohne Handys, ohne Mails. Wir wechselten dafür sogar das Gebäude, um keinesfalls gestört zu werden. Es gab ganze vier (in Zahlen: 4, in Worten auch) Tage dieser Art, dann hörten wir auf. Nicht jedoch, weil es uns untersagt wurde oder weil wir keinen Erfolg sahen: wir waren fertig. Lediglich vier Tage intensiver und ungestörter Zusammenarbeit waren nötig, um Findbugs zum Schweigen zu bringen. Das nahmen wir übrigens gleich zum Anlass, eine Null-Fehler-Strategie für unsere Builds einzuführen. Sollte ein Entwickler versehentlich einen Fehler oder eine Unsauberheit einbauen, würden alle betroffenen Builds sofort fehlschlagen. Matthias Koch hat hierzu einen guten Artikel mit dem Fokus auf Resharper geschrieben.

Ich persönlich bin davon überzeugt, dass Refactoring nur dann wirklich funktionieren kann, wenn man es gezielt und (größtenteils) ungestört durchziehen kann. Ebenso erachte ich es als sehr sinnvoll, wenn nicht sogar als erforderlich, dass sich das Team an einen Ort zurückzieht, wo es nicht belangt werden kann. Und auch nicht sollte.

Leave a Reply

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