1. März 2018 von Markus Wagner
Clean Code Developer Teil 2
Im ersten Teil meines Blog-Beitrags habe ich euch das Thema Clean Code Developer (CCD) sowie dessen Vorteile näher erklärt. Jetzt möchte ich euch zeigen, welche Möglichkeiten es gibt, um die Prinzipien und Praktiken von CCD schrittweise in die tägliche Arbeit eures Entwicklungsteams einzubinden.Wie funktioniert CCD?
Ein kurzer Rückblick: Beim CCD handelt es sich um eine Sammlung von Prinzipien und Praktiken, die in verschiedene Grade unterteilt sind. Diese Grade werden schrittweise und getreu der agilen Vorgehensweise iterativ durchwandert. Falls ihr euch das Ganze nochmal vor Augen führen möchtet, werft doch einen kurzen Blick in den ersten Teil meines Beitrags.
Zurück zur Frage, wie CCD eigentlich funktioniert. Zunächst einmal habt ihr unterschiedliche Vorgehensweisen und Schulungsmodelle zur Auswahl, um eure Entwickler auf die Prinzipien eines Grades zu fokussieren. Es ist allerdings abhängig vom Projektmodell und der Struktur eines Unternehmens. Die Grade können rein individuell oder mit einer organisierten Vorgehensweise – etwa als Team − beschritten werden. CCD beschränkt sich dabei auf keine spezielle Programmiersprache. Neben Java und C++/C# ist die Vorgehensweise von CCD mittlerweile auch für weitere Sprachen − etwa JavaScript, Python oder PHP − denkbar. Im Folgenden möchte ich euch zeigen, wann ihr die individuelle und wann die organisierte Methode wählen solltet.
1. Individuelle Methode
Die individuelle Methode eignet sich vor allem für sehr kleine Projekte. Hier seid ihr selbst dafür verantwortlich, die Grade während der täglichen Arbeit einzuhalten. Ihr fangt einfach mit dem roten Grad an und prüft selbst, ob ihr die Prinzipien und Praktiken einhalten könnt. Natürlich müsst ihr ein gewisses Maß an Selbstdisziplin mitbringen, denn gerne werden manche Prinzipien aus Zeitgründen oder Bequemlichkeit missachtet. Daher rate ich euch zu einem Code Review durch weitere Entwickler − sofern es die Projektgröße zulässt. Ich empfehle euch pro Grad eine Dauer von mindestens 21 Tagen. Damit wird sichergestellt, dass der Inhalt eines Grades „in Fleisch und Blut“ übergehen kann. Der Vorteil von CCD wird vor allem dann sichtbar, wenn ihr in ein größeres Projekt wechselt und auf weitere Clean Code Developer trefft. Hier werdet ihr sofort die Gemeinsamkeiten im Programmierstil, aber auch im Qualitätsbewusstsein bemerken.
2. Organisierte Methode
Die organisierte Methode bietet sich für größere Entwicklungsteams an, die längerfristig an einem Projekt arbeiten − vor allem bei agilen Vorgehensmodellen wie Scrum, Kanban und Co., da hier die iterativen und reflektierenden Eigenschaften von CCD optimal unterstützt werden. Wie bereits im ersten Teil beschrieben, sollten eure Teams ein gemeinsames Mindset hinsichtlich der Architektur und Qualität entwickeln, da nicht alle Entwickler einen ähnlichen Wissenstand bezüglich einer sauberen Code-Architektur und -Qualität besitzen. Daher solltet ihr der Teamleistung gegenüber den individuellen Leistungen den Vorrang geben. Ihr könnt das Ganze als eine gemeinsame und kontinuierliche Schulung betrachten, die während der täglichen Arbeit durchgeführt wird.
Meiner Erfahrung nach führt die Einführung von CCD in einem Entwicklungsteam zu folgender Vorgehensweise: Euer Entwicklungsteam wird sich gemeinsam dazu verpflichten, die Grade des CCD zu durchschreiten. Ich empfehle euch auch hier eine Länge der Iterationen von mindestens 21 Tagen. Solltet ihr in eurem Projekt die weitverbreitete Sprintlänge von zwei Wochen nutzen, läuft eine CCD-Iteration am besten über zwei Sprints. Vorzugsweise startet ihr mit einer Iteration des schwarzen Grades, denn hier werden aktiv noch keine Prinzipen und Praktiken befolgt. Diese Iteration nutzt ihr, um euch auf den roten Grad vorzubereiten. Bewährt haben sich auch kurze, einführende Schulungen zu den Prinzipien. Während einer Iteration sind damit zwei Aufgaben auszumachen, die zeitgleich berücksichtigt werden können: Einerseits beachtet ihr die Prinzipien und Praktiken des Grades in dem ihr euch aktuell befindet, andererseits bereitet ihr euch auf den nächsten Grad vor. Ich nenne diese beiden Aufgaben den „Planning Stream“ und den „Practice Stream“, die ich euch nun näher vorstellen möchte:
Planning Stream
- Hier werden die einzelnen Prinzipien und Praktiken durch Schulungen vorbereitet.
- Inhaltlich sollten die Schulungen Begriffserklärungen und Zielsetzung der Praktiken und Prinzipien beinhalten.
- Die Schulungen sollten von verschiedenen Entwicklern vorbereitet und abgehalten werden.
- Verweise auf den Legacy Code, der diesen Prinzipien und Praktiken widerspricht, sind hilfreich, um einen negativen Fall zu veranschaulichen. Lösungen sollten aber erst im Practice Stream ausgearbeitet werden.
Practice Stream
- Ihr prüft vor dem Check-In anhand einer Liste, ob alles eingehalten wurde.
- Wenn ein Prinzip verletzt wurde, wird dies im Check-In-Kommentar begründet.
- Der Reviewer prüft Anhand der Liste das Check-In und validiert die Begründung bei einer Verletzung.
- Sollte die Begründung nicht ausreichend sein oder gar keine Begründung vorliegen, nehmt ihr mit dem Entwickler Kontakt auf und sucht zusammen eine Lösung.
- Der Ausgang ist entweder ein den Prinzipien entsprechendes Check-In oder aber eine durch zwei Personen begründete Ausnahme. Wichtig ist die Begründung im Kommentar, denn damit wird ersichtlich, dass es sich um eine bewusste Entscheidung handelt.
Im einem Daily Standup solltet ihr im Team immer kurz reflektieren, ob es Verletzungen gegen die Prinzipien gab. Damit stellt ihr sicher, dass bisher nur „Clean Code“ in die produktive Code-Basis eingecheckt wurde. Die Check-Ins sporadisch auf die Einhaltung der aktuellen Prinzipien zu prüfen, könnte beispielsweise die Aufgabe des Softwarearchitekten oder Lead-Entwicklers sein.
Einige der Prinzipien könnt ihr im Java-Umfeld mit Hilfe von statischen Code-Analyse-Tools abbilden – etwa Sonar, PMD, Checkstyle oder Findbugs. Diese Tools sind aber nur hilfreich, wenn sie auch wirklich beachtet werden. „SuppressWarning“-Annotationen solltet ihr sparsam einsetzen und immer mit einer Begründung kommentieren. Aber auch im NET-Umfeld gibt es einige Tools, die eure Bemühungen unterstützen können. NDepend, Simian oder SourceMonitor sind hier einige Beispiele.
Aufstieg in den nächsten Grad
Ein Aufstieg in den nächsten Grad sollte nur stattfinden, wenn die Vorgehensweise eingehalten wurde. Im Gegensatz zur individuellen Methode steigt euer Team nur gemeinsam in den nächsten Grad auf. Sollten jedoch unbegründete Verletzungen gegen den Inhalt eines Grades wahrgenommen werden, so wird derselbe Grad für eine weitere Iteration durchlaufen. Ein Aufstieg ist somit eine Belohnung und zeigt die qualitativen Bemühungen des ganzen Teams. Zudem wird auf diese Weise sichergestellt, dass eure Entwickler mit ihren Bemühungen in die gleiche Richtung gehen. Ihr werdet bemerken, wie schnell sich eure Code-Basis in Richtung Clean Code bewegt, sobald ihr zusammen die Prinzipien von CCD berücksichtigt.
Ein Wechsel innerhalb des Teams – etwa durch neue Mitarbeiter – führt natürlich dazu, dass sich nicht mehr alle Entwickler im gleichen Grad befinden. Am einfachsten ist es, wenn ihr geschlossen als Team wieder im roten Grad beginnt. Damit kann ein neuer Mitarbeiter schnellstmöglich in das Thema CCD eingeführt werden und profitiert von den Erfahrungen, die ihr als Team in den vorherigen Iterationen gemacht habt.
Ist der nächste Grad erreicht, bedeutet es nicht, dass ihr andere Grade, die ihr bereits in vorherigen Iterationen durchlaufen habt, außer Acht lassen könnt. Es bedeutet nur, dass ihr euch mit dem Grad, in dem ihr euch momentan befindet, besonders intensiv beschäftigen sollt – während eurer täglichen Arbeit und beim Lesen von Fachliteratur.
Wichtig ist, dass eine Übersicht der Grade, inklusive der wichtigsten von euch definierten Commit-Rules, in schriftlicher Form am Arbeitsplatz des Entwicklers zu finden ist. Eine rein elektronische Abbildung, zum Beispiel in Wiki-Dokumentationen, ist nicht besonders wirkungsvoll. Bewährt haben sich ausgedruckte und laminierte A4-Blätter, die täglich ins Auge fallen.
CCD: Die-Grade in der Übersicht
Die Prinzipien werden dann bei jedem Einchecken sowie bei jedem Code Review aktiv berücksichtigt. Zudem wird auf diese Weise auch eine Diskussion zwischen Commiter und Reviewer angestoßen, sobald die Prinzipien verletzt werden.
Es ist besser, nicht alle Prinzipien erfüllen zu können, als überhaupt keine Prinzipien zu beachten!
Ich möchte euch an dieser Stelle nochmals den Unterschied zwischen Prinzipien und harten Regeln verdeutlichen: Während starre Regeln keinen Platz für eigene Entscheidungen lassen und auch nicht jeder Situation gerecht werden, sollen die Praktiken und Prinzipien im Rahmen des CCD zu mehr Eigeninitiative und Selbstverantwortung beitragen. Dabei wird euch nicht der Gebrauch von Design Patterns vorgeschrieben. Vielmehr seid ihr selbst dafür verantwortlich, die richtigen Design Patterns auszuwählen, um die Prinzipien von CCD zu erfüllen. Zudem steht ihr natürlich selbst in der Pflicht, in einer Situation, wo sich Prinzipien widersprechen zu scheinen, die bestmögliche Lösung für eine Aufgabe zu finden.
Vorgehen bei adesso Schweiz
Wir setzen vermehrt auf die Eigenverantwortung der Entwickler in den verschiedenen Teams. Eine einfache, aber effektive Methode, die wir bei adesso Schweiz anwenden, besteht darin, die Farbe eines CCD-Grades auf Teammonitoren − etwa als Hintergrundfarbe − anzuzeigen. In einem bestimmten Intervall werden die Farben der CCD-Grade abwechselnd dargestellt und so ins Bewusstsein der Entwickler gerufen. Jeder Entwickler ist, ähnlich wie bei der individuellen Vorgehensweise, dafür verantwortlich, die Prinzipien und Praktiken einzuhalten. Zudem wird durch die team- und projektübergreifende Darstellung auf den Teammonitoren eine gemeinsame Vorgehensweise gewährleistet. Wichtig ist die Sichtbarkeit des Grades für alle Entwickler eines oder mehrerer Teams und zwar unabhängig von der gewählten Präsentationsmethode. Damit soll allen Teammitgliedern täglich sichtbar gemacht werden, auf welchem Grad sich die jeweiligen Entwickler befinden und auf welche Prinzipien und Praktiken sich der Einzelne besonders konzentriert. Bei mehreren Teams bietet dieses Vorgehen zudem den Vorteil, dass sich die Teams der verschiedenen Projekte über die Prinzipien und Praktiken des jeweilig aktuellen Grades austauschen können.
Begleitend zu diesem Vorgehen könnt ihr Informationsveranstaltungen (Brownbags) durchführen. Auch sogenannte Coding Dojos – gemeint ist die transparente Entwicklung und Kommunikation von Ideen und Lösungsansätzen – haben sich in diesem Zusammenhang etabliert. Ziel solcher Maßnahmen ist es, ein gesteigertes Bewusstsein für eine qualitativ hochwertige Entwicklung innerhalb der verschiedenen Kundenprojekte zu verinnerlichen. Letztendlich sollen vor allem eure Kunden von diesem Bewusstsein für Qualität und Professionalität in der Softwareentwicklung profitieren.
Ihr möchtet mehr zu diesem Thema erfahren? Kein Problem! Besucht einfach devblogs.ch. Hier veröffentliche ich regelmäßig Beiträge mit weiterführenden Beschreibungen und Informationen. Wem das noch nicht reicht, empfehle ich folgende Seiten:
Kategorie: |
|
Schlagwörter: |
Clean Code Softwareentwicklung |
