Refactoringseminar in München

Am 23. und 24. März gebe ich in München wieder das Intensivseminar „Refactoring in der Praxis oder die Kunst schmerzfreier Änderungen“ in Zusammenarbeit mit SIGS DATACOM. Der Kurs bietet die Möglichkeit, Refaktorisieren am praktischen Beispiel zu erlernen und zu vertiefen bis hin zur emergenten Entwicklung einer kleinen Architektur.

Es sind noch Plätze frei, weitere Informationen und Anmeldemöglichkeiten finden Sie hier.

Refactoring mit PHP

Dass Refactoring in Java mit Eclipse so richtig Spaß macht und auch die Kombination von Visual Studio mit Resharper oder DevExpress ganz brauchbar ist, dürfte zumindest unter Agilisten hinreichend bekannt sein. PHP-Entwickler haben es da deutlich schwerer, wie Roy Ganor in seinem Blog-Eintrag „Refactoring PHP Code“ beschreibt. Zend scheint zumindest ein paar Basisfunktionen anzubieten, aber selbst der Beitrag (auf dem Firmenblog!) klingt nicht wirklich enthusiastisch. Dennoch kann es sich für PHP-Entwickler lohnen, hineinzuschauen und zumindest zu beobachten, was dort die nächste Zeit passiert.

Achtung: Ich selbst habe keinerlei Erfahrung mit Refactoring unter PHP! Wer da mehr weiß, ist herzlich eingeladen, hier Kommentare zu ergänzen.

Notizen von der OOPSLA – Refactoring Werkzeuge

Einmal im Jahr gönne ich mir den Besuch der OOPSLA. Zum einen, um Bekanntschaften und Freundschaften zu pflegen, aber auch, um einen Überblick zu bekommen, was derzeit an (wirklich) neuen Dingen aufkommt, abseits der aufgeregten Marketing-Hypes. Ich möchte hier über für mich interessante Erkenntnisse berichten.

Am ersten Tag entschloss ich mich kurzfristig, als Zuhörer am zweiten Workshop über Refactoringwerkzeuge teilzunehmen. Eine Entscheidung, die sich gelohnt hat, obwohl ich normalerweise „Präsentationsworkshops“ meide. Der Workshop hat einen guten Überblick über den aktuellen Stand der Forschung zum Thema Refactoring gegeben — und deutlich gemacht, dass wir hier erst am Beginn einer Entwicklung stehen, die unsere Arbeit über die nächsten Jahre wesentlich beeinflussen wird.

Zu den Vorträgen:

Refactoring bei IntelliJ

Dimitri Jemerov von JetBrains (IntelliJ, Resharper) stellte die Mechanismen hinter den Refactoring Browser von IntelliJ IDEA vor. Er basiert auf einem gemeinsamen „Refactoring Workflow Framework“, mit dem sich die einzelnen Operationen relativ einfach implementieren lassen. Jemerov sprach von einer „Refactoring DSL“, die bei IntelliJ dafür entwickelt wurde.

Während die Grundlagen relativ gut standardisierbar sind (und die vorgestellten Ideen auch entsprechend wenig überraschend), liegt der Teufel und damit auch der Aufwand im Detail. Hier diktiert die Sprachkomplexität auch die Komplexität des Refactorings. Gerade bei Java mit seinen Einschränkungen was wo erlaubt ist, führt das beim Refactoring gelegentlich auch zu Ergebnissen, die nicht gerade schön sind. Die Begründung war pragmatisch: Normalerweise wird refaktorisierter Code nicht mehr überprüft. Daher muss er zu 100% korrekt sein, auch wenn das Ergebnis nicht gerade elegant ist.

Interessante Features von IntelliJ, die er vorstellte, waren:

  • Extract Method bei mehreren Ergebniswerten: Hier werden komplette Klassen erzuegt und extrahiert.
  • Refactorings über mehrere Sprachen: Während der aktuelle Stand (Rename, Move) noch nicht so aufregend ist, wird derzeit daran gearbeitet, die interne Darstellung sprachübergreifend zu gestalten, um auch komplexe Refactorings sprachübergreifend zu ermöglich. Geplant ist Unterstützung von Java, Ruby, Groovy, Python und XML (wenn ich keinen vergessen habe…)
  • Veränderung von Typen: Als Beispiel ersetzte Dimitri ein Array durch eine Liste, ein Beispiel für ein ziemlich komplexes Refactoring, das auch nur teilautomatisiert möglich ist. Leider reichte die Zeit nicht aus, das im Detail darzustellen.

