Der grüne Pfad

soccer free zone by extranoise
gefunden über Photo Suggest

Schön, wenn einem die Arbeit abgenommen wird: Kollege Stefan Roock schreibt in seinem neuesten Blogeintrag vom grünen Pfad, den ich beim Refactoring gerne gehe. Auf einem grünen Pfad gibt es minimales Risiko, sich im Code zu verlaufen. Aber der grüne Pfad ist nicht ganz einfach zu finden, auch wenn seine Regeln sehr einfach sind:

1. Einen atomares, d.h. nicht weiter unterteilbares, Refactoring durchführen.
2. Tests grün laufen lassen.
3. Weiter mit 1.

Laufen die Tests bei 2. nicht grün, sondern rot, hat man den grünen Pfad verlassen und findet sich unweigerlich in der roten Testhölle wieder, aus der es nur durch Strg-Z oder CMD-Z einen sicheren Ausweg gibt.

Was sind atomare Refactorings? Solche, die nicht weiter durch andere Refactorings unterteilbar sind, etwa Umbenennen, Extrahieren, oder Inlinen. Die meisten anderen Refactorings sind aus atomaren Refactorings zusammen gesetzte Refactorings.

Stefan beschreibt sehr schön, dass es gar nicht darauf ankommt, immer auf dem grünen Pfad zu weilen. Eigentlich braucht man den grünen Pfad nur dann, wenn es knifflig wird. Aber wer nicht oft auf dem grünen Pfad gelaufen ist, der wird ihn nur sehr schwer finden, und wer nicht oft kleine Schritte beim Refactoring gegangen ist, der wird sich unter Druck oder in sehr krudem Big-Ball-of-Mud-Code nicht mehr daran erinnern können, also genau dann, wenn es einem besonders helfen würde.

Stefan hat ein schönes Beispiel aufgeschrieben, bei dem ich ihn quasi auf dem grünen Pfad vor mich hergeschoben habe - und er zu einer, wie ich finde, sehr cleveren Lösung gekommen ist.

Gerne gebe ich den Aufruf von Stefan weiter: Habt ihr Code, der nicht auf dem grünen Pfad zu refaktorisieren sei? Immer her damit: bernd.schiffer@gmail.com oder hier in die Kommentare. Wir freuen uns über jede Herausforderung :-)