Begonnen habe ich mit der Vorgeschichte und den Episode 1, Episode 1, 2, 3 und 2, 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ihref="http://miradlo.net/bloggt/index.php?79-s""> 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefhref="http://miradlo.net/bloggt/index.php?80-s""> 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folghref="http://miradlo.net/bloggt/index.php?79-s"">Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folgende Dateien:

• 

• TestDummyModel Eine Unit-Testklasse mit der das DummyModel auf Funktion überprüft wurde.
• BaseUIElement Der Observer mit dem das Subjekt überwacht werden soll.
• TestBaseUIElement Ratet mal Ist wohl eine Testklasse.
• BaseModel Beinhaltet die Basis-Modell Information und schlussendlich die echte Subjekt-Methode.

Um das BaseModel testen zu können, wurde ein TestBaseModel eingeführt. Das DummyModell wurde nur dazu benötigt um die protected-Methoden der BaseModelklasse testen zu können. Der Aufwand, um DummyModel und TestDummyModel entwickeln zu können, betrug in etwa einen Arbeitstag. Jetzt kommt aber der Hammer: Die Wartung von DummyModel und TestDummyModel kostete zwei Stunden. Im zweiten Jahr wuchsen die Wartungsaufwände auf zwei Tage an. Das bedeutet, dass die Wartung mehr kostete als die ursprüngliche Herstellung. Wie konnte das passieren? DummyModel wurde nicht nur für den Test von BaseModel verwendet, sondern wurde in vielen anderen Testszenarien als einfache Lösung angesehen, die protected-Methoden von BaseModel zu verwenden.

• 

Eine Änderung am DummyModel verursachte nun enorme Kosten bei den Testklassen.

Was kann man da besser machen?

Ok, zuerst kann man mal über ein sauberes Konzept und „wir programmieren nur gegen Schnittstellen“ und all die schönen Regeln beherzigen. Manchmal sieht man aber den Klassenwald vor lauter Methoden nicht mehr. Lavacode entsteht, niemand kann ihn 100% verhindern. Wenn aber so ein Problem erkannt wurde, muss man handeln. Orlando griff in die Tasten und entfernte das DummyModel. Das Testen der protected-Methoden löste er durch eine Wrapperklasse im TestBaseUIModel und die Testklassen wurden so umgebaut, dass sie sich wieder an Schnittstellen halten und keine Wartungsexplosion zu erwarten ist. Karl hatte an einem nebligen Freitag ein Problem beim Review. „Jungs schaut mal her: Diese Methode hier verursacht das Problem, dass wir an zwanzig Stellen im Programm Abhängigkeiten schaffen. Das ganze ist nicht modular sondern vernetzt. Wenn ich das jetzt aber ändern soll werde ich nicht fertig und außerdem müssen wir das extrem gut testen. Was sollen wir machen?“ Termine drücken im Familiengeschäft immer. Wenn die drei den nächsten Release vergeigen ist mindestens einer der Drei bei Fred. Dementsprechend sind Klaus, Orlando und Hans etwas vorsichtig beim kompletten Umstellen der Systemkomponenten. Hans schaute sich das Problem an: „Also gut, wir schaffen das jetzt nicht. Geh doch durch alle dir bisher bekannten Komponenten durch und schreibe ein TODO hinein. Wir analysieren das Thema über die nächsten Wochen und falls wir dann glauben, dass wir es schaffen können, putzen wir den Code.“ Diese Idee beruhigte die Nerven der drei gestressten Entwickler doch sehr. Vier Review-Zyklen später war das Problem vollständig analysiert und sie konnten ohne Familienteich die Abhängigkeiten auflösen. Wenn beim Codereview festgestellt wird, dass ein größerer Aufwand vorhanden ist, muß dies vermerkt werden. Der Projektleiter muss eine Issue-Liste führen und neue Anforderungen und Probleme dort hinterlegen. Es werden immer Problemstellungen vorhanden sein, die nicht sofort gelöst werden können. Die schlechteste Alternative ist diese einfach zu verdrängen. Wenn im Sourcecode dokumentiert ist, dass noch Nacharbeiten notwendig sind und Zeit und Aufwand für diese Nacharbeiten im Projekt budgetiert worden sind, stellen diese notwendigen Korrekturen kein Problem dar.