Die Clean Code Developer Grade

Clean Code Developer ist man nicht einfach, sondern wird es. Es geht nämlich nicht darum, ein paar Regeln auswendig zu lernen, sondern das CCD-Wertesystem wirklich zu verinnerlichen. Das braucht Zeit und Übung. Deshalb haben wir das CCD-Wertesystem in Stufen unterteilt, die man als Entwickler eine nach der anderen erklimmt. Allerdings sehen wir den gesamten Prozess als Kreis: wer alle Grade bearbeitet hat, beginnt wieder von vorne.

Jeder Entwicklungsstufe ist eine Farbe zugeordnet. Und wer an sich als Clean Code Developer auf einer Stufe arbeitet, der trägt ein CCD Armband als Zeichen seines Willens, sie zu meistern. Anders als im Judo-Sport entspricht die Farbe also nicht einem erreichten Grad, sondern dem in Arbeit befindlichen.

Schwarzer 0. Grad

Den schwarzen Grad hat jeder, der sich noch nicht auf den Weg gemacht hat. Ein schwarzes Armband signalisiert deshalb nur, dass man sich für CCD interessiert. Man kann es tragen, wenn für den ersten richtigen Grad noch nicht alle Voraussetzungen erfüllt sind.

Roter 1. Grad

Der wirkliche Weg zum Clean Code Developer beginnt mit dem roten Grad. Mit dem roten Grad setzt die Übungspraxis ein. Er enthält deshalb nur Elemente des CCD-Wertesystems, die absolut unverzichtbar sind. Der Einstieg soll so leicht wie möglich sein. Auf dieser Stufe geht es deshalb noch nicht so sehr um Softwareentwicklungsprinzipien, als vielmehr um den Aufbau einer fundamentalen Haltung zur Softwareentwicklung und zum Clean Code Developer.

Oranger 2. Grad

Nachdem im roten Grad die Grundlagen für den Prozess der kontinuierlichen Verbesserung geschaffen wurden, geht es im orangen Grad darum, einige fundamentale Prinzipien auf den Code anzuwenden und erste Erfahrungen mit dem Mittel Nr. 1 zur Produktivitätssteigerung zu gewinnen: der Automatisierung von Abläufen. Da nur korrekter Code guter Code ist, dient die Automatisierung der Korrektheitsprüfung. Es geht also nicht um eine nice-to-have Eigenschaft von Code, sondern um seine Essenz.

Gelber 3. Grad

Der gelbe Grad steht ganz im Zeichen automatisierter Tests. Beim orangen Grad ging es noch um die von außen ansetzbaren Integrationstests. Für sie war nicht unbedingt ein Eingriff in den Code nötig. Ab dem gelben Grad allerdings geht es nicht mehr ohne Tests unter der Oberfläche. Und nicht nur das: getestet werden sollen die kleinstmöglichen Einheiten, nicht nur funktionale Durchstiche. Das bedeutet ein Änderung der Codierungspraxis, denn sonst lassen sich einzelne Klassen nicht isoliert, d.h. unabhängig von genutzten Diensten prüfen. Deshalb gehören zum gelben Grad auch objektorientierte Prinzipien, denn nur mit ihnen ist eine Ablösung von zu testendem Code von seinem „Untergrund“ möglich.

Grüner 4. Grad

Im grünen Grad geht es weiter mit der Automatisierung. Die ist einfach der Schlüssel zur Produktivität und Reaktionsfähigkeit. Nur wenn maximal viele Tätigkeiten in der Softwareentwicklung automatisiert sind, kann sich der CCD auf das Wesentliche konzentrieren: die Implementation von Kundenanforderungen. Ohne Automatisierung hängt die Entwicklung sonst oft an Kleinigkeiten – das kostet Zeit. Korrektheitsprüfungen und Releases sind dann mehr Strafe denn Mittel zum Erfolg. Nach der Automatisierung der Tests steht jetzt allerdings die Produktion auf dem Plan. Code am Entwicklerarbeitsplatz zu testen, ist eine Sache. Ihn auf einem unabhängigen Rechner erfolgreich zu übersetzen und zu testen, eine andere. Nur so lassen sich mehr oder weniger subtile Abhängigkeiten von den einzelnen Entwicklerarbeitsplätzen finden. Garniert wird diese Praxis dann noch mit weiteren Prinzipien zur Codestrukturierung und einem Werkzeug für bessere Architekturen.

Blauer 5. Grad

Mit dem blauen Grad geht es in die Zielgerade des CCD-Wertesystems. Die Automatisierung ist noch einen Schritt weiter zu treiben. Nach Übersetzung und Test steht jetzt das Deployment auf dem Programm. Vor allem geht es im blauen Grad aber nun um Aspekte der Softwareentwicklung jenseits von Code und Tools: CCD kümmern sich nicht nur um gute Strukturen im Kleinen, sondern planen sie von vornherein im Großen. Es geht also um Architektur. Da wir uns jedoch bewusst sind, dass keine Planung eine perfekte Lösung definieren kann, gehört nicht nur zur Architektur, sondern zur Softwareentwicklung insgesamt auch ein passendes Vorgehensmodell. Das ist iterativ und soll während der Arbeit am blauen Grad nun auch eingeübt werden.

