Softwareprojekte Episode 5 ::: Coderefacturing und Lavacode Beseitigung

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.

Softwareprojekte Episode 3 ::: Refactoring kann helfen

Diese Geschichte über Softwareprojekte startete mit der Vohref="http://miradlo.net/bloggt/index.php?69-s"">Vorgeschichte, Episode 1, und Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schref="http://miradlo.net/bloggt/index.php?70-s"">Episode 1, und Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schwierigkeiten helfen kann. Die drei Nachfolger von Fred heißen Karl, Orlando und Hans. Orlando war auf einer Schulung und lernte dort das ein permanenter Review-Prozess den Schmerz mit der IT lindern kann. Nach der Schulung kam er völlighref="http://miradlo.net/bloggt/index.php?78-s"">Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schwierigkeiten helfen kann. Die drei Nachfolger von Fred heißen Karl, Orlando und Hans. Orlando war auf einer Schulung und lernte dort das ein permanenter Review-Prozess den Schmerz mit der IT lindern kann. Nach der Schulung kam er völlig glücklich und aufgeregt nach Hause und nahm Karl und Hans mit zum Picknick am Familienteich. „Wir haben ja mitbekommen, dass eine ständige Erweiterung des Systems außer in den Teich nirgends hinführt. Wir spüren jetzt schon seit Wochen, dass die Änderungen immer gefährlicher werden. Das Refactoring kann uns, glaube ich, sehr viel helfen.“ Hans verstand bisher noch nicht, was ihnen das Refactoring helfen könnte. „Theorien sind ganz nett, aber wenn wir Mist bauen, sitzen wir ein paar Meter tiefer hier im See und brauchen uns keine weiteren Sorgen machen. Hier geht es im wahrsten Sinn des Wortes um Kopf und Kragen. Ich habe noch keine Lust abzutreten und deshalb musst du mir schon mehr erzählen, wie das gehen kann.“ Karl nickte zustimmend und Orlando erläuterte die Vorgehensweise: „Wir wenden jede Woche ein paar Stunden auf um den vorhandenen Code zu analysieren. Jede Funktion, jede Variable und jeden Kommentar überprüfen wir, ob der vernünftig dokumentiert, wirklich benötigt oder durch einen einfacheren Code ersetzt werden kann.“ Karl verschluckte beinahe seine gelbe Rübe am Stück und mußte erst einmal kräftig würgen. „Du willst an den bestehenden Lava Code ran? Das ist doch Wahnsinn und ein direktes Ticket in den Teich!“ „Es ist gefährlich, aber wir haben so eine Chance auf Dauer stabiler zu werden und ein wartbares System hinzubekommen.“ Orlando bemerkte: „Ok, wir haben keine Chance also nutzen wir sie!“ Die drei machten sich mit zitternden Fingern ans Werk. In Entwicklungsprojekten führe ich im Schnitt einmal die Woche einen Codereview und Coderefactoring durch. Dabei nimmt ein Mitarbeiter den Code eines anderen Mitarbeiters und kontrolliert folgende Eigenschaften:

• Wird der Code wirklich benötigt? Eine einfache Kontrolle ist, ob auf den vorhandenen Code noch referenziert wird. Das kann man mit einfachem Suchen und Ersetzen feststellen.
• Gibt es genügend Testfälle (Unit Tests) für den Code?
• Kann die Dokumentation verstanden werden?
• Kann der Code einfacher gestaltet werden?
• Sollte der Code durch einen anderen ersetzt werden?

Die Kosten für diesen Code Review werden durch einen stabilen und lesbaren Code kompensiert. Die Fehlerquote fällt drastisch und kritische Fehler werden während der Entwicklung erkannt. Je nach Fähigkeiten der Entwickler (Anfänger, Fortgeschrittene oder Experten) sollte der Codereview gestaffelt sein. Bei Anfängern mehr, bei Experten reicht etwas weniger, da sie im Normalfall diesen Review schon intuitiv durchführen. Das bedeutet für den Projektleiter etwas Mut, die Entwicklung einmal pro Woche zu stoppen und Qualitätssicherung durchzuführen, für die Entwickler etwas Disziplin und für die Fehlerquote eine Reduktion. In der nächsten Episode will ich ein bisschen was übers Testen, im Speziellen über Unit Tests, erzählen.