Die anschließende Diskussion kreiste vor allem um den Konflikt zwischen 100% korrektem Umbau des Codes, eleganten Ergebnissen und Unterstützung des Entwicklers. Es dürfte hier kaum möglich sein, den richtigen Weg zu finden.

Oberflächen für Refactoring Werkzeuge

Dustin Campbell, der vor wenigen Monaten von DevExpress (Refactor!) zu Microsoft wechselte, demonstrierte aktuelle Entwicklungen in der Oberfläche von Refactoring Werkzeugen am Beispiel von Refactor!. Der Trend geht dahin, den Browser nahtlos in den Editor zu integrieren: Keine Dialogboxen mehr, keine Sammlungen von Shortcuts, statt dessen kontext-sensitive Erweiterungen des Editors. Wer mit Eclipse arbeitet, kennt ähnliche Ansätze bereits vom Umbenennen eines Identifikators: Drückt man vor dem Editieren eines Identifikators eine bestimmte Tastenkombination, werden auch alle anderen Vorkommen umbenannt. Refactor! treibt diesen Ansatz wesentlich weiter: Das Werkzeug ist darauf optimiert, mit einem einzigen Shortcut kontextsensitiv zu arbeiten.

Die Demonstration war beeindruckend, hier wurde ziemlich sicher die derzeit beste Lösung für die Oberfläche des Werkzeugs präsentiert. Ob die dahinter liegenden Mechanismen mit den Anforderungen großer Systeme mithalten können, weiß ich nicht. Ebenso wenig ist mir klar, ob diese Art der Oberfläche für Umbauten an großen Systemen noch adäquat ist, insbesondere in Situationen, in denen bewusst nicht-vollständige Refactorings eingesetzt werden sollen. Das lässt sich sicherlich nur durch praktischen Einsatz herausfinden (Bekannt ist, dass Refactor! für C++ erhebliche Stabilitätsprobleme hat. Die Versionen für C# (und andere .NET Sprachen) scheinen nicht so extrem unter diesem Problem zu leiden). Unabhängig davon ist die enge Integration von Editor und Refactoring sehr interessant (sie war genau genommen bereits in John Grants und Don Roberts „Ur-Refactoring-Browser“ angelegt) und ich hoffe, dass sie sich auf breiter Basis durchsetzen.

Werkzeuge zur Entwicklung von Refactoring Werkzeugen

Dieser Teil des Workshops richtete sich naturgemäß eher an jene, die selbst Refactoring bauen, als an deren Anwender. Ich fand die Vorträge dennoch interessant, weil sie einen guten Eindruck liefern, mit welchen Problemen derzeit gekämpft wird und was uns die Zukunft hier bringen kann.

Verbesserung der Analyse

Max Schäfer von der Oxford University stellte eine Refactoring Engine vor, die sich vor allem um Namensprobleme kümmert, um sicher zu stellen, dass die verbreiteten Probleme, die Refactoringwerkzeuge mit Verschattung von Namen haben. Aus Anwendersicht war die Nachricht interessant, dass keines der marktüblichen Werkzeuge hier wirklich sauber arbeitet. Es lohnt sich also weiterhin, darauf zu achten, dass man die Verschattungsregeln der Sprachen nicht zu sehr ausreizt — eine Regel, die schon im Interesse der Lesbarkeit von Programmen sinnvoll ist.

Framework für den Bau von Refactoring Werkzeugen

Jeffery Overbey, ein Diplomand von Ralph Johnson an der Univerity of Illinois, Urbana Champaign, demonstrierte einen Ansatz, die für brauchbares Refactoring notwendigen Syntaxbäume aus speziellen Grammatiken zu erzeugen. Sein Demonstrationsobjekt war ein Transformationswerkzeug für Fortran-Programme. Hier ging es eher im Detailprobleme, die eher für Werkzeugbauer von Interesse sind, wie zum Beispiel der Umgang mit Kommentaren und Einrückungen, Themen die im klassischen Compilerbau kaum eine Rolle spielen, für die Akzeptanz von Refactoring Werkzeugen aber entscheidend ist. Der Vortrag hat schön gezeigt, dass Refactoringwerkzeuge derzeit eine ähnliche Entwicklung durchmachen, wie Compiler in den 70er Jahren. Das halte ich durchaus für einen Grund, sich auf die Werkzeuge der nächsten zwanzig Jahre zu freuen 🙂

Refactoring auf höherer Ebene

Macneil Shonle von der University of San Diego stellte ein Plug-in für Eclipse vor, das versucht, Java Refactorings auf höherer Ebene umzusetzen (Arcum). Auch wenn sich der Vortrag eher um Grundlagenforschung drehte, zeigte er doch, dass zumindest die angelsächsischen Universitäten mittlerweile den Ball aufgenommen haben und an den komplexen Problemen wie Migrationen von Bibliotheken forschen. Sollten diese Arbeiten für den professionellen Einsatz reif werden — womit ich nicht in den nächsten zehn Jahren rechne —, könnte das den Umgang mit Architektur und Bibliotheken ähnlich revolutionieren, wie die derzeitigen Werkzeuge den Umgang mit Code und Design verändert haben.

Analyse des Refactoring von Entwicklern

Emerson Murphy-Hill von der Portland State University berichtete über Strategien, um herauszufinden, welche Refactorings an einer Codebasis durchgeführt wurden. Auch er stellte noch mehr Fragen vor, als Antworten. Ziel ist die Verbesserungen von Refactoringwerkzeugen, das Thema kann aber auch relevant werden, um Dokumentations- und Revisionsanforderungen zu erfüllen, oder in Wartungssituationen den Code zu verstehen. Zweifel sind aber angebracht: Murphy-Hill stellte fest, dass nur ca. 10% der Refactorings mit Werkzeugen durchgeführt werden und nur etwa ein Drittel sich überhaupt im Versionsmanagement niederschlagen. Sein Resümee: Wir kennen (noch) keine zuverlässige Methode, durchgeführte Refactorings zu ermitteln.

Zum Nachdenken hat auch eine Erkenntnis am Rande angeregt: Deutete ein Check-in in das Versionsmanagement einen Kommentar, der auf Refactoring hindeutet, war die Anzahl der darin enthaltenen Umbauten halb so groß [sic!], wie bei Check-ins ohne solche Kommentare. Es wäre interessant, ob sich das auf die Zuverlässigkeit von Check-in-Kommentaren verallgemeinern lässt.

Refactoring Lab

Josh Kerievsky, Autor des Buchs „Refactoring to Patterns“ und Gründer von „Industrial Logic„, zeigte den Einsatz seines „Refactoring Labs“, eines Trainingswerkzeugs für Refactoring. Die Studenten werden vor eine Refactoringaufgabe gestellt und das Lab analysiert den gewählten Lösungsweg und macht Verbesserungsvorschläge, z.B. dass bestimmte Schritte, die manuell gemacht wurden, einfacher im Refactoringbrowser durchgeführt werden können. Die Regeln sind als JUnit-Tests hinterlegt und überprüfen z.B. wie oft die Tests gestartet wurden und welche Optionen beim Umbau eingesetzt wurden. Ein sehr nettes Werkzeug für die Schulung.

Refactoring für Nebenläufigkeit

Der Organisator Danny Dig berichtete über seine Arbeiten am MIT, in denen er versuchte, sequenziell geschriebenen Code in Code umzustellen, der die Java 5 Unterstützung für Nebenläufigkeit nutzt. Das Werkzeug heißt Concurrencer und ist als Eclipse-Plugin verfügbar. Die Wirksamkeit des Tools wurde mit 6 Open Source Projekten überprüft. Die Ergebnisse waren zwar nicht perfekt, aber deutlich besser, als die manuellen Umstellungen der Entwickler, die die entsprechenden Werkzeuge betreuen. Immerhin machte das Werkzeug keine Fehler, die zu Fehlfunktionen der Software führen können — im Gegensatz zu vier solchen Fehlern im offiziellen, manuell umgestellten Code. Als wichtige Richtung für die zukünftige Entwicklung wurde die Integration mit Analysewerkzeugen angesprochen: Deren Ergebnisse sollten die Entwickler durch die notwendigen Schritte leiten.

Wer vor dem Problem steht, Java Code threadsafe zu machen, sollte sich das Tool genauer ansehen.

Refactoring von Programmen zur Matrixmanipulation

Beverly Sanders von der University of Florida erzählte über den Einsatz von Refactoring in der algebraischen Chemie. Dabei werden chemische Reaktionen simuliert, was im Wesentlichen darauf hinausläuft, Lösungen für die Schrödingergleichungen zu finden. Die Programme laufen auf hoch-parallelen Supercomputern mit speziellen DSLs für Matrizenumformungen. Hier wird Refactoring nicht zur Verbesserung des Designs eingesetzt, sondern um die Performance und Ausführungskomplexität zu verbessern. Das geht oft nicht durch pures Ansehen, sondern auf der Basis von Messungen. Für mich war die Einsicht spannend, dass man Refactoring auch in zunächst anderen Domänen mit ganz anderen Zielen betreiben kann. Der Schluss liegt nahe, dass wir hier erst ganz am Anfang stehen.

Resümee

Refactoring steht erst am Anfang. Sowohl für die Werkzeuge im breiten Einsatz, als auch in Randthemen besteht noch erheblicher Forschungsbedarf, der zunehmend von den Universitäten auch angegangen wird. Aus Sicht des Praktikers kann man nur hoffen, dass sich diese Forschung so bald wie möglich in breit einsetzbaren Produkten niederschlägt. Das könnte die Art, wie wir programmieren weg vom Programme schreiben hin zu Software entwickeln revolutionieren — vorausgesetzt, die Ausbildung wird auch entsprechend angepasst.

Refactoringseminar in München

Es ist bald wieder so weit: Am 19. und 20. November gebe ich in Zusammenarbeit mit SIGS Datacom zum dritten Mal öffentlich das zweitägige Intensivseminar „Refactoring in der Praxis oder die Kunst schmerzfreier Änderungen„. In dem Seminar werden die Teilnehmer ausgehend von unlesbarem Code durch diszipliniertes Refactoring zunächst wartbaren Code erzeugen und dann daraus Ansätze für eine Architektur entwickeln. Neben der praktischen Arbeit gibt es natürlich auch Hintergrundinformationen und die notwendige Theorie. Der Kurs ist bisher von dem Teilnehmern mit der Note 1,6 benotet worden.

Weitere Informationen und die Anmeldeseite finden Sie hier.

Refactoring-Seminar in München am 21./22.7.

Die Aufbauarbeiten am OBJEKTspektrum haben ihre Spuren hinterlassen: Der Blog musste ein wenig ruhen und wird erst jetzt wieder langsam aufgeweckt:

Am 21./22. Juli (Mo/Di) halte ich in München gemeinsam mit SIGS Datacom das Seminar „Refactoring in der Praxis oder Die Kunst schmerzfreier Änderungen„. Die Teilnehmer werden in dem Seminar ein Stück völlig unlesbaren Codes Schritt für Schritt so weit refaktorisieren, dass eine erste Architektur entsteht. Die dabei angewendeten Strategien arbeiten wir natürlich auch sauber auf und unterfüttern sie mit allem, was man braucht, um sie im Projekt anzuwenden und um sich selbst weiter einzuarbeiten.

Technisch arbeiten wir in Java auf Eclipse, es sind aber keine tiefen Java-Kenntnisse erforderlich. Die Strategien lassen sich ohne weiteres auch auf C# oder C++ abbilden – allerdings leider mit unterschiedlich großem manuellem Aufwand. Bei Bedarf sprechen wir auch über die spezifischen Probleme in diesen beiden Sprachen.

Die Teilnehmer des letzten Durchgangs haben den Kurs mit einer glatten Eins bewertet.

Anmelden können Sie sich über http://www.sigs-datacom.de/sd/seminare/evt_seminar_show.htm?&TABLE=sd_product&PID=1087

Architektur und Agilität

Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von „Agilisten“ und „Traditionalisten“ das Stichwort „Architektur“: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: „Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus“ und „Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren“. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.

Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:

  • Wann wird die Architektur erstellt? Ist die Architektur eine eigene Phase zu Projektbeginn, wird sie zu Beginn jeder Iteration erstellt, oder entsteht Sie während des Programmierens durch Refaktorisieren?
  • Wie wird die Architektur repräsentiert? Existiert ein eigenes Dokument oder repräsentiert der Code die Architektur — wobei dann oft Werkzeuge eingesetzt werden, um grafische Darstellungen aus dem Code zu extrahieren und wichtige Eigenschaften zu prüfen, zum Beispiel automatisierte Test, um Abhängigkeiten zu prüfen.
  • Wer ist für die Architektur verantwortlich? Gibt einen oder mehrere Architekten? Als Entscheider oder als Moderatoren? Oder ist das Entwicklungsteam gemeinsam verantwortlich?

Ich denke, auf welche „Seite“ man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als „selbstverständlich“ vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:

In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.

In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.

Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.

Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.

In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.

ReFit: Refaktorisieren von Akzeptanztests

Johannes Link hat einen Werkzeugsatz geschrieben, mit dem man größere Mengen an FitNesse-Seiten umstellen und Refaktorisieren kann. Derzeit präsentiert sich ReFit, wie er das Werkzeug nennt, recht spartanisch als Groovy-Konsole, Johannes hat mir aber versichert, dass er jeden unterstützt, der Lust hat, dazu eine schicke grafische Oberfläche zu schreiben. Im Projekt verwendbar ist ReFit jetzt schon, zumindest wenn die Entwickler sich noch nicht auf die Maus beschränken, sondern noch mit der Tastatur umzugehen wissen…

Weitere Informationen und Links finden Sie auf Johannes Links Blog unter dem Titel Refactoring FitNesse Tests.

Seminar Refaktorisieren in München

Am 5. und 6. März gebe ich in Zusammenarbeit mit SIGS Datacom ein zweitägiges Seminar zu Refaktorisieren in München. Nach einer wirklich kurzen Einführung können Sie in dem Seminar erleben, wie Sie mit Hilfe kleinster, sicherer Schritte zunächst völlig unverständlichem Code in eine lesbare Variante umformen, um sie dann in Richtung einer neuen Architektur weiter zu entwickeln. Natürlich werden wir auch mögliche Rollen von Refaktorisieren im Projekt diskutieren, emergente Archtiekturen ansprechen und bei Bedarf ein wenig Richtung testgetriebene Entwicklung schauen.

Im Gegensatz zu manchen anderen Seminaren zum Refaktorisieren werde ich keine drögen Transformationskapitel abarbeiten, sondern lege Wert darauf, dass die Teilnehmer Strategien des Refaktorisierens verstehen und eintrainieren. Das macht nicht nur mehr Spaß, sondern bildet vor allem das Rüstzeug für die eigene Weiterbildung.

Zielgruppe sind Entwickler, Architekten und Projektleiter. Ein paar Grundkenntnisse mit Java und Eclipse sind hilfreich und Sie sollten keine Angst vor dem Programmieren haben. Sie brauchen Sie einen Laptop mit Windows XP (oder einer Windows XP VM), die restliche Software erhalten Sie während des Seminars. Anmelden können Sie sich auf der Semniarseite von SIGS Datacom.

Refactoring von Spaghetticode

Refactoring von Spaghetticode ist grundsätzlich anders, als Refactoring im Rahmen testgetriebener Entwicklung: Letzteres ist gut verstanden und bedarf keiner besonderen Beachtung während der Planung, die einzelnen Refactoringschritte dauern immer nur ein paar Minuten und sind in der Gesamtschätzung enthalten.

Wenn man aber versucht, alten Spaghetticode durch Refactoring wieder in einen wartbaren Zustand zu bringen, sieht die Sache ganz anders aus. Dies ist ein kaum planbares Unterfangen mit hohem Zeit- und Aufwandsrisiko. Der Nutzen kommt dabei häufig erst, wenn die Arbeiten deutlich voran geschritten sind; oft wird also Monate lang ohne greifbaren Nutzen entwickelt, bis sich der „Knoten“ plötzlich auflöst und ein deutlich besser wartbares Design entsteht, das exakt der alten Funktionalität entspricht – modulo der Fehler, die man üblicherweise während dieser Arbeit noch entdeckt und behebt.

Um die Situation etwas zu entschärfen, gehen wir bei solchen Vorhaben oft in mehreren Phasen vor, die sich bisher ganz gut bewährt haben (ich spreche hier von „wir“, weil ein solcher Umbau immer im Team oder mindestens von einem Paar durchgeführt werden muss, niemals von einem „Einzelkämpfer“):
Weiterlesen