featured image

September 13, 2018 / by Jenny Dornberger / In Quality

Clean Code Development Part 1: Eine Typen- und Team-Frage

Heute, am 256. Tag des Jahres, feiern wir mit dem Tag des Programmierers einen beruflichen Gedenktag. Aber welche Regeln sollte ein „guter Programmierer“ eigentlich berücksichtigen, um qualitativ hochwertige Software zu bauen? Mit Blick auf das Kernelement der Arbeit von Entwicklern – dem Schreiben von Quellcode - kommt mir als Content-Managerin eines IT-Unternehmens, natürlich als erstes das Clean Code Development in den Sinn.

10 Jahre nach der Softwareentwickler-Bibel

Zehn Jahre nach Erscheinen des englischsprachigen Standardwerks von Robert C. Martin möchte ich durch diese 2-teilige Serie in Interviews mit unseren Entwicklern evaluieren, was Clean Code Development (CCD) bewirken kann und welche Hürden die Integration des Ansatzes im Alltag von Softwareentwicklern mit sich bringt.

Ist das Interesse an sauberem Code eine Frage des Typs?

Klar ist: Jeder Softwareentwickler hat einen anderen Ausbildungshintergrund, unterschiedliche Vorerfahrungen, divergierende Interessensschwerpunkte und daraus resultierend andere Herangehens- und Arbeitsweisen im Laufe seiner Karriere entwickelt. Je nach Typ, orientieren sich einige Entwickler lieber an den Code-Ratschlägen anderer und hoffen, dass sie damit durch kommen (Jesse Pinkman-Typ) oder haben als pragmatischer Macher à la MacGyver den schnellen Bugfix im Blick, ohne den perfektionistischen Anspruch zu haben gute Code-Qualität abzuliefern. Viele Entwickler streben jedoch wohl das Idealbild des „Rain Man“ an, der – wie es t3n in seiner scherzhaften Umfrage formulierte - Code atmet und mit einwandfreien Codezeilen denkbar elegant ganz einfach jedes Problem des Entwickler-Alltags in den Griff bekommt, ohne sich darauf etwas einzubilden. Gerade diese Rain Men sind es wohl auch, die als Clean Coder versuchen mehr Qualität in die Softwareentwicklung zu bringen. Da beim Clean Code Development letztendlich jeder Entwickler selbst dafür verantwortlich ist, langfristig die Prinzipien und Praktiken für sauberen Code einzuhalten, muss er dazu bereit sein, sich ständig mit seiner eigenen Leistung und Herangehensweise auseinanderzusetzen. Eine intrinsische Motivation, sich unaufhörlich weiterzuentwickeln und offen für Neuerungen zu bleiben, ist deshalb von unschätzbarem Vorteil. Schon 2008 scheint „agile software craftsmenship“ von so großer Bedeutung zu sein, dass Uncle Bob den Begriff im Untertitel seines Buchs „Clean Code“ nannte. Ein Software Craftsman, der mit einem gewissen Qualitätsanspruch an die Arbeit geht, findet sich heute wohl schnell in diversen Architektur-Ansätzen (DDD, SOA, Microservices…) und methodischen Vorgehensweisen (TDD, CD oder Pair-Programming…) wieder. Folgt man der gängigen Meinung, führt bei der konkreten Code-Produktion kein Weg am Clean Code Development vorbei.

Aber bringt CCD – im Vergleich zum Zeit-Invest - wirklich so viel?

