{"id":260,"date":"2016-06-24T10:06:29","date_gmt":"2016-06-24T09:06:29","guid":{"rendered":"http:\/\/refactoring-legacy-code.net\/?p=260"},"modified":"2024-02-23T09:44:04","modified_gmt":"2024-02-23T08:44:04","slug":"mikado-method-2","status":"publish","type":"post","link":"https:\/\/refactoring-legacy-code.net\/mikado-method-2\/","title":{"rendered":"Komplexe Refactorings an Legacy Code durchf\u00fchren – Teil 2"},"content":{"rendered":"

Dies ist der 2. Teil des Artikels \u00fcber die Mikado Methode. Lesen Sie ggf. zun\u00e4chst den 1. Teil<\/a>.<\/p>\n

Umsetzung des Refactorings mit der Mikado Methode<\/b><\/h2>\n

Im ersten Schritt ist durch eine experimentelle Vorgehensweise ein Mikado Graph<\/i> entstanden. Es wurde jeweils naiv versucht, die erforderlichen \u00c4nderungen am Code durchzuf\u00fchren. Alle Probleme, die sich bei diesen Experimenten gezeigt haben, sind als Vorbedingungen<\/i> f\u00fcr das Mikado Ziel<\/i> in den Mikado Graph \u00fcbernommen worden. Da die einzelnen Vorbedingungen aufeinander aufbauen, sich also in Abh\u00e4ngigkeiten befinden, enth\u00e4lt der Mikado Graph nicht nur die Vorbedingungen, sondern stellt auch die Abh\u00e4ngigkeiten dar.<\/p>\n

\"Mikado<\/a>Der Mikado Graph ist also ein gerichteter Graph<\/i>. An der Wurzel steht das Mikado Ziel, das durch die einzelnen Refactoring Ma\u00dfnahmen erreicht werden soll. Das Mikado Ziel kann so etwas sein wie \u201eSpeichern der Daten in der Cloud statt lokal\u201c oder \u201eFehler bei der Neuanlage eines Produkts beheben\u201c.<\/p>\n

Nachdem der Mikado Graph erstellt ist, werden die einzelnen Herausforderungen angegangen. Die Umsetzung der Refactorings erfolgt in der Gegenrichtung der Abh\u00e4ngigkeiten, von den Bl\u00e4ttern zur Wurzel. Wir arbeiten uns nun in der Gegenrichtung, im Bild von au\u00dfen nach innen, vor. Die einzelnen Herausforderungen werden gel\u00f6st und jeweils in die Versionskontrolle \u00fcbertragen. Beachten Sie, dass diese \u00c4nderungen auf dem Trunk<\/i> durchgef\u00fchrt werden, da sie von kurzer Dauer sind. Ein Branch<\/i> ist nicht erforderlich, weil die \u00c4nderungen nicht lange dauern und das Ergebnis potentiell auslieferbar sein soll. Automatisierte Tests sollten entweder schon vorhanden sein oder im Zuge des Refactorings erg\u00e4nzt werden. Vor dem Commit in die Versionskontrolle muss schlie\u00dflich sicher gestellt sein, dass die \u00c4nderung zu keinen Defekten gef\u00fchrt hat.<\/p>\n

Die Mikado Methode<\/b><\/h2>\n

Die folgende Abbildung zeigt den Ablauf der Mikado Methode.<\/p>\n

\"Die<\/a>Das Mikado Ziel<\/i> notieren<\/h3>\n

Zu Beginn wird das Ziel der \u00c4nderung notiert. Dieses Ziel ist getrieben von einer Anforderung des Kunden. Ein neues Feature oder die \u00c4nderung eines bestehenden Features sowie Bugfixes sind potentielle Ziele einer \u00c4nderung.<\/p>\n

Das Ziel bzw. die aktuelle Vorbedingung naiv implementieren<\/h3>\n

Nun wird versucht, das Ziel auf naive Weise zu erreichen. Implementieren Sie munter drauf los. Wichtig ist jetzt herauszufinden, was der Umsetzung im Weg steht. Es geht in diesem Schritt nicht darum die endg\u00fcltige Implementation vorzunehmen, sondern Erkenntnisse zu gewinnen. Daher ist es in Ordnung, das ein oder andere Clean Code Developer Prinzip zu verletzen, da der Code ohnehin zun\u00e4chst wieder weggeworfen wird. Allerdings d\u00fcrfen Sie in diesem Schritt nicht \u00fcber die Str\u00e4nge schlagen. Halten Sie immer wieder inne und pr\u00fcfen Sie, ob Sie an einem Punkt angekommen sind, an dem es darum gehen k\u00f6nnte, einen Erkenntnisgewinn im Mikado Graph zu notieren. Wenn Ihr System sich pl\u00f6tzlich nicht mehr wie gew\u00fcnscht verh\u00e4lt oder die \u00c4nderung viele Compilerfehler an allen m\u00f6glichen Stellen verursacht, haben Sie einen solchen Punkt erreicht.<\/p>\n

Gibt es ein Problem?<\/h3>\n

Wenn Sie eine \u00c4nderung durchgef\u00fchrt haben, m\u00fcssen Sie herausfinden, ob es ein Problem gibt. Es k\u00f6nnte sein, dass das Programm nicht mehr tut was es soll. Dann liegt definitiv ein Fehler vor. Wenn Sie automatisierte Tests haben, sind Sie fein raus, denn dann schl\u00e4gt wom\u00f6glich einer fehl. Ohne Tests bleibt Ihnen nur das manuelle Testen. Im Zweifel gehen Sie an dieser Stelle davon aus, dass etwas kaputt gegangen ist.<\/p>\n

Zum zweiten k\u00f6nnen Sie auf Probleme in Ihrer Codebasis sto\u00dfen. Wenn Sie bei der naiven Umsetzung auf eine Herausforderung sto\u00dfen, sollten Sie an dieser Stelle ebenfalls anhalten. Typische Herausforderungen sind Abh\u00e4ngigkeiten. Sie stellen pl\u00f6tzlich fest, dass Sie eine Abh\u00e4ngigkeit \u00fcbersehen haben und die \u00c4nderung erst abschlie\u00dfen k\u00f6nnen, wenn Sie die Abh\u00e4ngigkeit eliminiert oder ver\u00e4ndert haben. Eine weitere typische Herausforderung ist das Vermischen von Aspekten. Sie stellen fest, dass eine Methode oder Klasse nicht nur f\u00fcr einen Aspekt zust\u00e4ndig ist, sondern ein Durcheinander von Aspekten vorliegt. Um in guter Weise weiterzukommen, m\u00fcssen Sie erst die Aspekte trennen. Notieren Sie die Herausforderung als Vorbedingung im Mikado Graph und betrachten Sie das Ergebnis der \u00c4nderung als ein Problem.<\/p>\n

Ergibt die \u00c4nderung Sinn?<\/h3>\n

Wenn es keinen Fehler gab, m\u00fcssen Sie herausfinden, ob die \u00c4nderung Sinn ergibt. Hier geht es darum, \u00c4nderungen nur dann in die Versionskontrolle zu \u00fcbertragen, wenn diese zusammenh\u00e4ngend einen Sinn ergeben. Das bedeutet, Sie sollten nun keine Ergebnisse einchecken, die einen unfertigen Zwischenschritt darstellen.<\/p>\n

Typischerweise kommen Sie hier erst zu einer positiven Entscheidung, wenn Sie begonnen haben, die Erkenntnisse des Mikado Graphs Blatt f\u00fcr Blatt umzusetzen. Sie haben also nicht mit dem Ziel des Mikado Graph begonnen, sondern haben sich ein Blatt des Graphen ausgesucht und begonnen, diese Voraussetzung f\u00fcr das Oberziel zu implementieren. Hierbei sollten Sie nat\u00fcrlich irgendwann zu der Entscheidung kommen k\u00f6nnen, dass die \u00c4nderung Sinn ergibt. Sie befinden sich jetzt nicht mehr in der Experimentierphase sondern sind dabei, die gewonnenen Erkenntnisse Blatt f\u00fcr Blatt umzusetzen.<\/p>\n

Sie sollten die \u00c4nderung durch automatisierte Tests absichern. Auf diese Weise ist es leichter herauszufinden, ob die \u00c4nderung Sinn ergibt.<\/p>\n

Commit der \u00c4nderungen in die Versionskontrolle<\/h3>\n

Sofern die \u00c4nderungen einen Sinn ergeben, \u00fcbertragen Sie diese in die Versionskontrolle. Im Mikado Graph machen Sie einen Haken an die Vorbedingung, denn sie ist nun umgesetzt. Dadurch ergeben sich neue Bl\u00e4tter, die das Ziel der n\u00e4chsten \u00c4nderung sein k\u00f6nnen.<\/p>\n

Ist das Mikado Ziel erreicht?<\/h3>\n

Nach dem Commit m\u00fcssen Sie entscheiden, ob das Mikado Ziel bereits erreicht ist. Wenn ja, sind Sie fertig.<\/p>\n

Nach L\u00f6sungen suchen<\/h3>\n

Wenn es Fehler gab, m\u00fcssen Sie nun nach einer L\u00f6sung suchen. Fehler k\u00f6nnen auf der Ebene des Programmcode auftreten. Ein Beispiel k\u00f6nnte sein, dass Sie feststellen, dass Sie das Programm beim Entfernen einer Abh\u00e4ngigkeit nicht mehr \u00fcbersetzen k\u00f6nnen. Ferner k\u00f6nnen Fehler bei der Ausf\u00fchrung des Programms auftreten. Ihre \u00c4nderung hat das Programm \u201ekaputt gemacht\u201c. In beiden F\u00e4llen m\u00fcssen Sie nach L\u00f6sungsideen suchen.<\/p>\n

Die L\u00f6sungen als Vorbedingungen im Mikado Graph notieren<\/h3>\n

Haben Sie eine L\u00f6sungsidee f\u00fcr das Problem gefunden, notieren Sie diese im Mikado Graph. Achten Sie darauf, dass die im Graph notierte Vorbedingung nicht zu umfangreich ist. Teilen Sie umfangreiche Aufgaben besser in mehrere Schritte auf. Achten Sie dabei darauf, die Abh\u00e4ngigkeiten der einzelnen Schritte korrekt darzustellen.<\/p>\n

Verwerfen aller \u00c4nderungen mit Hilfe der Versionskontrolle<\/h3>\n

Dieser Schritt der Mikado Methode ist sehr wichtig: verwerfen Sie nun alle \u00c4nderungen!<\/b> Nur so ist sichergestellt, dass Sie die n\u00e4chsten Schritte wieder auf einem bekannten Zustand auszuf\u00fchren. Wenn Sie auf dem \u201ekaputten Code\u201c weiterarbeiten, w\u00fcrden Sie sehr schnell den \u00dcberblick verlieren und sich im Chaos verstricken. Durch die Visualisierung im Mikado Graph soll genau das verhindert werden. Dazu muss jeder einzelne Schritt auf einer Codebasis durchgef\u00fchrt werden, von der Sie wissen, in welchem Zustand sie ist. Andernfalls schichten Sie einen gro\u00dfen Stapel Probleme auf. Schauen Sie sich dazu noch mal die Bildfolge im ersten Teil\u00a0des Artikels<\/a> an. Nachdem Sie ein Pflaster draufgelegt haben, erscheinen sofort weitere Probleme. Da verlieren Sie schnell den \u00dcberblick. Sie befinden sich dann typischerweise in einer der beiden folgenden Situationen:<\/p>\n