Weißer 6. Grad

Im weißen Grad fließen alle Prinzipien, Regeln und Praktiken zusammen. So wie im weißen Licht alle Farben enthalten sind, so enthält der weiße Grad alle anderen Grade. Auf der Ebene des weißen Grades arbeitet ein CCD nur, wenn er ständig das ganze CcdWertesystem im Blick hat. Das macht klar, dass nur wirklich fortgeschrittene Softwareentwickler mit mehreren Jahren Erfahrung und in einer geeigneten Umgebung mit dem weißen Grad arbeiten können.

Bedeutung der Grade

Die Grade drücken keinen Wert aus. Wer am blauen Grad arbeitet ist nicht „besser“ oder „weiter“ als jemand, der am orangen Grad arbeitet. Die Grade sind nur ein didaktisches Hilfsmittel, um die Gesamtheit des Wertesystems „einfacher verdaubar“ zu machen. Die vielen Bausteine lassen sich schlicht in kleinen Happen besser aneignen, als in einem Anlauf.

Deshalb ist es uns auch wichtig, dass jeder Interessent mit dem roten Grad beginnt. Aus didaktischen Gründen ist es der beste Einstieg – auch wenn man meint, man würde doch auch schon in der täglichen Arbeit andere Werte umsetzen. Denn unabhängig von der heutigen Projektpraxis ist es sicherlich neu, sich so bewusst mit Prinzipien und Praktiken auseinanderzusetzen. Insbesondere die tägliche Reflektion darüber ist wahrscheinlich noch nicht Gewohnheit. Um sie im Kontext „einfacher“ Bausteine zu üben, eignet sich dann der rote Grad.

Auch wenn wir verstehen, dass jeder, der das Wertesystem zum ersten Mal sieht, abhaken will, was er davon schon beherzigt, so ist das letztlich unerheblich. Die bewusste Praxis im Rahmen des Wertesystems ist immer neu – und sollte auch wer meint, er „verdiene“ eigentlich den weißen Grad, beim roten Grad beginnen. Es geht eben nicht um „Verdienst“, sondern um Iterationen und kleine Happen. Grade sind Gucklöcher auf das große Ganze.

Wer das erste Armband bestellt, bestelle also am besten das rote Armband.

Fortbildung

Das Wertesystem und die Bausteine mögen starr aussehen, wie in Stein gemeißelt. Das ist es aber nicht. Es ist immer nur vorläufig, bis wir bzw. die Community meint, dass etwas verändert werden sollte. Noch viel stärker im Fluss ist jedoch die Welt der Werkzeuge und Materialien, auf die das Wertesystem anzuwenden ist. Programmiersprachen, IDEs, Frameworks, Plattformen, Serverprodukte verändern sich ständig, kommen hinzu, fallen weg. Tendenziell wird das, was potenziell gewusst und gekonnt werden könnte immer nur mehr, viel mehr. Früher war man gut bedient mit einer Programmiersprache und deren Standardbibliothek. Heute reicht das schon lange nicht mehr.

Da Professionalität bedeutet, informierte Entscheidungen zu treffen, kommt der CCD nicht umhin, sich ständig fortzubilden. Wahrscheinlich ist die Softwareentwicklung sogar die Branche mit der größten Notwendigkeit dazu. Aspekte der Fortbildung sind daher Bestandteile mehrerer Grade (Orange, Gelb, Grün). Damit wollen wir deutlich machen, dass Fortbildung immer ein Thema ist, aber eben auch einer Entwicklung folgen muss. Von 0 auf 100 bei der Fortbildung in einem Grad ist nicht möglich. Nicht nur Softwareentwicklung braucht Übung, auch die Fortbildung will gelernt sein.

In den Graden geht es aber nur um unterschiedliche Fortbildungsformen (Lesen, Networking, Veröffentlichen). Wieviel Zeit ein CCD für sie aufwenden sollte, geben sie nicht vor. Der Grund: das ist aus unserer Sicht nicht formspezifisch. Fortbildung sollte unabhängig von der Form mindestens 20% der Arbeitszeit ausmachen.

Ja, das meinen wir ehrlich. 20% der Arbeitszeit sollte Fortbildungszeit sein. Pro 5-Tage-Woche also 1 Tag nur für die Fortbildung. Nicht weniger. Google macht vor, dass das funktioniert: „Das heißt, jeder Mitarbeiter darf 20 Prozent seiner Arbeitszeit mit Projekten verbringen, die nicht direkt mit seiner Aufgabe zu tun haben. Das wird nicht kontrolliert.“ (Quelle: Interview mit Nordeuropa-Chef Phillip Schindler von Google im Hamburger Abendblatt, 7.11.2007)

