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.

IE8 und das Metatag für Internet Explorer ::: geniale Neuigkeiten von Microsoft I.

Im Artikel Webdesign mit Webstandards oder für Microsofts Internet Explorer? habe ich ja bereits über die Diskussion bezüglich des geplanten Metatags berichtet. Der Grund für dieses Tag ist, dass gewährleistet werden muss, dass auch ältere Webseiten von aktuellen Browsern, in diesem Fall, dem IE8 (Internet Explorer 8), noch korrekt angezeigt werden können. Das neue Metatag ermöglicht explizit anzugeben, ob eine Seite so angezeigt werden soll, wie sie der, wohl tatsächlich standardkonforme, IE8 darstellt oder ob sie so ausgegeben wird, wie es eine ältere Version getan hätte.

Mehr lesen

Softwareprojekte Episode 2 ::: Ein möglicher Versuch

Die Vorgeschichte und Episode 1 ::: Episode 1 ::: So klappts nicht mit der Software beschrieben die Problematik, hier folgt ein möglicher Versuch. Die drei Nachfolger von Fred lernten sich, mehr schlecht als recht, in den von Fred erzeugten Code ein und das Familienunternehmen konnte weiter operativ tätig sein. Karl, einer der drei Nachfolger, formulierte seine täglichen Problemstellungen wie folgt: „Wir nehmen den nächsten Auftrag entgegen und skizzieren den möglichen Ablauf. Dann schauen wir welche Daten wir aus dem Altsystem benötigen und versuchen, wann immer möglich, nur lesend auf die Daten zuzugreifen. Wenn das nicht geht, kopieren wir die benötigten Daten in einen neuen Datenspeicher und replizieren in regelmäßigen Abständen die Originaldaten. Auf diese Weise müssen wir am bestehenden System nichts ändern. Die neuen Datenstrukturen beschreiben wir, damit wir später noch verstehen was die Komponenten tun.“ In gewachsenen Strukturen wird häufig das bestehende System nicht weiter entwickelt, da niemand genau weiß, welche Auswirkungen eine Änderung am System haben wird. Karl und seine Kollegen setzen auf diese Vorgehensweise. Ein Problem dabei ist, dass die Systeme permanent anwachsen und nicht mehr benötigter Code stehen bleibt. Es handelt sich um den Ansatz eines Anti-Patterns das Lava Code genannt wird. Alter, nicht mehr gewarteter Code bleibt bestehen und im Fehlerfall kann nicht nachvollzogen werden was von diesem Code noch benötigt wird.

Mögliche Symptome für das Bestehen von Lava Code sind:

• Die Kosten für Wartung und Fehlerkorrektur steigen stetig an.
• Die Integration neuer Funktionalitäten wird immer komplexer und risikoreicher.
• Code ist vorhanden, der im eigentlichen Sinn keine Aufgaben mehr wahrnimmt.
• Ein Technologiewechsel wird immer unwahrscheinlicher, da das Migrieren von der alten Technologie auf die Neue zu gefährlich und teuer wäre. Viele Firmen müssen daher steinalte, nicht mehr supportete Hard- und Software einsetzen, um ihre IT-Systeme weiter betreiben zu können. Die Folge sind Systemausfälle, hohe Wartungskosten und kaum noch Weiterentwicklung der Systeme.

Die Idee, Freds suboptimalen Code einfach stehen zu lassen und neue Funktionen parallel aufzubauen, gibt Karl und seiner Gang die Möglichkeit schnell aus dem Schlammassel zu kommen. Auf Dauer werden sie sich mit dieser Vorgehensweise nicht retten, sondern ebenfalls im Familienteich enden. Da nicht jeder ins Wasser fallen soll, werde ich weitere mögliche Szenarien vorstellen.

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.