Clean Code Development zu erlernen, erfordert viel Know-how, Übung und Erfahrung. Seit über 12 Jahren haben wir uns auf die Fahne geschrieben, sauber zu entwickeln und Clean Code Development fest in unseren Unternehmensgrundsätzen und Projekten verankert. In internen und externen Schulungen geben unsere Clean Development Trainer dieses Wissen und ihre Erfahrungen aus der Praxis nun weiter. Wie die Schulungen ablaufen und welche Lerninhalte vermittelt werden? Wir haben bei unseren Trainern Felix und Thomas nachgefragt.
Felix: Ich wage zu behaupten, dass jeder, der Software schreibt und jedes Unternehmen, das irgendeine Softwareabteilung hat, über kurz oder lang auf das gleiche Problem stößt: Der Quellcode ist nicht mehr erweiterbar und neue Features zu implementieren, kostet unheimlich viel Geld. Beschäftigt man sich mit der Problematik dahinter, kommt man schnell auf das Thema Clean Code. Und dazu gibt es auch wahnsinnig viel Material. Allerdings erschlägt das Thema auch schnell, da es so umfangreich ist. Mit Kolleg:innen zu sprechen, die damit schon Erfahrungen gemacht haben, ist für viele daher sehr hilfreich. Und eben diese Erfahrungen teilen wir in unseren Schulungen. Denn wir kennen die Probleme, wir erleben die auch tagtäglich – und haben Lösungsvorschläge damit umzugehen.
Thomas: Die Unternehmen, die bei uns Schulungen anfragen, stehen an sehr unterschiedlichen Stellen. Teilweise geht es um Wissen über die Technologien, teilweise um die Clean Code Konzepte. Wir führen mit den Teilnehmenden deshalb vorher Gespräche, um zu erfahren, was denn die Schmerzpunkte sind. Beispielsweise das Thema automatisiertes Testing: Oft wissen die Teilnehmer:innen, dass Tests in der Softwareentwicklung enorm wichtig sind. Und sie möchten auch testen – aber wissen einfach nicht genau, wie man solch ein großes Thema angeht.
„Für uns hat sich herausgestellt, dass das richtige Mindset fast genauso wichtig ist, wie das Handwerkliche.“
(Thomas)
Felix: Zunächst ist es uns wichtig, das Problem bewusst zu machen: Was passiert, wenn wir eben nicht nach guter Handwerkskunst entwickeln? Das geht einher mit dem Thema Softwarequalität: äußere Qualität, die man eben sieht, wenn man die Anwendung bedient, aber auch innere Qualität, die nur Softwareentwickler:innen sehen.
Ist dieses Bewusstsein geschaffen, geht es um das Handwerkliche. Also welche Prinzipien, Praktiken aus den Clean Code Büchern kann man anwenden? Welche sind wichtig, welche sind weniger wichtig? Ein weiterer großer Teil in unseren Schulungen dreht sich um die Frage: Wie komme ich überhaupt von der Anforderung zum Code? Wie kann ich Probleme, die der Kunde mir stellt, so zerlegen – wir sprechen hier auch von schneiden –, dass sie sinnvoll mit Quellcode abbildbar sind? Denn wenn ich bereits in dieser Entwurfsphase richtig und durchdacht arbeite, generiere ich später fast schon automatisch sauberen oder besser gesagt erweiterbaren Code.
Thomas: Ein weiteres Lernziel unserer Schulungen ist das Thema Mindset. Für uns hat sich herausgestellt, dass das fast genauso wichtig ist, wie das Handwerkliche. Also wie man im Team zusammenarbeitet, wie agil oder eben nicht agil man arbeitet, wie sehr man fokussiert darauf ist, dass man Inkremente fertigstellt. Als Beispiel: Kein Code, den wir schreiben, geht ohne Review in den Produktivstand über. Das heißt mindestens zwei oder drei andere Entwickler:innen müssen den Code angeschaut haben. Eine Praxis, die wir immer wieder empfehlen, ist gemeinsames Code Review mit dem kompletten Team. Denn auch in der Kommunikation über den Code kann man viel lernen und sich kontinuierlich weiterentwickeln – im Projekt, im Team und im Unternehmen.
Thomas: Am Anfang geben wir immer eine Einführung in das Thema Clean Code und in die Clean Code Initiative. Dann dreht sich ein großer Block um automatisiertes Testen. Und im dritten großen Block geht es um Flow Design, wo wir darauf eingehen, wie man die Anforderung zerlegt, wie man den Entwurf für die Software macht und wie man den implementiert.
Dabei wechseln sich Theorieteile und Praxisteile immer wieder ab. Die Teilnehmenden machen Übungsaufgaben zu einem bestimmten Punkt, den man vorher theoretisch behandelt hat. Und dann schaut man im Review zusammen, was gut umgesetzt wurde, wo noch Lücken sind und leitet dann ab, worauf man im nächsten Theorieteil noch tiefer eingehen muss.
Felix: Also wir sind in der Lage, in verschiedene Themen verschieden tief einzusteigen. Das liegt auch ein bisschen an der Dynamik der Gruppe. Diese ganze Mindset-Thematik zum Beispiel ist nicht unbedingt etwas, wo man sagt: Okay, jetzt machen wir mal schnell Mindset und dann ist das Thema gegessen. Sondern das ist natürlich etwas, auf das wir immer wieder zurückkommen – beispielsweise während Praxisübungen.
„Über das Mitmachen lernt man einfach am besten.“
(Felix)
Thomas: Eher mehr Praxis. Ein großer Praxisteil ist das Code Review – also den erstellten Code gemeinsam zu besprechen. Da lernen die Teilnehmenden auch immer sehr viel dabei, weil es halt praktische Beispiele sind und von ihnen selbst erstellter Quellcode ist.
Felix: Der Einstieg ist natürlich erst mal eher theorielastig. Wir schauen aber schon, dass wir alles, was wir theoretisch vermitteln auch über Übungen, Beispiele oder Demonstrationen praktisch darstellen, um die Leute auch in den Theorieteilen interaktiv abzuholen. Das Mitmachen ist eben das, worüber man am besten lernt.
Thomas: Zum Beispiel Galgenmännchen programmieren. Also eine kleine Klasse, ein Konsolenprogramm oder – wenn es ums Testen geht – eine Funktion schreiben, mit der man das Kinderspiel Galgenmännchen umsetzen könnte. Oder auch schon etwas Komplizierteres: Bei unserer letzten Schulung haben wir bspw. einen Fragebogen gemacht.
Felix: Wir haben einen guten Fundus an Übungsaufgaben, die auch verschiedene Themen adressieren. Die wählen wir dann gezielt aus, um ein Thema, das wir theoretisch angesprochen oder durchgesprochen haben, durch Übung zu vertiefen.
Felix: Der Code, den Person A beispielsweise in der Galgenmännchen-Übungsaufgabe geschrieben hat, soll vom Team gereviewt werden. Dafür muss eine andere Person B, den ihr fremden Code dem Team vorstellen. Bei Clean Code ist immer auch Lesbarkeit ein großes Thema. Und durch dieses Vorgehen stellen wir sicher, dass jemand anderes diesen neu entstandenen Code auch richtig lesen und erklären kann, ohne ganz tief drin zu sein. Die Autoren sind allerdings auch dabei, sodass auf Rückfragen schnell reagiert werden kann. Dann werden Kommentare erstellt und diese Kommentare können parallel vom gesamten Team bearbeitet werden. Damit fokussiert man sich sehr stark auf das Abschließen und Fertigmachen von Dingen.
Felix: Eine Applikation ist dafür da, Probleme zu lösen. Und diese Probleme, die draußen bei unseren Kunden in der Welt sind, die müssen wir zunächst mal mit Code abbilden. Flow Design ist eine Technik, diese Probleme in viele kleine Häppchen zu zerschneiden, die schließlich mit Quellcode abbildbar sind.
Thomas: Uns ist wichtig, dass wir uns noch vor der ersten Zeile Code Gedanken machen, wie wir den Produktiv-Code schreiben und wie wir ihn zerlegen. Und das ist eben der Teil, den wir unter Flow Design verstehen. Mit Flow Design können wir Kundenanforderungen so zerlegen, dass wir immer tiefer kommen, immer kleinere Bausteine haben. Für die können wir dann ganz klar definieren, wie sie im Code zu arbeiten haben. Das ist unglaublich hilfreich für die Les- und Nachvollziehbarkeit im Code. Und auch das Thema Testing kann ich damit von Beginn an richtig angehen und planen.
„Wir sprechen da von Test First. Das bedeutet, dass ich mir noch bevor ich eine Zeile Produktiv-Code schreibe, Gedanken machen muss, wie ich diese Funktion testen könnte.“
(Felix)
Thomas: Wenn ich das Kundenproblem mithilfe von Flow Design in kleine Teile zerlegt habe, dann kommen auf der tiefsten Ebene vielleicht irgendwelche mathematischen Berechnungen oder Logiken raus. Da muss ich mir sicher sein, dass die funktionieren. Über automatisierte Tests in Form eines separaten Codes, der neben dem Produktiv-Code liegt, können wir sicherstellen, dass der Code auch das macht, was er machen soll. Eines der größten Probleme bei Projekten, die nicht mehr wartbar sind, ist, dass man kein Vertrauen mehr in den Code hat. Wenn ich jetzt an irgendeiner Stelle eine Änderung mache, kann ich mir nicht sicher sein, ob alles noch funktioniert. Und das immer manuell zu testen, wäre enorm schwierig und aufwändig.
Felix: Wir sprechen da von Test First. Das bedeutet, dass ich mir noch bevor ich eine Zeile Produktiv-Code schreibe, Gedanken machen muss, wie ich diese Funktion testen könnte. Testfälle sind auch ein super Mittel, um den Kunden zu fragen, was er sich eigentlich vorstellt. Nehmen wir nochmals das Galgenmännchen-Beispiel. Dann könnte man fragen: „Wenn ich jetzt zweimal hintereinander den gleichen Buchstaben eingebe, was soll denn dann passieren?“ Das darf der Kunde sich ja aussuchen. Das heißt, wir trainieren unsere Teilnehmenden auch darauf, solche Fragen zu stellen. Außerdem frieren Tests den aktuellen Status der funktionalen Anforderungen ein – auch für Entwickler:innen, die später daran weiterarbeiten.
Testing ist allerdings ein echtes Handwerk, das man erlernen muss. Das ist mit Sicherheit erst mal eine Hürde. Und die nimmt man tatsächlich auch besser, wenn jemand da ist, der einem auf die Sprünge helfen kann, wenn man den ersten Test nicht hinkriegt. Sobald man die Konzepte allerdings verinnerlicht hat und weiß, welche Technologien es gibt, ist das auch kein Problem mehr. Wenn ich weiß, wie ein Test zu schreiben ist, dann muss ich mir über das Wie eben keine Gedanken mehr machen. Dann geht es eher darum, welche Tests sind wichtig, um meine Applikation sinnvoll abzudecken.
Thomas: Eines der zentralen Themen der Clean Code Initiative sind die vier Werte: Die Korrektheit. Also dass der Code das macht, was der Kunde sich wünscht. Die Erweiterbarkeit. Will heißen, dass dem Code auch nach 2, 3, 4, 5, 10 Jahren immer noch Funktionalitäten hinzugefügt werden können, ohne dass man ihn erst monatelang umbauen muss. Die Produktionseffizienz. Dass das Team neue Features auch mit einer gewissen Geschwindigkeit und Effizienz einbauen kann. Und die kontinuierliche Verbesserung. Sich selbst und als Team kontinuierlich verbessern, reflektieren und auch hinterfragen.
Felix: Das oberste Ziel muss sein, diese Werte zu leben. Dabei müssen nicht immer komplett alle Prinzipien bis ins kleinste Detail erfüllt werden. Denn diese über 40 Prinzipien zahlen ja alle nur auf die Werte ein. Wenn ich das ein oder andere Prinzip verletze, aber trotzdem effizient korrekten und weiterentwickelbaren Code produziere, ist das vollkommen okay. Solch eine pragmatische Denkweise zu entwickeln, ist ganz wichtig.
„Jetzt Optimierungen für eine mögliche Zukunft zu machen, von denen man gar nicht wissen kann, ob sie funktionieren, fügt in fast allen Fällen nur unnötig Komplexität hinzu.“
(Thomas)
Thomas: Je nach Projekt und Code-Struktur sind natürlich unterschiedliche Prinzipien wichtig. Trotzdem gibt es Evergreens, die man immer befolgen sollte. Beispielswiese „Single Responsibility Principle“: Eine Methode oder eine Klasse sollte immer nur eine Funktion haben. Wenn eine Methode fünf verschiedene Funktionen hat, dann ist es schwierig, diese zu testen, weil man dann für alle fünf Sachen Tests schreiben müsste, vielleicht sogar für alle möglichen Kombinationen. Wenn man es allerdings in fünf Methoden aufsplittet, dann können die einzelnen Methoden separat getestet werden.
Felix: „Don’t Repeat Yourself“ ist ein weiteres der zentralen Prinzipien – das Copy-Paste-Problem. Wenn man feststellt, dass es im Code Duplikate gibt, man immer wieder an verschiedenen Stellen dasselbe macht. Denn das führt zwangsläufig dazu, dass man irgendwelche Änderungen an einer Stelle macht, die anderen drei Stellen allerdings vergisst. Die arbeiten dann eben noch nach dem alten Prinzip und sind fehleranfällig. Also man hat einen Bug behoben, aber nur an einer Stelle. Das macht es auch unnötig komplex, zu verstehen, wie der Code arbeitet.
Thomas: Dann – mehr bezogen auf die Arbeitsweise – „You Aint Gonna Need It“. Es geht darum zu sagen: „Den Teil klammern wir jetzt erst mal aus.“ Die Teilnehmenden auf das YAGNI-Prinzip zu trimmen, ist ein ganz großer Teil der Schulung. Konzentriert euch auf das, was ihr im Moment braucht und versucht nicht jetzt schon Probleme zu lösen, die irgendwann potenziell auftreten könnten. In eine ähnliche Kerbe schlägt „Beware of Premature Optimization“. Dahinter steckt die Denke: „Oh, ich optimiere das direkt auf Performance, weil ich potenziell 5 Millionen Benutzer haben werde.“ Tatsache ist aber besonders am Anfang, dass man vielleicht 50 User hat. Dann darf man sich auch nicht vom Kunden einreden lassen, dass das schon jetzt hochskalierbar sein muss. Jetzt Optimierungen für eine mögliche Zukunft zu machen, von denen man gar nicht wissen kann, ob sie funktionieren, fügt in fast allen Fällen nur unnötig Komplexität hinzu.
Felix: Außerdem das „Integration Operation Segregation Principle“. Wichtig ist dabei, dass wir unsere Applikation in Funktionseinheiten schneiden, die wie in einer Kette aufgerufen werden. Das heißt, dass ich bspw. in einer Buchhaltungsanwendung auf oberster Ebene definiere: „Wir wollen eine Buchung hinzufügen.“ Und dann fragen wir uns, was das eigentlich bedeutet. Das heißt vielleicht die Buchung erst mal in die Datenbank zu speichern und dann aufzusummieren. Und so gehen wir eben immer tiefer in diese Zerlegung und erhalten dadurch eine Applikation, die getrieben ist von Datenflüssen.
Felix: Code Checks sind tatsächlich ein sehr guter Einstieg, um herauszufinden, wo ein Unternehmen mit seiner Codebasis steht. Da sehen wir relativ schnell, ob es Verletzungen von Clean Code Prinzipien gibt und können diese gemeinsam besprechen. Wir können auch gleich Tipps geben, wie man den Code an dieser oder jener Stelle anders schreiben könnte und welche Vorteile sich daraus ergeben. Am Ende liegt die Wahrheit immer im Code.
Thomas: Wir gehen Code Checks sehr ähnlich wie Code Reviews an. Kann ich mir relativ einfach einen Überblick verschaffen, wurde wahrscheinlich Flow Design eingesetzt. Dann sehe ich nämlich die oberste Ebene und kann mich Stück für Stück reinzoomen. Wenn das nicht so ist, hat der Code schon einen gewissen Mangel. Lesbarkeit ist eines der höchsten Güter. Denn kann ich den Code nicht richtig lesen und nachvollziehen, kann ich ihn auch nicht um Funktionalitäten erweitern.
Interessant finde ich daran, dass man oft denkt: „ohje, ich bin zu blöd – ich verstehe diesen Code nicht.“ Aber nein, es liegt nicht an mir, sondern am Code. Und wenn man die ursprünglichen Entwickler:innen dann bittet, den Code zu erklären, merken die meistens selbst, dass er da etwas verworren geschrieben oder unklar formuliert hat. Häufig löst das auch schon den Knoten, um herausfinden, was man eigentlich ändern müsste.
Felix: Es müssen Leute sein, die Software entwickeln. Ansonsten macht es wenig Sinn. Wir halten zwar auch Vorträge über die Vorteile von Clean Code auf Management-Ebene, aber für die Schulungen braucht man einfach ein gewisses Vorwissen in Sachen Softwareentwicklung. Das kann sehr unterschiedlich sein, aber auch hier macht es Sinn, Entwickler:innen mit ähnlichem Wissenstand zusammenzubringen. Menschen, die schon viele Jahre entwickelt haben und sehr fit sind in Unit Tests bspw., die sind dann natürlich schnell gelangweilt, wenn es die dritte Übung zum Testen gibt. Insofern wäre es schon gut, wenn es nach Möglichkeit eine homogene Gruppe ist, was das Vorwissen betrifft.
Ihr möchtet weitere Informationen zu unseren Clean Code Schulungen erhalten? Oder gleich eine Schulung für Euer Team anfragen?
Im Rahmen des diesjährigen adesso eduCamps betreuten unsere Clean Code Experten Felix und Thomas die Clean Code Sessions.
Das Wertesystem von Clean Code Development umfasst die Werten Evolvierbarkeit, Korrektheit, Produktionseffizienz und Kontinuierliche Verbesserung.