20% klingt dennoch sehr viel. Aber keine Angst, Fortbildung ist gar nicht so schlimm für den, der sie bezahlen soll. Denn Fortbildung ist einiges nicht, was man zunächst damit verbindet:

Fortbildung ist kein Urlaub
Fortbildung ist keine Abwesenheit vom Arbeitsplatz
Fortbildung bedeutet nicht, dass kein Nutzen für Projekte gestiftet wird
Fortbildung braucht nicht zwangsläufig ein hohes Budget für Schulungen oder Software

Fortbildung bedeutet vor allem Spielraum für Fehler. Anders formuliert: Während 20% der Arbeitszeit sollte ein professioneller Softwareentwickler keine Angst vor Fehlern haben. Das bedeutet im Extremfall, dass die 20% ohne direkten Gewinn für ein Projekt sind. Vergleichen Sie die Fortbildung mit der Übungszeit eines Musikers. Auf der Bühne muss der Musiker performen, tunlichst ohne Fehler. Um sein Können auf gleichem Stand zu halten oder sogar zu verbessern, muss ein Musiker jedoch üben. Dabei sind Fehler ausdrücklich zugelassen, da sonst keine Weiterentwicklung möglich wäre. Es bedarf also zweier unterschiedlicher „Betriebsarten“.

Erst auf der Basis solchen Spielraums für Fehler geht es darum, wie der ausgefüllt werden könnte. Einziger Anspruch an mögliche Inhalte sollte sein, dass ein Bezug zur Arbeit erkennbar ist. Wer die 20% Spielraum für die private online Immobiliensuche oder Sport im unternehmenseigenen Fitnesscenter nutzt, bildet sich nicht wirklich fort.

Beispiele für Fortbildungsinhalte sind:

Studium von Fachpublikationen (online/offline, Blog/Zeitschrift/Buch/Video)
Ausprobieren von Gelesenem
- Technologien
- Verfahren
- Werkzeuge
Besuch von Fachveranstaltungen (Schulung, Konferenz, Community-Event)
Publikation eigenen Fachwissens
- in unternehmenseigenen Medien (z.B. Projekt-Wiki)
- auf öffentlichen Plattformen (Blog, Zeitschrift, Buch, Fachkonferenz)

Ob Lektüre, Experimente oder Publikationen direkt mit einem Projekt im Zusammenhang stehen, ist nachrangig. Sie können, müssen aber nicht. Ein CCD kann eine Technologie mit Blick auf das Firmenprojekt evaluieren oder nur aus allgemeinem Interesse. Nutzen für das Projekt entsteht in beiden (!) Fällen. Einmal unmittelbar, einmal mittelbar. Denn jede Kenntnis einer Technologie oder eines Verfahrens, auch wenn der Einsatz im Projekt noch nicht absehbar ist, erweitert den Horizont, macht also erfahrener, optionenreicher.

Hinweis für Entscheider: Entwickler, die sich kontinuierlich fortbilden, stellen einen Wert dar. Sie sind erfahrener, innovativer, flexibler. Das dient Ihren Produkten.

Hinweis für Softwareentwickler: Wer sich fortbildet wird wertvoller. Er gewinnt an Erfahrung, ist nicht in einer Nische festgenagelt, gibt keine Angriffsfläche für Hype ab. Das dient der „Employability“.

Übungspraxis

Clean Code Developer zu werden braucht Zeit. Wir glauben, dass es pro Grad mit nicht weniger als 21 Tagen getan ist. Denn 21 Tage (oder 3 Wochen) – so sagt die Psychologie – brauchen Menschen, um Neues oder allgemein Veränderungen als Gewohnheiten in ihr Leben zu integrieren.

Wer auf einer CCD-Stufe arbeitet, soll deshalb so vorgehen: Am Abend jedes Arbeitstages reflektiert der CCD darüber, ob er die Prinzipien seines Grades (und der darunter liegenden) eingehalten hat. Wenn ja, behält er das Armband an dem Arm, an dem es ist. Wenn nein, wechselt er das Armband jedoch zum anderen Arm! Das ist wichtig, denn durch den Akt des Wechselns macht sich der Entwickler bewusst, dass er und welche Prinzipien er noch besser verinnerlichen muss.

Sobald ein Entwickler dann auf einer Stufe 21 Tage ohne Wechseln des Armbands gearbeitet hat, kann er den Grad als gemeistert ansehen, zum nächsten fortschreiten und dessen Armband überstreifen.

Natürlich gibt es keine formale Kontrolle, ob während eines Tages wirklich alle Prinzipien beachtet worden sind. Wir stellen es also der Ehrlichkeit jedes Entwicklers sich und der CCD-Community gegenüber anheim, darüber nach bestem Wissen und Gewissen zu urteilen. Da kein Grad „besser“ oder „schlechter“ ist als ein anderer, lohnt sich Mogelei ohnehin nicht. Wir gehen davon aus, dass Entwickler, die den weißen Grad gemeistert haben, wieder beim roten Grad beginnen. So demonstrieren sie ihre Überzeugung, dass Softwareentwicklung ständiges Lernen ist.