Clean Code Developer in Brownfield-Projekten
Wird ein Projekt "auf der grünen Wiese" gestartet, kann ein Team die Prinzipien der "Clean Code Developer"-Initiative von Anfang an einsetzen. Doch was ist zu tun, wenn ein Projekt längst läuft? Wo liegen die Herausforderungen bei solchen Brownfield-Projekten?
- Stefan Lieser
- Ralf Westphal
- Alexander Neumann
Wird ein Projekt "auf der grünen Wiese" gestartet, kann ein Team die Prinzipien und Praktiken der "Clean Code Developer"-Initiative von Anfang an im Alltag einsetzen. Das ist oft Herausforderung genug. Doch was ist zu tun, wenn ein Projekt längst läuft? In diesen sogenannten Brownfield-Projekten wurde möglicherweise gegen einige der Prinzipien verstoßen. Wo liegen jetzt die Herausforderungen?
Die Qualität heutiger Software ist oft schlecht. Nicht dass Entwickler keine Funktionen ausliefern, nein, die innere Qualität der Implementierung ist gemeint. Das lässt sich nicht immer mit Zeit- oder Budgetdruck erklären. Oft ist es die innere Struktur der Software, die nicht angemessen ist. Das ist auf allen Ebenen zu beobachten: Es mangelt an einer angemessenen Architektur, Komponentenorientierung fehlt meist ganz, und selbst bei den kleinen Einheiten wie Klassen und Methoden werden grundlegende Prinzipien nicht beachtet. In der Folge sind vor allem Änderungen und Ergänzungen an solcher Software enorm teuer, und die Fehlerrate bleibt über einen langen Zeitraum hoch.
Das Wertesystem
Herausforderung Brownfield
Im Rahmen einer Artikelserie beleuchten die Initiatoren der "Clean Code Developer"-Initiative, Stefan Lieser und Ralf Westphal, die Herausforderungen an Clean Code Developer in Brownfield-Projekten.
- Teil 1: Was sind die Probleme?
- Teil 2: Das Sicherheitsnetz aufspannen
- Teil 3: Das Sicherheitsnetz erweitern
- Teil 4: Komplexität bewältigen durch Partitionierung
- Teil 5: Explizite Architektur als Ziel für Refaktorisierungen
- Teil 6: Partitionen durch Refaktorisierung evolvierbar machen
- Teil 7: Alle Veränderung in kleinen Schritten durchführen
Die "Clean Code Developer"-Initiative ist angetreten, daran etwas zu ändern. Sie hat dazu ein Wertesystem aufgestellt, das zu mehr Softwarequalität führen soll. Die Werte sind Evolvierbarkeit, Korrektheit, Produktionseffizienz und Reflexion.
Evolvierbarkeit: Bei ihr geht es um die Frage, wie leicht sich eine Software an geänderte Rahmenbedingungen anpassen beziehungsweise erweitern lässt. Oft setzt man das mit dem Begriff Wartbarkeit gleich. Wartung gibt es bei Software im engeren Sinne jedoch nicht. Nur beim Betrieb von Software kann man von Wartung sprechen. Es lässt sich beispielsweise vorausschauend sicherstellen, dass eine Datenbank immer über ausreichend freie Kapazität verfügt. In der Entwicklung der Software ist der Begriff Wartung jedoch nicht angemessen. Die Analogie zur Wartung, die man aus der Mechanik kennt, greift hier nicht: Regelmäßig nach dem Ölstand zu schauen funktioniert in der Software nicht.
Da Software sich nicht in einem großen Wurf entwickeln lässt, sondern ein iteratives Vorgehen unabdingbar ist, ist die Evolvierbarkeit schon während des Erstellungsprozesses erforderlich.
Korrektheit: Selbstverständlich muss Software korrekt sein – und das in funktionaler und nichtfunktionaler Hinsicht. Funktionale Anforderungen beziehen sich auf die eigentlichen Funktionen einer Software. Hinzu kommen die nichtfunktionalen wie Anforderungen an Laufzeitverhalten oder sparsamer Umgang mit Ressourcen. Sind alle umgesetzt, ist die Software korrekt.
Das scheint so selbstverständlich, dass es selten hinterfragt wird. In der Praxis ist die Korrektheit jedoch ein großes Problem. Vor allem nach Änderungen oder Ergänzungen treten häufig Probleme auf, die in vorhergehenden Versionen schon überwunden galten.
Produktionseffizienz: Am Ende muss der Kunde alle Anstrengungen, die Entwickler zur Einhaltung der Werte Evolvierbarkeit und Korrektheit unternehmen, bezahlen. Deshalb sind alle Schritte, die zur Einhaltung der Werte führen, effizient durchzuführen. Der Begriff Produktionseffizienz zielt darauf ab, den gesamten Prozess der Softwareerstellung so effizient wie möglich durchzuführen, ohne dabei die anderen Werte zu vernachlässigen. Damit ist die Produktionseffizienz ein Gegenpol zu den anderen Werten, der dafür sorgt, dass man am Ende Zeit und Kosten angemessen berücksichtigt.
Reflexion: Bei der Softwareentwicklung geht es oft um das Abwägen von Alternativen. Um auswählen zu können, müssen Letztere bekannt sein. Nach der Entscheidung für eine der Alternativen muss man zurückschauen, um zu prüfen, ob die Entscheidung die richtige war. Ohne diese Reflexion gibt es keine Weiterentwicklung. Selbst das Überprüfen der Ergebnisse eines Testlaufs bedeutet Reflexion. Auch sie ist notwendig, um herauszufinden, ob die Software korrekt ist. Sie sollte damit auf allen Ebenen der Softwareentwicklung anzutreffen sein.
Die Bausteine: Prinzipien und Praktiken
Da die vier Werte zu abstrakt für eine direkte Umsetzung sind, hat die "Clean Code Developer"-Initiative mehr als 40 Bausteine zusammengetragen, die in Prinzipien und Praktiken unterteilt sind. Jeder Baustein trägt etwas zu einem der Werte bei. So unterstützt beispielsweise das Prinzip "Don't Repeat Yourself" (DRY) die Evolvierbarkeit, weil Code, der nur einmal vorkommt, sich leichter anpassen lässt als mehrere, möglicherweise sogar noch leicht modifizierte Kopien. Ein Praxisbeispiel ist das Refaktorisieren, das auch die Evolvierbarkeit unterstützt. Kein Entwickler ist in der Lage, beim ersten Herunterschreiben sofort den optimalen Code abzuliefern. Das Refaktorisieren dient also dazu, Code immer wieder zu verbessern.