Softwareprojekte Episode 1 ::: So klappts nicht mit der Software

Diese recht umfangreiche Einleitung soll, nach der Vorgeschichte, auf das Problem gewachsener Softwaresysteme hinführen. Ein monolitisches, nicht wartbares System entsteht nicht innerhalb von wenigen Tagen sondern wird durch viele Einflussfaktoren gebildet. Gründe hierfür können unter anderem sein:

• Schlechte oder nicht vorhandene Dokumentation
• Keine Architektur und keine Planung für eine durchgängige Architektur
• Nicht verstandene Konzepte
• Stolz
• Keine Betriebskonzepte

Die folgende Kurzgeschichte zeigt einen möglichen Verlauf, wie es zu einer nicht wartbaren und teuren Softwarelösung kommen kann, auf. Die Giuseppe Connection Ltd. ist ein durchaus erfolgreiches Familienunternehmen. Die Familienmitglieder halten zusammen und ein Austritt aus der Familie ist bisher noch keinem Familienmitglied lebend gelungen. Fred war ein junger, dynamischer Softwareentwickler, der von der Familie für ihr Geldwäschesystem eingestellt wurde. Ihr müsst wissen, dass in so einer Familie viel Geld in den Taschen der schweren Jungs steckt. Und da die schweren Jungs beim Geldeintreiben arg schwitzen wird das Geld schmutzig. Um nun einigermaßen koordiniert das Geld waschen zu können, hat die Familie ihr Geldwäsche System erstellt. Die Funktionsweise ist denkbar einfach. Ein schwerer Junge liefert das schmutzige Geld ab. Es wird dokumentiert wer wieviel Geld gebracht hat. Das Geld wird anderen Familienmitgliedern zugesteckt und die kaufen davon nette Kleinigkeiten beim Kollegen um die Ecke. Der gibt ihnen die Kleinigkeiten und eine Quittung. Das Geld wird dann vom Kollegen auf eine Bank gebracht und die Kleinigkeiten werden vom Kollegen wieder sehr günstig zurückgekauft. Und schon ist das Geld sauber verstaut in einem Banktresor. Naja, mit Geldwäsche kenne ich mich nicht sonderlich gut aus, aber auf alle Fälle hat dieser Ablauf einige Prozeduren, mit denen ein dynamischer Softwareentwickler schnell ein Programm zusammensetzen kann. Fred sollte am Geldwäschesystem eine Änderung vornehmen, die ihm von Giuseppe mit seiner väterlichen und ruhigen Stimme wie folgt erläutert wurde: „Du musst verstehen, es ist nicht leicht den schweren Jungs ihren Anteil zuzustecken. Du musst jedem Jungen das Geld abnehmen und je nach Gewicht des Jungen ihm seinen Anteil gutschreiben. Sonst ist der Junge nicht mehr glücklich und wird untreu. Und dann geht es der Familie nicht gut. Wir wollen glückliche Familienmitglieder, musst du wissen. Deine Aufgabe ist nun, eine Eingabe zu erstellen mit der ich, der Vater der Familie, die Höhe des Anteils jedes schweren Jungen festsetzen kann. Wenn der Junge brav war und sein Geld abgibt, möchte ich ihm seinen zustehenden Anteil geben. Einfache Aufgabe capische?“ Diese Aufgabe erschien Fred wirklich furchtbar einfach. „Kein Problem Giuseppe, das mach ich dir in drei Tagen!“ ,rief Fred freudig aus und schnappte sich seine Kaffeemaschine, eine Pizza und drei Kilo Schokolade und schloss sich im Keller ein.

Er überlegte kurz wie er das lösen will:

