Wenn ich über das Refaktorisieren spreche, werde ich oft gefragt, wie es geplant werden sollte. Sollen wir alle paar Monate zwei Wochen zum Refaktorisieren ein- planen?
In fast allen Fọllen bin ich dagegen, zusọtzliche Zeit zum Refaktorisieren einzupla- nen. Refaktorisieren ist etwas, was man die ganze Zeit über in kleinen Portionen macht. Sie entscheiden nicht zu refaktorisieren, sondern Sie refaktorisieren, weil Sie etwas anderes machen wollen und das Refaktorisieren Ihnen dabei hilft.
2.3.1 Die Dreierregel
Dies ist eine Empfehlung, die ich von Don Roberts habe: Wenn Sie etwas das erste Mal machen, tun Sie es einfach. Das zweite Mal, wenn Sie etwas Ähnliches ma- chen, so scheuen Sie zwar die Wiederholung, aber Sie machen es trotzdem noch einmal. Wenn Sie etwas Ähnliches das dritte Mal tun, refaktorisieren Sie.
2.3.2 Refaktorisieren Sie beim Hinzufügen von Funktionen
Am họufigsten refaktorisiere ich, wenn ich etwas Neues zu einer Software hinzu- fügen will. Oft ist der erste Grund zum Refaktorisieren, dass ich eine Software ver- stehen will, die ich ọndern muss. Das kann Code von jemand anderem oder von mir selbst sein. Immer wenn ich darüber grübeln muss, was der Code macht, frage ich mich, ob ich den Code so refaktorisieren kann, dass er unmittelbar verstọnd- lich wird. Dann refaktorisiere ich. Zum Teil ist das etwas fỹr das nọchste Mal, wenn ich an diese Stelle komme, aber vor allem verstehe ich die Dinge besser, wenn ich den Code jetzt klarer strukturiere.
Drei Mal und Sie refaktorisieren.
Der andere Anlass zum Refaktorisieren ist ein Design, das es mir nicht erlaubt, et- was Neues leicht einzufỹgen. Ich betrachte das Design und sage mir: ằHọtte ich das so gemacht, kửnnte ich dies jetzt leicht einfỹgen.ô In diesem Fall ọrgere ich mich nicht lange über meine früheren Missetaten – ich korrigiere sie durch Refak- torisieren. Ich mache das zum Teil, um spọtere Verbesserungen einfacher zu ma- chen, vor allem aber, weil ich festgestellt habe, dass es so am schnellsten geht.
Hinterher geht das Hinzufügen der neuen Teile viel schneller und glatter vonstat- ten.
2.3.3 Refaktorisieren Sie, wenn Sie einen Fehler beheben müssen
Bei der Fehlerbehebung zeigt sich der Nutzen des Refaktorisierens darin, dass der Code verstọndlicher gemacht wird. Wọhrend ich versuche den Code zu verste- hen, refaktorisiere ich, um mein Verstọndnis zu verbessern. Ich empfinde dies họufig als eine aktive Auseinandersetzung mit dem Code, die den Fehler zu fin- den hilft. Eine Schlussfolgerung, die Sie hieraus ziehen kửnnen, ist folgende: Be- kommen Sie einen Fehlerbericht, so ist dies ein Zeichen, dass Sie refaktorisieren mỹssen, weil der Code nicht verstọndlich genug war, um zu erkennen, dass hier ein Fehler war.
2.3.4 Refaktorisieren Sie bei Code-Reviews
Einige Organisationen machen regelmọòig Code-Reviews; die, die es nicht tun, wọren besser beraten, wenn sie es auch tun wỹrden. Code-Reviews helfen dabei, das Wissen in einem Entwicklungsteam gleichmọòig zu verteilen. Reviews helfen erfahreneren Entwicklern, ihr Wissen an weniger erfahrene weiterzugeben. Sie helfen mehr Menschen, mehr Aspekte eines groòen Softwaresystems verstehen.
Sie sind auch sehr wichtig, um klaren Code zu schreiben. Mein Code mag mir klar erscheinen, nicht aber meinem Team. Das ist unausweichlich – es ist sehr schwie- rig sich in die Position eines anderen zu versetzen, der mit den Dingen, an denen man arbeitet, nicht vertraut ist. Reviews geben auch mehr Menschen die Gelegen- heit, nỹtzliche Vorschlọge zu ọuòern. Mir kommen nur so und so viele gute Ideen pro Woche. Beitrọge von anderen machen mein Leben einfacher, so dass ich im- mer viele Reviews anstrebe.
Ich habe festgestellt, dass das Refaktorisieren mir bei Reviews von fremdem Code hilft. Bevor ich begann hierfür Refaktorisieren einzusetzen, konnte ich den Code lesen, ihn zu einem gewissen Grad verstehen und Verbesserungsvorschlọge ma- chen. Wenn ich jetzt mit Vorschlọgen komme, ỹberlege ich, ob sie auch leicht umgesetzt werden kửnnen und ob das Refaktorisieren dafỹr geeignet ist. Wenn ja,
refaktorisiere ich. Habe ich dies einige Male getan, so sehe ich genauer, wie der Code mit den umgesetzten Verbesserungsvorschlọgen aussieht. Ich muss mir das nicht vorstellen, ich kann es sehen. Als Folge davon komme ich auf Ideen auf ei- nem anderen Niveau, die ich ohne Refaktorisieren nie gehabt họtte.
Das Refaktorisieren führt bei Code-Reviews auch zu konkreteren Ergebnissen. Sie fỹhren nicht nur zu Vorschlọgen, sondern viele Vorschlọge werden auch auf der Stelle umgesetzt. Sie bekommen dabei das Gefühl, richtig etwas erreicht zu haben.
Damit dies auch so funktioniert, müssen die Review-Teams klein sein. Ich emp- fehle aus meiner Erfahrung, einen Reviewer und den ursprünglichen Autor ge- meinsam an dem Code arbeiten zu lassen. Der Reviewer schlọgt die Änderungen vor, und beide gemeinsam entscheiden darüber, ob die Änderungen im Code leicht vorgenommen werden kửnnen. Wenn dies so ist, nehmen sie die Änderun- gen vor.
Bei grửòeren Design-Reviews ist es oft besser, verschiedene Meinungen aus einer grửòeren Gruppe einzuholen. Code zu zeigen, ist nicht das beste Mittel hierfỹr.
Ich bevorzuge UML-Diagramme und das Durcharbeiten von Szenarios mit Klas- senkarten (CRC cards). Auf diese Weise führe ich sowohl Design-Reviews in Grup- pen als auch Code-Reviews mit einzelnen Entwicklern durch.
Die Idee der aktiven Code-Review wird durch die ằExtreme Programmingô- Tech- nik [Beck, XP] der paarweisen Programmierung auf die Spitze getrieben. In dieser Technik erfolgt jede wichtige Entwicklung mit zwei Programmierern an einem Rechner. Das Ergebnis ist ein stọndiger Code-Review im Entwicklungsprozess, und darin geht auch das Refaktorisieren auf.
Warum Refaktorisieren funktioniert von Kent Beck Programme haben auf zweierlei Weise Wert: Durch das, was sie heute für Sie tun kửnnen, und durch das, was sie morgen fỹr Sie tun kửnnen. Wenn wir program- mieren, konzentrieren wir uns meistens auf das, was das Programm heute tun soll. Ob wir nun einen Fehler beheben oder eine neue Funktion hinzufügen, wir machen das Programm nỹtzlicher, indem wir es leistungsfọhiger machen.
Sie kửnnen kaum lange programmieren, ohne zu erkennen, dass das, was das Sys- tem heute macht, nur der eine Teil der Geschichte ist. Wenn Sie es schaffen, die heutige Arbeit auch heute zu erledigen, aber nur so, dass Sie mửglicherweise die morgigen Aufgaben nicht morgen erledigen kửnnen, so verlieren Sie. Aber Ach- tung: obwohl Sie vielleicht wissen, was Sie heute brauchen, kửnnen Sie nicht so
sicher sein, was Sie morgen brauchen. Vielleicht machen Sie dies, vielleicht das, vielleicht etwas, was Sie sich jetzt noch gar nicht vorstellen kửnnen.
Ich weiò genug, um die heutige Arbeit zu schaffen. Ich weiò nicht genug ỹber die morgige. Aber wenn ich nur für heute arbeite, bin ich morgen arbeitslos.
Refaktorisieren ist ein Ausweg aus dieser Zwickmühle. Stellen Sie fest, dass die Entscheidung von gestern heute falsch erscheint, so ọndern Sie sie. So kửnnen Sie die heutige Arbeit schaffen. Morgen mag manches von heute naiv erscheinen, also ọndern Sie es wieder.
Was macht die Arbeit mit Programmen so schwierig? Die vier Dinge, an die ich denke, wọhrend ich dieses schreibe, sind die folgenden:
• Schwer zu lesende Programme sind auch schwer zu ọndern.
• Programme mit duplizierter Logik sind schwer zu ọndern.
• Programme, bei denen neues Verhalten es notwendig macht, funktionieren- den Code zu ọndern, sind schwer zu ọndern.
• Programme mit komplexen Bedingungen sind schwer zu ọndern.
Wir wollen also Programme schreiben, die leicht zu lesen sind, die alle Logik an genau einer Stelle zusammenfassen, bei denen Änderungen das vorhandene Ver- halten nicht gefọhrden und die es ermửglichen, Bedingungen so einfach wie mửglich zu formulieren.
Refaktorisieren bezeichnet den Vorgang, ein funktionsfọhiges Programm zu neh- men und seinen Wert zu erhửhen, indem wir sein Verhalten nicht ọndern, aber ihm mehr von diesen Eigenschaften geben, die es uns ermửglichen, es mit hohem Tempo weiterzuentwickeln.