Clean Code Development hat sich als Präventionsmaßnahme für sauberen und langfristig veränderbaren Quellcode etabliert. Trotzdem entwickelt noch lange nicht jede:r Entwickler:in mit der Methode. Der Grund: Clean Code zu erlernen, erfordert viel Know-how, Übung und Durchhaltevermögen. Das Karlsruher Softwareentwicklungsunternehmen generic.de hat sich seit über 12 Jahren auf die Fahne geschrieben, sauber zu entwickeln und Clean Code Development fest in den Unternehmensgrundsätzen verankert. Seit letztem Jahr verfügt das Unternehmen über ausgebildete Trainer für Clean Code Development, die ihr Wissen intern wie auch extern teilen. Wie die Schulungen ablaufen und welche Lerninhalte vermittelt werden, erklärten uns Thomas und Felix – Clean Development Trainer und erfahrene Softwareentwickler bei generic.de.
Warum werden Clean Code Schulungen bei generic.de gebucht?
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.
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, 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, Clean Development Trainer bei generic.de)
Welche Lernziele verfolgt ihr mit den Schulungen?
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? Denn wenn ich bereits in der 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. Also wie man im Team zusammenarbeitet. 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, sind gemeinsame Code Reviews mit dem kompletten Team. Denn auch in der Kommunikation über den Code kann man viel lernen und sich kontinuierlich weiterentwickeln.
Wie läuft eine Clean Code Schulung im Detail ab?
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.
„Das Mitmachen ist das, worüber man am besten lernt.“ (Felix, Clean Development Trainer bei generic.de)
Wie sind Theorie- und Praxisteil verteilt?
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 den Teilnehmenden 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.
Ihr habt vorhin Flow Design angesprochen. Was ist das genau?
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 Lesbarkeit 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, Clean Development Trainer bei generic.de)
Warum ist das Thema automatisiertes Testen so wichtig und wie vermittelt ihr das in den Schulungen?
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. 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 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.
Clean Code Development sind ja nicht nur Tipps und Tricks, sondern ein komplettes Wertesystem. Wie genau kann man sich das vorstellen?
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, Clean Development Trainer bei generic.de)
Gibt es sowas wie die Best of der Clean Code Prinzipien?
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. Man hat also 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 gerade am Anfang, dass man vielleicht 50 User hat. 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.
Bietet ihr auch Code Checks an?
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.
Für wen sind die Clean Code Schulungen?
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.
Vielen Dank
Das komplette Interview gibt es hier.
Weitere Informationen über CLean Code Schulungen bei generic.de gibt es hier.
Warum werden Clean Code Schulungen bei generic.de gebucht?
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.
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, 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, Clean Development Trainer bei generic.de)
Welche Lernziele verfolgt ihr mit den Schulungen?
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? Denn wenn ich bereits in der 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. Also wie man im Team zusammenarbeitet. 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, sind gemeinsame Code Reviews mit dem kompletten Team. Denn auch in der Kommunikation über den Code kann man viel lernen und sich kontinuierlich weiterentwickeln.
Wie läuft eine Clean Code Schulung im Detail ab?
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.
„Das Mitmachen ist das, worüber man am besten lernt.“ (Felix, Clean Development Trainer bei generic.de)
Wie sind Theorie- und Praxisteil verteilt?
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 den Teilnehmenden 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.
Ihr habt vorhin Flow Design angesprochen. Was ist das genau?
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 Lesbarkeit 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, Clean Development Trainer bei generic.de)
Warum ist das Thema automatisiertes Testen so wichtig und wie vermittelt ihr das in den Schulungen?
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. 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 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.
Clean Code Development sind ja nicht nur Tipps und Tricks, sondern ein komplettes Wertesystem. Wie genau kann man sich das vorstellen?
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, Clean Development Trainer bei generic.de)
Gibt es sowas wie die Best of der Clean Code Prinzipien?
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. Man hat also 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 gerade am Anfang, dass man vielleicht 50 User hat. 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.
Bietet ihr auch Code Checks an?
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.
Für wen sind die Clean Code Schulungen?
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.
Vielen Dank
Das komplette Interview gibt es hier.
Weitere Informationen über CLean Code Schulungen bei generic.de gibt es hier.