„Ich baue eine Eingabemaske mit der Giuseppe seine schweren Jungs erfassen kann. Da gibt er einen Namen, das Gewicht des Jungen und seine ihm zustehenden Prozente ein. Das Ganze speichere ich ab. Wenn Geld reinkommt, wird der Betrag dem jeweiligen schweren Jungen zugewiesen und über eine einfache Prozentrechnung bekommt der schwere Junge seinen Betrag.“ Gesagt, getan. Keine vierhundert Zeilen Code später hatte Fred sein System fertig. Er gab es Giuseppe und der war hell begeistert. „Eccelente! Ich kann endlich meine schweren Jungs sinnvoll verwalten. Jetzt habe ich aber noch ein Problem. Ich kann gar nicht sehen, welche schweren Jungs bisher bei mir arbeiten. Mach mir noch eine Anzeige um alle Jungs darstellen zu können.“ Und wieder war Fred glücklich, dass IT so einfach ist. Dreihundert weitere Zeilen Code und er lieferte eine Liste, mit der Giuseppe alle Jungs anzeigen lassen konnte. „Hm, das ist nicht schlecht. Aber ich möchte auch wissen wieviel jeder Junge im vergangenen Monat an Geld eingebracht hat.“ Also wieder in den Keller und schnell noch eine Liste basteln in der die Gelder der Jungs aufgelistet wurden. „Ja das ist schon brauchbar. Ich habe aber ein Problem. Ein paar der schweren Jungs fühlen sich ungerecht behandelt. Ich möchte jetzt wissen wann ich bei welchem Jungen die Prozentsätze angepasst habe.“ Fred setzte mittlerweile wegen der Schokoladenzufuhr an Gewicht an und glich sich allmählich an die schweren Jungs an. Sein System war nun schon recht komplex. Er musste aus dem bestehenden Code nun die Prozentsätze herausziehen und in eine Historie einbauen. Da Giuseppe ziemlich ungeduldig war, arbeitete er zwei Nächte durch und sah nun aus wie ein geübter Hacker auszusehen hat: Bleich, blutunterlaufene Augen und sich irgendwie nur noch am Kaffeebecher haltend. Die Zusammenarbeit mit Giuseppe ging ein paar Monate in diesem Modus weiter. Giuseppe stellte eine Aufgabe, Fred setzte sie um. Das Geldwäschesystem hatte nun mehrere hundert Komponenten, die Programmteile waren sehr unübersichtlich und Fred baute mehr Fehler ein, als er korrigieren konnte. Kurz vor Giuseppes Geburtstag machte Fred einen fatalen Fehler. Giuseppe wollte eine neue Funktion und Fred sagte: „Ich arbeite jetzt schon seit einem Jahr für dich. Ich möchte mehr Geld von dir haben. Ich bin der einzige der dein Geldwäschesystem versteht und bin somit sehr wichtig für deine Familie.“ Giuseppe antwortete: „Mein Junge, du verstehst das nicht ganz richtig. Niemand droht mir und niemand fordert von mir etwas. Ich verteile die Gaben, niemand sonst.“ Fred kam nicht mehr zur Arbeit und eine Woche später trat im Geldwäschesystem ein Fehler auf. Keine Gelder konnten mehr an die schweren Jungs ausgezahlt werden. Die fanden das nicht sonderlich nett und steckten Fred in Betonschuhe. Fred versank im Familienteich und konnte nicht lange genug die Luft anhalten. Er liegt vermutlich immer noch am Grund und isst heute keine Pizza mehr. Für die Familie waren die Probleme jedoch nicht gelöst. Wer sollte das Geldwäschesystem wieder zum Laufen bringen? Wie können die schweren Jungs bezahlt werden? Giuseppe organisierte drei neue Familienmitglieder die sich um das Geldwäschesystem von Fred kümmern sollten. Sie erreichten, dass das System wieder Gelder auszahlte. Aber sie klagten über diverse Probleme:

