Sauberer Code ist eine Arbeitserleichterung, wer einmal – in fremdem Code – herumgearbeitet hat, weiß das. Und manchmal ist „fremder Code“ mein eigener Code von vorletztem Jahr… Clean Code Developer haben ein Wertesystem entwickelt, das dieses Übel an der Wurzel packt. Das skizziere ich Euch mal hier, zuerst die vier Werte:
- Evolvierbarkeit
- Korrektheit
- Produktionseffizienz
- Reflexion
Evolvierbarkeit
Damit Änderungen möglich sind, muss jede Software eine innere Struktur haben, die Änderungen ermöglicht. Das ist für Clean Coder „Evolvierbarkeit“.
Alle, die ein Auto besitzen, wissen, dass es regelmäßig einen Ölwechsel braucht. Nicht etwa, weil das Öl zu dem Zeitpunkt aufgebraucht wäre, nicht einmal deshalb, weil das Öl zu dem Zeitpunkt bereits völlig wirkungslos wäre. Nein, es wird getauscht, weil Erfahrungswerte des Herstellers zeigen, dass der Motor durch den rechtzeitigen Ölwechsel geschont wird und somit länger hält.
Das ist bei Software anders. Es gibt – auf den ersten Blick – keine Verschleißteile oder ähnliches.
Software wird in der Regel über lange Zeiträume betrieben. Während dieser Zeit ändern sich die Rahmenbedingungen, müssen Features ergänzt werden. Im Idealfall kostet die Implementierung eines Features einen festen Betrag, der unabhängig davon ist, wann das Feature realisiert wird.
Natürlich gibt es beim Betrieb der Software immer etwas zu tun. So sollte vielleicht regelmäßig geprüft werden, ob die Logdateien noch ausreichend freien Platz auf der Festplatte lassen, ob eine Datenbank überläuft oder der Speicher sich zunehmend füllt.
In der Praxis steigt der Aufwand (nicht nur der Preis) für ein Feature umso mehr, je später es realisiert wird. Am Anfang sind Features preiswert, am Ende ist es gar nicht mehr möglich Features zu ergänzen, weil niemand mehr durchblickt. Die Kosten steigen exponentiell. Schließlich wird die Software weggeworfen und neu entwickelt.
Das Gemeine an exponentiellem Wachstum:
- Anfangs erkennt man kaum, dass die Kosten anwachsen. Die Steigung ist moderat.
- Erkennt man, dass die Kosten steigen, ist es zu spät. Ein Gegensteuern ist nicht mehr möglich.
Je einfacher die Software an geänderte Rahmenbedingungen angepasst werden kann, desto höher ist ihre Evolvierbarkeit. Doch Evolvierbarkeit erhält man nicht nachträglich. Sie muss von vorneherein berücksichtigt werden.
Beispiel
Klassen sollten genau eine Verantwortlichkeit haben. Ist eine Klasse für mehr als eine Sache zuständig, ist es schwerer sie zu überblicken. Das behindert Änderungen, denn diese bedingen, dass man den Quellcode versteht. Die Kopplung zwischen den Klassen ist größer als bei „Einzelverantwortlichkeit“. Plötzlich hängt alles mit allem zusammen.
Dies kann man nur verhindern, indem Funktionseinheiten eine klar definierte Verantwortlichkeit haben und man die Kopplung im Blick behält.
Hat man in einem Softwaresystem eine Reihe von Klassen angesammelt, die jeweils für mehrere Dinge verantwortlich sind, ist es im Nachhinein nur schwer möglich, diesen Zustand zu beseitigen. Die Kopplung ist so groß, dass es schwer fällt, einzelne Funktionseinheiten heraus zu lösen. Sollen in diesem Dickicht neue Features realisiert werden, ist das sehr aufwändig. Wenn nicht rechtzeitig begonnen wird, das Dickicht zu lichten, wird die Situation mit jeder Änderung schlimmer.
Korrektheit
Software muss funktional korrekt sein. Ein Buchhaltungsprogramm muss die Buchungen ordnungsgemäß verbuchen, eine Tabellenkalkulation muss richtig rechnen. Und auch die nicht-funktionalen Anforderungen müssen erfüllt sein. Das Programm muss schonend mit Ressourcen wie Speicher, Prozessorzeit, Plattenplatz etc. umgehen, die Antwortzeiten müssen in einem definierten Rahmen liegen. Erst wenn alle Anforderungen erfüllt sind, ist die erstellte Software korrekt.
Was kann man konkret für Korrektheit tun? Testen ist nicht die Lösung. Korrektheit muss bereits während der Entwicklung berücksichtigt werden. Nochmal: Die Entwickler müssen sich mit der Frage der Korrektheit auseinandersetzen.
Und damit sie das überhaupt können, muss ihnen klar sein, was die Anforderungen sind. Schon daran mangelt es zu oft. Die Aufgabe der Entwickler ist, bei unklaren Anforderungen nachzufragen, statt in eine Glaskugel zu schauen oder den schwarzen Peter zu „den Anderen“ zu schieben.
Verglichen mit dem Automobilbau steht die Softwareenwicklung beim Thema Korrektheit schlecht da. Ein Auto besteht aus vielen Teilen, deren Korrektheit jeweils einzeln nachgewiesen und überprüft werden kann. Stellen Dir vor, Du müsstest zur Fehlersuche mit einem Meßgerät in der Hand bei Tempo 200 auf der Motorhaube eines Autos sitzen, um dort verfolgen zu können, was sich in der Maschine abspielt. Hmmm… das ist komisch? Ein Debugger wird in vielen Fällen genau so eingesetzt.
Produktionseffizienz
Entwicklungszeit und Preis der Software spielen immer eine Rolle. Der Preis ist höher, wenn die Produktion der Software nicht effizient erfolgt. Das beginnt bei manuellen Arbeitsschritten, die nicht automatisiert werden und geht bis zu hohen Fehlerraten, die mehrmaliges Nachbessern erfordern. In letzter Konsequenz bedeutet Produktionseffizienz, dass die Software über Jahre oder gar Jahrzehnte weiterentwickelt werden kann, statt irgendwann die alte Software wegzuschmeißen und wieder ganz von vorne beginnen zu müssen.
Gleichzeitig reduziert eine hohe Produktionseffizienz die Anfälligkeit für Fehler.
Die Produktionseffizienz hilft, andere Werte in ein maßvolles Verhältnis zu setzen. Wer unendlich viel Aufwand für die Korrektheit treibt, macht am Ende auch etwas falsch.
Reflexion
Ohne Rückschau ist keine Weiterentwicklung möglich. Nur wer reflektiert, wie er eine Aufgabenstellung gelöst hat, kann beurteilen, ob der gewählte Weg einfach oder beschwerlich war. Lernen basiert auf Reflexion.
In so einem schnelllebigen Bereich wie der Informatik ist es besonders wichtig, stets neue Erkenntnisse zu berücksichtigen. Dazu ist Reflexion auf allen Ebenen erforderlich. Angefangen beim Reflektieren über die Implementation beim Pair Programming oder Code Review, das tägliche Reflektieren des Teams, die Reflexion nach jeder Iteration, bis hin zur Reflexion der gesamten Branche über ihr Tun. Ohne Reflexion keine Weiterentwicklung.
Clean Code Developer Grade
- Schwarzer 0. Grad
- Roter 1. Grad
- Oranger 2. Grad
- Gelber 3. Grad
- Grüner 4. Grad
- Blauer 5. Grad
- Weißer 6. Grad
- … und von vorn
Clean Code Developer*in ist man nicht einfach, sondern man wird es. Es geht nämlich nicht darum, ein paar Regeln auswendig zu lernen, sondern das CCD-Wertesystem zu verinnerlichen. Das braucht Übung … und Zeit. Deshalb gibt es die Unterteilung in CCD-Grade, die man als Entwickler*in eine nach der anderen durchläuft. Achtung: Der gesamte Prozess ist als Kreis zu verstehen: wer alle Grade bearbeitet hat, beginnt wieder von vorne.
Jedem Grad ist eine Farbe zugeordnet. (Wer mag, kann dabei ein CCD-Armband als tragen, gibt’s natürlich über die Website zu erstehen…)
Anders als im Judo entspricht die Farbe nicht einem erreichten Grad, sondern dem in Arbeit befindlichen.
Schwarzer 0. Grad
Den schwarzen Grad hat jeder, der sich für CCD interessiert. Man kann es tragen, wenn man für den ersten richtigen Grad noch nicht alle Voraussetzungen erfüllt.
Roter 1. Grad
Der Weg zum Clean Code Developer beginnt mit dem roten Grad. Mit dem roten Grad setzt die Übungspraxis ein. Er enthält nur Elemente, 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.
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 wichtigsten Mittel zur Produktivitätssteigerung zu gewinnen: Automatisierung von Abläufen. Die Automatisierung dient der Korrektheitsprüfung. Es geht also nicht um eine nice-to-have-Eigenschaft von Code, sondern um seine Essenz.
Gelber 3. Grad
Beim gelben Grad geht es vollends um automatisierte 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 eine Ä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. Automatisierung ist Schlüssel zur Produktivität und Reaktionsfähigkeit. Nur wenn maximal viele Tätigkeiten in der Softwareentwicklung automatisiert sind, kann sich der Clean Code Developer auf’s Wesentliche konzentrieren: die Implementation von Kundenanforderungen. Ohne Automatisierung hängt die Entwicklung sonst oft an Kleinigkeiten, was Zeit kostet. Korrektheitsprüfungen und Releases sind dann eher eine Strafe. Nach der Automatisierung der Tests steht jetzt die Produktion auf dem Plan. Code am Entwicklerarbeitsplatz zu testen, geschenkt. Ihn auf einem unabhängigen Rechner zum Laufen zu bringen und zu testen, ist eine ganz andere Nummer. Nur dort lassen sich mehr oder weniger subtile Abhängigkeiten vom Entwicklerarbeitsplatz finden. Dazu gibt es im 4. Grad noch mit weitere Prinzipien zur Codestrukturierung und ein Werkzeug für bessere Architekturen.
Blauer 5. Grad
Mit dem blauen Grad geht die Automatisierung noch einen Schritt weiter. Jetzt steht das Deployment an. Vor allem geht es im blauen Grad aber nun um Aspekte der Softwareentwicklung jenseits von Code und Tools: Clean Code Developer kümmern sich nicht nur um gute Strukturen im Kleinen, sondern planen sie von vornherein im Großen. Es geht also um Architektur. Zur Softwareentwicklung insgesamt gehört an dieser Stelle 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
In den weißen Grad fließen alle Prinzipien, Regeln und Praktiken ein. Auf der Ebene des weißen Grades arbeitet ein CCD nur, wenn er ständig das ganze CCD-Wertesystem im Blick hat. Das macht klar, dass nur wirklich fortgeschrittene Softwareentwickler*innen 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. Die vielen Bausteine lassen sich schlicht in kleinen Happen besser aneignen als in einem großen Anlauf.
Deshalb ist es wichtig, dass alle, die sich für CCD interessieren, 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 neu und ungewohnt, sich dermaßen bewusst mit Prinzipien und Praktiken auseinanderzusetzen. Insbesondere die tägliche Reflektion darüber ist wahrscheinlich noch nicht Gewohnheit.
Ein stumpfes Abhaken von Programmiergewohnheiten, die man davon schon beherzigt, ist letztlich unerheblich. Es geht nicht um „Verdienst“, sondern um Iterationen und kleine Happen. Grade sind Gucklöcher auf das große Ganze.
Fortbildung: Fortwährend immer weiter und weiter bilden
Das Wertesystem und die Bausteine mögen starr aussehen, wie in Stein gemeißelt. So ist es aber nicht. Es ist immer nur vorläufig, bis die Community sieht, dass etwas verändert werden sollte. Noch viel stärker im Fluss ist die Welt der Werkzeuge: Programmiersprachen, IDEs, Frameworks, Plattformen, Serverprodukte verändern sich ständig. Tendenziell wird das, was es zu wissen und zu können gilt, immer nur mehr und mehr. Ein Ende ist nicht in Sicht.
Professionalität bedeutet, informierte Entscheidungen zu treffen. Daher die Notwendigkeit, sich ständig fortzubilden. Wahrscheinlich ist Softwareentwicklung sogar der Bereich mit der größten Notwendigkeit dazu.
Aspekte der Fortbildung sind deswegen Bestandteile mehrerer Grade (Orange, Gelb, Grün). Damit wird deutlich, 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 Sich-Fortbilden will gelernt sein.
In den Graden geht es aber lediglich um die Fortbildungsformen (Lesen, Networking, Veröffentlichen). Wieviel Zeit sie benötigt, geben sie nicht vor. Daumenregel: Fortbildung sollte unabhängig von der Form mindestens 20% der Arbeitszeit ausmachen.
Ja, das meinen die Leite von CleanCodeDeveloper.de genau so. 20% der Arbeitszeit für Fortbildung. In der Regel also 1 Tag/Woche nur für die Fortbildung. Nicht weniger. (Google macht vor, dass das funktioniert.)
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, dass Nutzen für Projekte gestiftet werden kann
- Fortbildung braucht kann mit kleinem Budget für Schulungen oder Software funktionieren
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 dem Üben beim Musizieren. Auf der Bühne muss die Musikerin performen, tunlichst fehlerfrei. Um ihr Können auf gleichem Stand zu halten oder sogar zu verbessern, muss die Musikerin natürlich üben. Dabei sind Fehler ausdrücklich zugelassen, da sonst keine Weiterentwicklung möglich wäre. Es bedarf also zweier unterschiedlicher „Betriebsarten“.
Erst unter der Voraussetzung eines solchen Spielraums für Fehler geht es darum, wie er sinnvoll ausgefüllt wird. Einziger Anspruch an mögliche Inhalte sollte sein, dass ein Bezug zur Arbeit erkennbar ist. Wer die 20% Spielraum für die private Wohnungssuche oder Sport im unternehmenseigenen Fitnesscenter nutzt, bildet sich nicht fort. (Wobei der Sport zumindes – auch geistig – die Leistungsfähigkeit stärkt ;)
Arten von Fortbildung
- 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: unternehmensintern (z. B. Firmen-Wiki) oder 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 jedem (!) Fall!!! Entweder unmittelbar oder mittelbar. Denn jede Kenntnis einer Technologie oder eines Verfahrens, auch wenn der Einsatz im Projekt noch nicht absehbar ist, macht optionenreicher.
Hinweis für die Entscheider*in: Entwickler, die sich kontinuierlich fortbilden, stellen einen Wert dar. Sie sind erfahrener, innovativer, flexibler. Zugehört: „Das dient Ihrem Erfolg!“
Hinweis für die Softwareentwickler*in: Wer sich fortbildet, wird wertvoller. Er gewinnt an Erfahrung, ist nicht in einer Nische festgenagelt. Das dient der „Employability“.
Übung
Clean Code Developer zu werden braucht Zeit. Schätzungsweise muss man pro Grad sicher mehr als 21 Tage einplanen. Denn 21 Tage (3 Wochen) – so sagt die Psychologie – brauchen Menschen, um Neues oder allgemein Veränderungen als Gewohnheit zu etablieren.
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. Diese physische Aktion hat einen eigenen Einfluss auf das Gehirn.
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 übergehen und das nächste Armband überstreifen.
Natürlich gibt es keine formale Kontrolle, ob während eines Tages wirklich alle Prinzipien beachtet worden sind. Es liegt an der Ehrlichkeit jeder Einzelnen sich und der CCD-Community gegenüber, darüber nach bestem Wissen und Gewissen zu urteilen.
Da kein Grad besser oder schlechter ist als ein anderer, lohnt sich Mogelei ohnehin nicht. Entwickler*innen, die den weißen Grad gemeistert haben, beginnen wieder beim roten Grad. So demonstrieren sie ihre Überzeugung, dass Softwareentwicklung ständiges Lernen ist.
Mehr Infos unter
www.cleancodedeveloper.de
Maria
Zur Auftaktveranstaltung der 5. Ingenieurinnen Sommeruni fand am 19 . August 2013 ein Vortrag durch Prof. Dr. Ulrike Jordan zum Thema „Aktuelle Forschungsthemen in der Solarthermie“ statt. Der sehr gut besuchte Vortragsaal, der auch männliche Teilnehmer anzog, dauerte ungefähr zwei Stunden und handelte von dem zukunftsträchtigen Feld der Solarthermie. Frau Prof. Dr. Ulrike Jordan hatte keine Scheu, auch einmal in die Runde zu fragen oder hochkomplizierte Dinge zu behandeln.
