Clean Code Developer aus Unternehmenssicht – ein Anwenderbericht

Inhaltsverzeichnis

Den Begründern von Clean Code Developer war es mit ihrer Anfang 2009 gestarteten Initiative wichtig, jenen Minimalkonsens herauszufiltern, der sich als Richtschnur für eine gesteigerte Professionalität in der Softwareentwicklung begreifen lässt. Das Unternehmen generic.de entwickelt seit rund zwei Jahren ausschließlich nach den Prinzipien und Praktiken des Clean Code Development. Ein Erfahrungsbericht zu den Auswirkungen auf Firma, Mitarbeiter und Kunden.

Der Begriff "Software-Ingenieur" ist nicht nur im IT-Umfeld eine gängige Bezeichnung für den Beruf des Softwareentwicklers. Er impliziert, dass es sich um einen für die Softwarebranche wissenschaftlich und technisch ausgebildeten Spezialisten handelt. Tatsächlich fehlt eine für alle Software-Ingenieure allgemeingültige Norm, nach der Produkte entwickelt werden. Um professionell zu arbeiten, qualitativ hochwertige Arbeit zu leisten und die Ergebnisse vergleichbar zu machen, empfehlen sich jedoch einheitliche Werkzeuge und Methoden, die für jeden Entwickler verbindlich sind. Besonders wenn es um die innere Qualität von Software geht, die sich nicht zwangsläufig an der äußeren Softwarequalität bemessen lässt, bilden ein strukturierter Entwicklungsprozess und sauberer, verifizierbarer Code die Grundlage für hochwertige Software. generic.de führte daher 2009 die Prinzipien des von Stefan Lieser und Ralf Westphal initiierten Clean Code Developer (CCD) ein, um unternehmensweit ein einheitliches Regelwerk zu schaffen.

Mehr Infos

Clean Code Developer

Clean Code Developer umfasst ein System von Bausteinen (Prinzipien, Regeln und Praktiken), deren Anwendung die Qualität von Software erhöhen soll. Diese Bausteine haben die CCD-Initiatoren Ralf Westphal und Stefan Lieser nicht erfunden, aber im Rahmen einer ganzheitlichen Initiative zusammengeführt. Um das Erlernen der Bausteine zu erleichtern, haben sie spezifische Lernmodule (Grade) definiert und im sogenannten "CCD-Wertesystem" festgehalten.

Das CCD-Wertesystem unterteilt sich in Lerngrade, anhand derer die jeweiligen CCD-Prinzipien und -Praktiken geübt werden. Insgesamt gibt es sechs Grade, die unterschiedlichen Farben zugeordnet sind. Beginnend beim roten Grad kann jeder Entwickler die einzelnen Entwicklungsstufen nach und nach bearbeiten oder auch quer in die Lernmodule einsteigen. Ziel des Lernprozesses ist es, sich kontinuierlich mit den Bausteinen zu befassen. Die Auseinandersetzung mit CCD versteht sich daher als Kreislauf: Wer alle Grade bearbeitet hat, beginnt wieder von vorn.

Die Grundlage für diese Entscheidung bildete die zugehörige Methodik, die auf die innere Qualität von Software abzielt und im Hinblick auf saubere Programmierung bei jedem einzelnen Entwickler und dessen Eigeninitiative ansetzt. Bereits zu Beginn wurden durch die Komplexität des Vorhabens alle Beteiligten in den Entscheidungsprozess eingebunden. Das sollte auch für eine hohe Motivation für das gemeinsame Projekt sorgen. Dieses Vorgehen war essenziell, da die grundlegende Umstellung nicht von der Unternehmensführung durchzusetzen, sondern von allen Entwicklern gleichermaßen mitzutragen und umzusetzen war.

Überschaubare Einführung

Vom Entschluss bis zur Einführung von CCD verging über ein halbes Jahr. In einem ersten Schritt machten sich die Softwareentwickler über Schulungen mit der neuen Methode vertraut. Dabei erwies sich das Aufbrechen alter Strukturen als anspruchsvoll, da durch das Fehlen eines einheitlichen Ausbildungsstandards jeder Entwickler zunächst über seine eigene Programmierweise verfügte. Je nachdem, welche Prinzipien und Praktiken der Mitarbeiter im Vorfeld erlernt hatte, ob er etwa eine Universität besucht oder Erfahrung in einem anderen Unternehmen gesammelt hatte, entpuppte sich der CCD-Lernprozess als mehr oder minder komplex.

Als Herausforderung gestaltete sich zudem der Einsatz der neuen Methodik im laufenden Projektgeschäft: Selbst erfahrenen Softwareentwicklern vermittelte die fundamentale Änderung der Arbeitsweise eingangs eine Art "Anfängergefühl". Das lag nicht zuletzt am mit ihr verbundenen, wenn auch kurzfristigen Absinken der Produktivität und der Tatsache, dass die Anwendung der neuen Praktiken nur sukzessive durchführbar war. Es erforderte viel Disziplin und eine große Lernbereitschaft eines jeden Entwicklers, sich an die neue Herangehensweise zu gewöhnen.

Nach der Einarbeitungsphase bildete sich allerdings ein Gefühl der Sicherheit und Überzeugung, mit CCD einen ersten wichtigen Schritt in Richtung langfristiger Qualitäts- und Effizienzsteigerung vollzogen zu haben. Als besonders hilfreich bei der Auseinandersetzung mit den neuen Techniken erwies sich das zyklusartige Baukastenprinzip des CCD-Regelwerks. Es gestattet jedem Entwickler trotz der allgemeinen Komplexität des Umgewöhnungsprozesses einen praktikablen Einstieg. Auf Basis voneinander unabhängiger Lernmodule erhielt jeder Entwickler von Anfang an die Möglichkeit, sich flexibel weiterzubilden.

Damals wie heute werden die Prinzipien und Praktiken geübt, die thematisch nach farbig gekennzeichneten Graden geordnet sind. Dabei ist es jedem Entwickler selbst überlassen, mit welchem Thema er sich befassen möchte. So trainiert ein Mitarbeiter, der sich mit dem gelben Grad auseinandersetzt, das Schreiben von besser testbarem Code. Durch ständiges Prüfen der eigenen Leistung stellt er sicher, dass er die beschriebenen Methoden verstanden hat und umzusetzen weiß. Dabei spielt es grundsätzlich keine Rolle, auf welcher Entwicklungsstufe sich der Entwickler gerade befindet. Wichtig sind lediglich der kontinuierliche Verbesserungsprozess und die Tatsache, dass durch CCD alle Mitarbeiter in ein System eingebunden sind, in dem einheitliche Regeln gelten. Der Ansatz wurde unternehmensweit positiv angenommen und ließ sich dauerhaft sowohl für Senior- als auch für Junior-Entwickler als verbindliche Weiterentwicklungsgrundlage etablieren.