• Die Programmstrukturen sind unübersichtlich
• Der Code ist nur unzureichend dokumentiert
• Eine Architektur ist nicht festzustellen
• Jede Änderung verursacht irgendwo anders einen Fehler
• Es ist besser neue Funktionen mit neuen Datenstrukturen zu schreiben als die alten zu verwenden
• Wichtige Komponenten, wie Zugriffskontrolle und Backup, sind nicht vorhanden

Was ist hier schief gegangen? Giuseppe und seine Familie haben diverse Fehler begangen:

• Die Familie ist im Prinzip von Freds Wissen abhängig. Die erstellte Software kann als Legacy Code angesehen werden. Fred kann die Software aus begreiflichen Gründen nicht mehr warten.
• Die Familie hat sich in eine Abhängigkeit begeben, da sie nicht dafür sorgte, dass das Wissen von Fred auf andere Familienmitglieder übertragen wurde.
• Durch die nicht vorhandene Dokumentation und Architektur wird es den drei neuen Familienmitgliedern sehr schwer fallen neue Funktionen anzubringen und das System zu warten.

Fred hat ebenfalls diverse Fehler begangen:

• Offensichtlich ist es nicht sehr ratsam sich gegen Giuseppe aufzulehnen
• Er war stolz und sich nicht darüber im Klaren das jeder Mitarbeiter ersetzbar ist.
• Seine Vorgehensweise ohne Dokumentation und Betriebskonzept ein komplexes System zu erstellen, war definitiv nicht brauchbar, um das System für längere Zeit betreiben zu können.

Es ist somit nicht ratsam darauf zu vertrauen, dass die Software ohne sinnvolle Strukturen erstellt und gewartet wird. Mitarbeiter verlassen das Unternehmen, Anforderungen an bestehende Systeme ändern sich und der Betrieb einer Software muss durch geeignete Maßnahmen gesichert werden. In der nächsten Episode will ich beginnen zu erläutern, wie ein mögliches Projekt aussehen kann, um auf dem bestehenden Legacy Code aufzubauen und wie eine Migration auf einen wartbaren Code durchgeführt werden kann.

Softwareprojekte ::: von Zitronenfaltern, dicken Programmen und fools with tools

Wer glaubt das Projektleiter Projekte leiten der glaubt auch das Zitronenfalter Zitronen falten. Ich weiß zwar nicht, von wem dieser Spruch ist, aber der stimmt schon ziemlich gut. Ein weiterer Spruch den ich wirklich super finde, ist: „Die dümmsten Programmierer haben die dicksten Programme.“ Und dann ist da noch „a fool with a tool is still a fool“ Ich arbeite meistens als Zitronenfalter, habe viel mit dicken Programmen zu tun und setze die lustigsten Werkzeuge ein. Wenn ich zwischendurch von der Projektbaustelle nach Hause komme erzähle ich meiner Frau, was ich so den ganzen Tag über an lustigen, spannenden, unsinnigen und merkwürdigen Erlebnissen habe. Da ich sie jetzt schon mehrere Jahre mit all den verschiedenen Anekdoten zutexte hat sie gemeint: „Schreib doch deine Erfahrungen in einem Blog, dann können Andere auch noch damit etwas anfangen.“ Die Idee fand ich lustig. Zuerst hatte ich mir noch überlegt ob das überhaupt jemand lesen will. Dann habe ich nachgedacht, was ich überhaupt erzählen darf. Schließlich sind die Projekte in Firmen durchgeführt worden und die haben bekanntlich etwas dagegen, wenn man interne Abläufe, Schwierigkeiten und Unzulänglichkeiten im Internet veröffentlicht. Damit hier niemand zu schaden kommt (und ich nicht am Ende gegen einen Arbeitsvertrag verstoße) habe ich mir eine kleine Story überlegt, die ich hier im Blog, im Lauf der Zeit zusammensetzen werde. Sämtliche Namen, Firmen und Gegebenheiten sind frei erfunden. Die Erkenntnisse habe ich aus meinen Projekten zusammen gesammelt und die sind echt. Ich werde euch diese Episoden in loser Reihenfolge hier erzählen. Viel Spaß beim Lesen und Anwenden!