ằWie sag ich’s meinem Chef?ô ist eine der họufigsten Fragen, die mir im Zusam- menhang mit dem Refaktorisieren gestellt werden. Ist der Chef technisch interes- siert, so wird es nicht schwierig sein, das Thema anzusprechen. Ist der Chef ernst- haft an Qualitọt interessiert, so muss man die Qualitọtsgesichtspunkte hervorhe- ben. In diesem Fall ist der Einsatz des Refaktorisierens bei Reviews eine Erfolg versprechende Vorgehensweise. Tausende von Untersuchungen zeigen, dass tech- nische Reviews ein wichtiger Ansatz sind, um die Fehleranzahl zu verringern und das Entwicklungstempo zu erhửhen. Werfen Sie hierzu einen Blick in irgendein
aktuelles Buch über Reviews, Inspektionen oder den Softwareentwicklungspro- zess, um die aktuellsten Quellen zu finden. Das sollte die meisten Manager vom Wert von Reviews überzeugen. Von hier ist es nur noch ein kleiner Schritt, um das Refaktorisieren als eine Methode einzuführen, bei der die Kommentare eines Re- views direkt Eingang in den Code finden.
Natỹrlich gibt es viele, die behaupten, auf Qualitọt zu achten, die aber tatsọchlich mehr auf das Einhalten des Zeitplans Wert legen. In diesem Fall gebe ich meinen eher umstrittenen Rat: Erzọhlen Sie nichts davon.
Ist dieser Rat subversiv? Ich glaube kaum. Softwareentwickler sind Profis. Unsere Aufgabe ist es, wirkungsvolle Software so schnell wir mửglich zu schaffen. Nach meiner Erfahrung ist das Refaktorisieren eine riesige Hilfe, um Software schnell zu entwickeln. Muss ich eine neue Funktion hinzufügen und das Design passt hier- für nicht, so empfinde ich es als schneller, erst zu refaktorisieren und dann die Funktion hinzuzufügen. Muss ich einen Fehler beheben, so muss ich verstehen, wie die Software arbeitet – und für mich ist das Refaktorisieren der schnellste Weg, dies zu erreichen. Ein Chef, der auf einen engen Zeitplan setzt, erwartet, dass ich die Aufgaben so schnell wie mửglich erledige; wie, ist meine Sache. Der schnellste Weg ist das Refaktorisieren, also refaktorisiere ich.
Indirektion und Refaktorisieren von Kent Beck Informatik ist die Wissenschaft, die glaubt, dass alle Probleme durch eine weitere Indi- rektionsebene gelửst werden kửnnen – Dennis deBruler
Bei der Vernarrtheit von Informatikern in Schnittstellen mag es nicht verwun- dern, dass das Refaktorisieren meistens weitere Indirektionsebenen einführt. Das Refaktorisieren fỹhrt in der Regel dazu, groòe Objekte in mehrere kleinere Ob- jekte und groòe Methoden in mehrere kleinere Methoden zu zerlegen.
Aber Indirektion ist ein zweischneidiges Schwert. Immer wenn man etwas in zwei Teile zerlegt, hat man mehr zu verwalten. Wenn ein Objekt an ein anderes dele- giert, das weiter delegiert, kann ein Programm aber auch schwieriger zu lesen sein.
Insofern mửchten Sie Indirektionen minimieren.
Urteilen Sie aber nicht zu schnell. Indirektionen kửnnen sich bezahlt machen.
Hier folgen einige Mửglichkeiten:
• Verarbeitungslogik kann gemeinsam genutzt werden. Beispielsweise kann eine Methode von verschiedenen anderen aufgerufen werden oder eine Me- thode einer Oberklasse von allen Unterklassen genutzt werden.
• Absicht und Implementierung kửnnen getrennt dargestellt werden. Die Wahl des Namens jeder Klasse und jeder Methode gibt Ihnen eine Chance aus- zudrücken, was Sie beabsichtigen. Die Interna der Klasse oder Methode zeigen, wie Ihre Absicht in die Tat umgesetzt wird. Gelingt es Ihnen, die Interna durch Ziele kleinerer Einheiten zu beschreiben, so kửnnen Sie Code schreiben, der die wichtigsten Informationen über seine eigene Struktur direkt vermittelt.
• Änderungen kửnnen isoliert werden. Ich verwende ein Objekt an zwei ver- schiedenen Stellen. In dem einem Fall mửchte ich das Verhalten ọndern. Än- dere ich das Objekt, so riskiere ich, es in beiden Fọllen zu ọndern. Deshalb bilde ich zunọchst eine Unterklasse und verwende diese an der Stelle, an der die Än- derung erfolgen soll. Nun kann ich die Unterklasse ọndern, ohne eine unbeab- sichtigte Änderung an der anderen Stelle zu riskieren.
• Bedingungen kửnnen verborgen werden. Mit polymorphen Nachrichten haben Objekte einen fabelhaften Mechanismus, um Bedingungen klar auszu- drỹcken. Sie kửnnen oft explizite Bedingungen durch Nachrichten ersetzen und dadurch gleichzeitig Duplikate reduzieren, die Verstọndlichkeit verbes- sern und die Flexibilitọt erhửhen.
Und dies sind die Spielregeln des Refaktorisierens: Wie kửnnen Sie unter Beibehal- tung des gegenwọrtigen Verhaltens das System verbessern, indem Sie seine Quali- tọt erhửhen oder seine Kosten senken?
In der họufigsten Spielart sehen Sie sich Ihr Programm an. Sie identifizieren Stel- len, an denen ihm einer oder auch mehrere der Vorteile der Indirektion fehlen.
Fügen Sie an diesen Stellen eine Indirektionsebene ein, ohne das Verhalten des Programms zu ọndern. Sie verfỹgen nun ỹber ein wertvolleres Programms, denn es hat zusọtzliche Eigenschaften, die Sie in der Zukunft schọtzen werden.
Beachten Sie den Unterschied zum traditionellen Design, bevor implementiert wird. Spekulatives Design versucht alle guten Eigenschaften in ein System einzu- bauen, bevor die erste Zeile Code geschrieben wird. Anschlieòend kann der Code einfach in dieses Skelett eingehọngt werden. Das einzige Problem ist, dass man sich sehr leicht verschọtzen kann. Beim Refaktorisieren laufen Sie nie Gefahr, vửl- lig falsch zu liegen. In jedem Fall arbeitet das Programm hinterher nicht anders als vorher. Darüber hinaus haben Sie die Gelegenheit, den Code zu verbessern.
Es gibt aber auch eine andere, seltenere Art des Refaktorisierens. Diese besteht da- rin, unnửtige Indirektionsebenen zu identifizieren und zu entfernen. Diese treten oft in der Gestalt von vermittelnden Methoden auf, die eine Aufgabe hatten, aber diese nicht mehr erfüllen. Es kann sich aber auch um eine Komponente handeln, von der Sie annehmen, dass sie oft verwendet oder spezialisiert wird, die aber tat- sọchlich nur an einer Stelle benutzt wird. Wieder haben Sie ein besseres Pro- gramm, diesmal nicht, weil es mehr von den vier Qualitọtseigenschaften hat, son- dern weil es weniger Indirektionsebenen erfordert, um die gleiche Qualitọt zu erreichen.