Wir als Cloudogu-Team sagen: „Ja!“. Unsere Entwickler berichteten mir, dass es anfangs schon gewöhnungsbedürftig war, jede Codezeile erneut mit dem Blick darauf zu überprüfen, ob nur eine Abstraktionsebene pro Methode gewählt, beschreibende Namen verwendet, Anweisung und Abfrage getrennt, Wiederholungen vermieden, optimal formatiert wurde, die Klassen klein gehalten waren etc. Aus der Logik heraus erscheint es natürlich sinnvoll Code von Beginn an so zu schreiben, dass er verständlich und nicht zu komplex ist; dass er Austauschbarkeit erlaubt und sich selbst durch sprechende Namen erklärt. Aber auch in unserem Projekt ging mit diesem Fokus anfangs (gefühlt) eine niedrigere Produktivität einher. Dennoch glauben wir, dass sich dieses Initial-Invest langfristig gelohnt hat. Denn die Ausrichtung auf sauberes Coding geht mit klaren Handlungsanweisungen einher, die Interpretationen und Fehler weniger Raum geben und in einem sehr strukturierten Softwareentwicklungsprozess münden. Qualitativ hochwertiger und testbarer Code kommt zudem langfristig auch Kunden und Usern zugute. Denn im Sinne der Nachhaltigkeit ist clean Software für spätere Anpassungen und Erweiterungen besser vorbereitet und verursacht so langfristig weniger Aufwand. Statt eines Wegwerfprodukts und teuren Starts von Null, sind es langfristig nutzbare Funktionen, die Investitionssicherheit geben. Orientieren sich Entwickler schon bei den ersten Codezeilen an den Hinweisen aus dem Clean Code-Buch, können zudem ungeplante Arbeitsumfänge durch Refactoring verringert werden und sind durch vorhandene Tests weniger fehleranfällig. Auch wenn dauerhafte Produktivitätssteigerungen durch Clean Code Development nur schwer mess- und beweisbar sind, folgen wir Uncle Bobs Argumentation, dass die „Lebenszykluskosten eines Chaos“ langfristig zu einer Null-Produktivität in Teams führen kann, wenn man keinen Wert auf sauberen Code legt.

A propos Team

Clean Code kann eine Grundlage für Standards am Code bilden und in anregenden Diskussionen zur Schaffung einer gemeinsamen Qualitätsbasis dienen, die kontinuierlich verbessert werden kann. Gerade im arbeitsteiligen Alltag eines agilen, wachsenden Teams wie bei uns, ist es wichtig den Code für unbedarfte Kollegen zu optimieren, die z.B. neu im Team sind oder sich Tasks aus dem Sprint Backlog genommen haben, mit denen es zuvor wenig Berührungspunkte gab und die normalerweise einer Einarbeitung bedürfen.

Die Lesbarkeit ist aber auch für den Entwickler selbst essentiell, denn Code wird nach dem einmaligen Schreiben bei langfristig laufenden Projekten mit teilweise mit großem Zeitversatz immer wieder „neu“ gelesen und ggf. angepasst.

Eine optimierte Maschinen-Lesbarkeit sollte erst dann im Fokus stehen, wenn es wirklich Notwendigkeit wird, denn “Premature optimization is the root of all evil” (Donald Knuth, 1968)“. Dass die Performance einer Anwendung durch das Clean Code Development unter einer „Kleinschrittigkeit“ im Code Design leidet, ist für uns kein hinreichendes Argument auf den Ansatz zu verzichten. So nehmen uns moderne Compiler heute einen Großteil der Optimierungsarbeit auf Basis von maschinenlesbarem Code ab. Das iterative Vorgehen und eine kontinuierliche Reflektion des geschriebenen Codes ist tief im Clean Code-Ansatz verankert. Beides passt sehr gut mit agilen Vorgehensmodellen (wie z.B. Scrum) zusammen, welche wir im Team leben.

Ausblick

Welche Voraussetzungen noch gegeben sein sollten, damit ein Clean Code Development sich in Eurem Team durchsetzen kann und wie wir das Thema im Cloudogu-Team angehen, erfahrt ihr im nächsten Teil dieser Serie. Dieser erste Teil hat einen Einblick gegeben, dass sowohl die individuelle Grundeinstellung zu Eurer täglichen Arbeit, als auch das Team-Committment und die Disziplin, die Anpassungs- und Lernbereitschaft aller Beteiligten ausschlaggebend sind, um die langfristigen Vorteile zu nutzen, die Clean Code Development bringen kann.


Jenny Dornberger

- Marketing Manager -

Sie versucht die Welt der Softwareentwicklung für Kunden und Bewerber zu erklären – auch vor technischen Themen macht sie dabei nicht Halt!

©2018 Cloudogu GmbH. All rights reserved. Legal Notice | Privacy Policy

Cloudogu™, Cloudogu EcoSystem™ and the Cloudogu™ logo are registered trademarks of Cloudogu GmbH, Germany.