Kein Mensch würde sich heutzutage von einem Chirurgen operieren lassen, von dem er weiß, dass er sich die Hände vor der Operation nicht desinfiziert. Der Patient vertraut darauf, dass der Chirurg alle Prinzipien seiner Profession befolgt, um ihn, den Patienten, zu heilen. Auch der Chirurg würde nie auf die Idee kommen, aus Zeit- und Kostengründen das Desinfizieren der Hände vor der Behandlung zu unterlassen. Dabei war das Desinfizieren bis zum Anfang des 19. Jahrhunderts keineswegs so selbstverständlich. Der Widerstand der Mediziner war trotz bekannter Tatsachen anfangs noch sehr groß. Die Ärzte sahen damals die Desinfektionshandlung als reine Zeitverschwendung an, eine sehr überhebliche Art, mit dem Leben der Menschen umzugehen.
Auch in der Softwareentwicklung erwartet der Kunde, dass der Entwickler alle Prinzipien, Regeln und Praktiken seiner Profession mit bestem Wissen und Gewissen befolgt, um das von ihm in Auftrag gegebene Produkt zu entwickeln. Der Kunde erwartet stillschweigend vom Entwickler nicht nur, dass die Software das tut, was sie tun soll, sondern dass sie auch robust, performant, fehlerfrei, kostengünstig und viel wichtiger, für zukünftige Anforderungen leicht erweiterbar ist. Der Kunde erwartet somit, ohne es explizit zu verlangen, eine hohe innere Qualität des Codes.
Nun stellt sich die Frage für uns Entwickler: Was sind eigentlich die Prinzipien, Regeln und Praktiken in unserer Profession der Softwareentwicklung, die zu hoher innerer Codequalität führen? Oder anders gefragt: Was macht einen professionellen Softwareentwickler aus? Hat er vielleicht die meisten Zertifikate? Oder kennt er sich über viele gängige Tools bestens aus? Geht er testgetrieben vor? Ist der Entwickler mit der meisten Erfahrung automatisch der professionellste? Die Antwort auf diese Fragen scheint in der Softwareentwicklung nicht so einfach zu sein wie in der Medizin. Oder doch?
Fast jeder Entwickler kennt das Prinzip "Don’t Repeat Yourself" (DRY), dessen Befolgen – das wird sicherlich keiner bestreiten wollen – zur besseren inneren Softwarequalität führt. "Return of Investment" ist dabei erheblich. Für den Kunden ist dies allerdings nicht immer direkt ersichtlich. Er fragt sich, warum er entsprechende Refactoring-Maßnahmen bezahlen soll, wenn sie keine äußeren Änderungen mit sich bringen. Dass ein Fehler so schnell wie möglich korrigiert werden soll, um danach nie wieder in der Produktion aufzutreten, ist allerdings für ihn selbstverständlich.
Auch völlig selbstverständlich für den Kunden ist, dass das Einbauen einer neuen Funktionalität nicht mehr kostet, als eine vergleichbare Funktionalität zu Beginn der Entwicklung gekostet hat. Umso überraschter ist er natürlich, dass die Kosten für Erweiterungen mit der Zeit immer weiter steigen. Für den Einsatz von Prinzipien zur Softwareentwicklung wie das so genannte "Open Closed Principle" (OCP) bringt der Kunde allerdings kein großes Verständnis auf. Dass durch OCP der Code bei zukünftigen Änderungen und Erweiterungen jederzeit mit dem geringst möglichen Aufwand erweiterbar wäre, wird im laufenden Entwicklungsprojekt aufgrund von Zeit- und Kostendruck so gut wie immer außer Acht gelassen.
Jedem Beteiligten in der Softwarebranche – sowohl dem Entwickler als auch dem Kunden – sollte es bewusst sein, dass durch vollständige Missachtung von DRY und OCP der Code außer Kontrolle geraten kann. Die Realität aktueller Softwareentwicklung ist heute offensichtlich vergleichbar mit der Realität der Medizin am Anfang des 19. Jahrhunderts, als die Infektionen durch Missachtung der gründlichen Hygiene in den Krankenhäusern außer Kontrolle gerieten. Heute wird ebenfalls in vielen Fällen von Zeitverschwendung geredet, wenn es z. B. um die Beseitigung von Coderedundanz geht. Zumindest werden entsprechend notwendige Refactoring-Maßnahmen mit sehr geringer Priorität behandelt.
Hier sind nur zwei der bekanntesten Prinzipien, DRY und OCP, exemplarisch erwähnt. Es gibt sicherlich viel mehr sinnvolle und praktikable Prinzipien der professionellen und qualitätsorientierten Softwareentwicklung. Robert C. Martin (Uncle Bob) hat zu diesem Thema ein sehr empfehlenswertes Buch mit dem Titel "Clean Code" geschrieben.
Sehr pragmatisch und konkret gehen Stefan Lieser und Ralf Westphal, zwei Entwickler aus der .Net-Szene, vor und haben kurzer Hand ( "Nicht lang’ schnacken, Kopf in’ Nacken!") die Initiative CleanCodeDeveloper (CCD) gegründet. Stefan Lieser und Ralf Westphal haben das "Clean-Code-Buch" von Uncle Bob gelesen und suchen die Antwort auf die Frage: "Was macht eigentlich den professionellen Softwareentwickler aus?". Das Besondere an ihrer Idee liegt nicht darin, dass sie irgendwelche neuen Prinzipien und Theorien erfunden hätten. Es ist eher ihre didaktische Herangehensweise an diese Problematik und die Art ihrer Initiative. Sie gehen dabei von folgendem Leitsatz aus:
Professionalität = Bewusstheit + Prinzipien
- Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander.
- Ein professioneller Softwareentwickler hat ein inneres Wertesystem.
Dieses innere Wertesystem besteht aus
- Evolvierbarkeit
- Die Kosten für das Einbauen eines neuen Features in ein bestehendes Softwaresystem sollen nicht von der Anzahl der bestehenden Features abhängen.
- Korrektheit
- Der Code soll frei von Fehlern sein.
- Produktionseffizienz
- Das Herstellen von Software soll so kostengünstig wie möglich sein.
- Reflexion
- Jeder Entwickler, jedes Team, jedes Softwareunternehmen und schließlich die gesamte Branche soll aus seinen Fehlern lernen und sie nicht einfach ignorieren.
Um das Erlangen dieser Werte für den Entwickler zu erleichtern, haben die beiden Initiatoren der CCD eine Sammlung von bekannten Prinzipien, Regeln und Praktiken aufgestellt und sie in sieben Grade (CcdGrad) aufgeteilt. Als didaktische Besonderheit wurde jedem Grad eine Farbe zugeordnet (von schwarz über rot bis weiß). Die CcdGrade sollen keine Hierarchie des Könnens darstellen, wie es etwa bei den asiatischen Kampfsportarten der Fall ist. Ein farbiges Armband soll dem Entwickler als Hilfsmittel dienen und das Interesse der anderen Entwickler, etwa im Team oder auf Fachkonferenzen, wecken und somit die Clean-Code-Idee verbreiten.
Wer den weißen Grad erreicht hat, arbeitet ständig an allen Facetten des Wertesystems. Da solche gleichschwebende Aufmerksamkeit jedoch schwer herzustellen ist, wird erwartet, dass der weiße Grad nach einiger Zeit wieder mit der Arbeit im Gradesystem von vorne beginnt. Indem der Entwickler wieder beim roten Grad beginnt, kann er sich in seiner täglichen Praxis etwas mehr auf einen weiteren Ausschnitt des Wertesystems konzentrieren.
So entsteht eine endlose Spirale, die der Professionalität des Entwicklers sehr zu Gute kommen kann. Er kontrolliert sich dabei in erster Linie selbst. Eine äußere Kontrolle stellt sich durch die Reflexion seiner Arbeit in der Gemeinschaft ein. Das ergibt eine gesunde Mischung von innerer und äußerer Bewertung der Entwicklung.
Weitere Informationen sind auf der Seite der CCD zu finden. Ein Besuch der Webseite lohnt sich auf jeden Fall. Wer weiß, vielleicht reicht ein kurzer Besuch, um dort für immer hängen zu bleiben.
