Refactoring für Sterbliche

Yahuda Katz, einer der Rails Großmeister (wenn es diesen Titel denn gibt), hat vor ein paar Tagen einen guten Blog-Artikel zum Thema Refactoring verfaßt: 6 Steps To Refactoring Rails (For Mere Mortals) beleuchtet ein paar grundsätzliche Vorgehensweisen zum Refactoring (und zwar nicht nur für Rails). Ich denke, nachdem es schon ganze Bücher zum Thema Refactoring gibt, ist das tatsächlich die Essenz des Refactoring, trotzdem halte ich zwei Punkte für besonders wichtig:

Erstmal bedeuted Refactoring, daß neuer Code die gleiche Funktion erfüllt (und keine neuen Features einführt), zweitens funktioniert Refactoring nur mit Tests. Vielen, vielen Tests, die alle funktionalen Bereiche des Codes abdecken.

Meine bescheidene Erfahrung sagt, daß vor dem und während des Refactoring ein ganzer Haufen neuer Tests entsteht. Grundsätzlich muß sowohl der alte als auch der neue Code die Tests bestehen; wenn der alte Code das nicht tut, gibt es nur zwei Szenarien: Der alte Code war fehlerhaft (was ja immer sein kann), oder die Tests stellen auf die neue Codestruktur ab (was möglicherweise etwas fragwürdig ist).

Zuletzt noch eine Anmerkung, die für Nicht-Rails- und Nicht-Ruby-Entwickler vielleicht etwas untergeht: Refactoring passiert nicht auf dem Master-Branch, sondern etwas abseits, da zwischendurch mit Sicherheit ein ganzer Haufen Fehler auftritt (ein SCM ist ohnehin Pflicht). Alle Nutzer von klassischen SCMs haben hier natürlich schlechte Karten, da ihr Code in Dateien organisiert ist, die vom SCM als separate Einheiten gesehen werden. Aber es gibt Hoffnung: Ein Refactoring ist ein guter Grund, sich mal git anzusehen. (Soviel zum Thema Propaganda.)