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.