Software-Qualität ist das große Ziel von Clean Code. Zuverlässige Software, einfache Wartbarkeit und effektive Weiterentwicklung sind ebenfalls wichtige Eigenschaften, damit man wettbewerbsfähig bleibt. Technische Schuld muß permanent abgebaut werden. Das ist eine Aufgabe für das ganze Team und nicht nur für einzelne Spezialisten. Betrachten wir heute „9 Qualitätsmerkmale zum Thema Clean Code“.
1. Legacy Code macht zu viel – Clean Code ist fokussiert
9 Qualitätsmerkmale zum Thema Clean Code
Ein wichtiges Clean-Code-Pattern ist das Single-Responsibility-Prinzip – kurz SRP. Jede Klasse und Methode soll also nur eine Aufgabe haben und nicht mehrere erledigen. Das ist wichtig für die Lesbarkeit und Wartbarkeit. Darüber hinaus macht es Code einfacher testbar. Test-Driven-Development – kurz TDD – unterstützt die Entwicklung dabei hervorragend. Allerdings ist es sinnvoll sich erstmal mit den Grundlagen und den Features von Phpunit vertraut zu machen. So ist der Start einfacher und effektiver. Generell ist es schwieriger mit einer neuen Technologie am konkreten Beispiel zu starten. Hier denkt man zu sehr, wie es aus seiner persönlichen Sicht sein sollte. Das deckt in der Regel nicht die Möglichkeiten ab, die man mit der Technik zur Verfügung bekommt.
A functional unit on a given level of abstraction should only be responsible for a single aspect of a system’s requirements. An aspect of requirements is a trait or property of requirements, which can change independently of other aspects.
hat Ralf Westphal bereits 2012 in seinem Post zu SRP geschrieben. Beim Code-Refactoring bietet PhpStorm hier sehr gute Möglichkeiten Code Abschnitte in eigene Methoden auszulagern. Neuer Code muß hier von Anfang an besser geplant und durchgeführt werden.
2. Die Sprache in deinem Quellcode soll die Lösung lesbar und klar abbilden
Robert C. Martin hat es in einem Zitat auf den Punkt gebracht
It is not the language that makes a program look simple, but the programmer who makes the language appear simple.
Quellcode sagt auch aus, ob der Programmierer das Problem selber verstanden hat. Andernfalls braucht er immer wieder sogenannte Workarounds. Dadurch entsteht sehr viel Chaos im Code. Quellcode sollte, wie ein Buch, lesbar sein. Von oben nach unten. Klar und verständlich. Erreicht der Code dieses Ziel nicht, ist er nicht gut genug geplant und muß verworfen und neu geschrieben werden.
3. Code darf nicht redundant sein
Copy & Paste sind böse. Dabei wird es von Entwicklern aber immer wieder genutzt. Es dauert dabei nicht viel länger Code neu zu schreiben, anstatt ihn zu kopieren und anzupassen. Hier ist auch eine große Fehlerquelle, auch wenn es unter Umständen nur ein Variablen Name ist. Häufig ist redundanter Code in If-Statements im Else-Teil zu finden. Generell sollen solche Statements vermieden und reduziert werden. Ein switch ist hier auch keine Alternative, sondern nur eine andere Schreibweise.
4. Code zu lesen soll Freude machen
Wir bewegen uns viel im Code und verbringen große Teile unseres Lebens damit. Das soll und muß Spaß machen, sonst belastet es uns und macht uns weich. Dafür ist es wichtig, daß Code sehr gut lesbar ist und effektiv geschrieben wurde. 2 Code-Prinzipien helfen hier sehr gut. KISS – Keep it simple, stupid – sagt im wesentlichen, daß mit so wenig Code wie möglich eine Lösung erzielt werden soll. Das hatte ich in einem anderen Blickwinkel auch schon mit dem Post zum Thema Gasstation erläutert. Dazu kann man auch einen Blick auf YAGNI – You aren’t gonna need it – aus dem Extreme Programming (XP) werfen. Es umfasst einige wichtige Aspekte. Im Kern soll jedoch aller Code und alle Funktionalität, die nicht benötig wird, entfernt werden.
5. Kann schnell und effektiv von anderen Entwicklern verstanden werden
Never Code Alone – Wir schreiben Quellcode nicht nur für uns, sondern auch für andere Entwickler. Hier ist der persönliche Austausch beim Pair Programming und bei Code-Reviews sehr wichtig. So einigt man sich auf eine gemeinsame Sprache und auf Regeln. Auch für uns selber ist es wichtig nach einigen Monaten schnell wieder einsteigen zu können, ohne aufwändige Analysen durchführen zu müssen.
6. Guter Code soll minimale Abhängigkeiten haben
Abhängigkeiten sind eine große Herausforderung. Sie machen Code instabil und fehleranfällig. Mit Cachegrind kann man die Abhängigkeiten im Code visualisieren und darstellen. Auch bei Phpunit ist es deutlich schwieriger zuverlässige Tests zu erstellen. Insgesamt machen Abhängigkeiten viele Probleme, lassen sich aber nicht immer vermeiden.
7. Weniger ist mehr
Viele Regeln aus dem täglichen Leben kann man auch in der Software-Entwicklung anwenden. In den vorherigen Punkten haben wir das auch schon mehrfach gehört. Trotzdem ist es wichtig das nochmal deutlich herauszustellen. Das weniger betrifft nicht ein zwanghaftes einsparen von Codezeilen. Auch noch nerdigere Einzeiler führen hier nicht ans Ziel. Lesbarkeit und Klarheit stehen natürlich im Gegensatz zu „weniger ist mehr“. Aber das Thema hier bezieht sich auf richtigen Legacy-Code Wildwuchs. Code muß effektiv bleiben. Deshalb immer konzentriert und geplant arbeiten, damit man sich nicht verrennt.
8. Unit- und Acceptance-Tests
Phpunit und Codeception. Beides ist in PHP geschrieben und kann sehr einfach von den Webdevelopern erstellt und eingesetzt werden. Dadurch arbeitet man schneller, effektiver, besser und professioneller. Alles andere ist nicht professionell und sorgt für großen Schaden bei enormen Kosten. Es ist verantwortungslos. Zu Beginn eines Projekts müssen Tests sofort mit eingeführt werden. Frontend- und Backend-Tests sind gleich wichtig.
9. Guter Code ist aussagekräftig und eindeutig
In Quellcode müssen viele Sachen benannt werden. Klassen, Methoden, Variablen, Ordner und Dateinamen. Hier sind Ausdrücke wie data, info, return, temp, item und viele andere hinderlich. Das wird vielleicht in dem Moment der Erstellung von dem der davor sitzt verstanden. Das ist allerdings kein Kriterium sein. Hier zählt auf jeden Fall ein zweiter Blick und eine zweite Meinung. Das muß regelmäßig passieren und auch angepasst werden.
Fazit Qualitätsmerkmale zum Thema Clean Code
Clean Code ist ein sehr großes Thema, in dem man sich schnell verlieren kann. Halbherzig kann man hier auch keinen Gewinn für die Software, den Kunden oder das Unternehmen erzielen. Es ist jedoch möglich damit zu beginnen, ohne mit den neuen Aufgaben überfordert zu werden. Neuer Code soll dabei von Anfang an die Ansprüche erfüllen und eine große Testabdeckung bekommen. Legacy Code ist ein großes Problem. Was man in Jahren anrichtet kann man unmöglich in Wochen wieder aufräumen. Refactoring und Rewriting sind hier wichtige Werkzeuge.
Artikelbild Quelle:
Von –CM 14:40, 1. Jan. 2012 (CET) – Selbst fotografiert, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=34176502
