Beim Schreiben eines Artikels ist jedem klar, dass nicht nur die Kerninformation des Artikels relevant ist, sondern auch seine Struktur und die verwendete Ausdruckweise, um die Information möglichst verständlich für den Adressaten des Artikels zu machen. Insofern hat das Schreiben von Code einige Parallelen zum Schreiben eines Artikels. Es geht nicht allein darum, dass der Code kompiliert und funktioniert, sondern der geschriebener Code hat immer einen Adressaten. In der Regel sind dies andere Entwickler. Um Code intuitiv verständlicher zu gestalten, stellt Clean Code eine Reihe von Lösungsansätzen bereit.
Der Begriff Clean Code hat seinen Ursprung im gleichnamigen Buch von Robert Cecil Martin. Als „sauber“ bezeichnen Softwareentwickler in erster Linie Quellcode, aber auch Dokumente, Konzepte, Regeln und Verfahren, die intuitiv verständlich sind. Als intuitiv verständlich gilt alles, was mit wenig Aufwand und in kurzer Zeit richtig verstanden werden kann. Dadurch sollen folgende Eigenschaften von Software verbessert werden:
Merke: Funktionierender ≠ Code Clean Code
Was Code letztlich tatsächlich sauber und intuitiv verständlich macht, ist dabei hoch subjektiv und Thema vieler Debatten. Wir wollen einige Anregungen liefern und es damit Teams erleichtern, Ihre eigenen Guidelines zum Schreiben von Clean Code zu entwickeln.
Zu Beginn eines neuen Projektes sollten alle Entwickler, die in der gleichen Programmiersprache arbeiten sich Gedanken darüber machen, welche Richtlinien sie für die Struktur des Codes festlegen möchten. Diese Richtlinien werden in einem Styleguide zusammengefasst und die Teammitglieder einigen sich darauf dem Styleguide zu folgen. Solche Styleguides können auch Unternehmensweit vorgegeben werden, um die Einarbeitungszeit in verschiedenste Projekte zu verringern.Wer sich nicht die Mühe machen möchte, einen kompletten Styleguide selbst zu entwerfen, kann entweder einen Styleguide übernehmen oder einen bestehenden Styleguide ergänzen.Unter folgender Adresse finden sich Styleguides von Google für verschiedenste Sprachen.
Zu Beginn eines neuen Projektes sollten alle Entwickler, die in der gleichen Programmiersprache arbeiten sich Gedanken darüber machen, welche Richtlinien sie für die Struktur des Codes festlegen möchten. Diese Richtlinien werden in einem Styleguide zusammengefasst und die Teammitglieder einigen sich darauf dem Styleguide zu folgen. Solche Styleguides können auch Unternehmensweit vorgegeben werden, um die Einarbeitungszeit in verschiedenste Projekte zu verringern.Wer sich nicht die Mühe machen möchte, einen kompletten Styleguide selbst zu entwerfen, kann entweder einen Styleguide übernehmen oder einen bestehenden Styleguide ergänzen.Unter folgender Adresse finden Styleguides von Google für verschiedenste Sprachen.
Prinzipien sind grundlegende Regeln, die häufig das Ziel verfolgen die Änderbarkeit, Wartbarkeit und Erweiterbarkeit von Software zu erhöhen. Dabei gibt es besonders in Bezug auf die objektorientierte Programmierung eine große Sammlung an Prinzipien. Es ist deutlich schwieriger, konsistent Prinzipien einzuhalten, als einem Styleguide zu folgen. Daher empfiehlt es sich, sich im Team auf eine Handvoll von Prinzipien zu einigen, welche eingehalten werden sollten. Dies macht die konsistente Einhaltung deutlich einfacher.Folgende Prinzipien versuchen wir bei der Entwicklung immer zu berücksichtigen.
Kohäsion und Kopplung sind zwar keine Prinzipien im traditionellen Sinne, aber sie bieten als Maß für Komplexität von Software einen guten Anhaltspunkt für die Änderbarkeit, Wartbarkeit und Erweiterbarkeit. Dabei beschreibt Kopplung die Beziehungen zwischen Komponenten und Kohäsion die Beziehungen innerhalb einer Komponente. Ziel ist eine möglichst hohe Kohäsion innerhalb von Komponenten und eine möglichst geringe Kopplung zwischen Komponenten. Eine hohe Kohäsion kann z.B. erreicht werden, indem Komponenten nach logisch zusammenhängenden Gruppen gebildet werden, die sich gegenseitig bedingen. Gibt es viele Beziehungen zwischen den Teilkomponenten zweier Komponenten, ist dies ein Zeichen dafür, Funktionen ggf. in weiteren Komponenten zu reorganisieren, weil die Kopplung zu hoch ist.
Komponenten sind hierbei funktionale Gruppen vom Mikroservice bis zur Klasse.
Jede Klasse, jedes Module oder jede Funktion sollten genau einen Zweck bzw. eine Aufgabe in einem Programm haben und damit auch nur aus einem Grund geändert werden.
Für jedes Problem sollte die einfachste Lösung gewählt werden. Ockhams Rasiermesser lässt sich hier ebenfalls anwenden. Die einfachste Lösung ist häufig die beste.
Redundanz sollte vermieden werden. Abstraktion kann dabei helfen Redundanz zu vermeiden.
Viele Prinzipien lassen sich darauf runterbrechen, dass versucht wird die Kohäsion von Komponenten hoch und die Kopplung möglichst gering zu halten. Wenn SPR, KISS und DRY berücksichtigt werden und gleichzeitig die Kohäsion hoch und die Kopplung geringgehalten wird, ist für die Erweiterbarkeit, Änderbarkeit und Wartbarkeit bereits viel getan. Wenn außerdem Komponenten über Interfaces zugänglich gemacht werden und von der Implementierung abstrahiert wird, hat dies nicht nur Einfluss auf Erweiterbarkeit, Änderbarkeit und Wartbarkeit, sondern auch die Lesbarkeit.
Als Ingenieure sind wir häufig von Technologie begeistert und wollen die neusten Tools, Werkzeuge und Programmiersprachen ausprobieren. Leider benötigen die meisten Unternehmensprojekte nicht das neuste High-End Framework. Daher ist es häufig empfehlenswert auf erprobte Technologien mit etablierten Best Practices zu setzen, um die Langlebigkeit einer Lösung sicherzustellen.
Aus ähnlichen Gründen bietet es sich bei der Wahl zwischen einem opinionated und unopinionated Framework häufig an, das opinionated Framework zu nehmen. Opinionated Frameworks bieten mehr Guidens und erschweren so Wildwuchs. Im Unternehmenskontext sollte eine möglichst langweilige Applikationslandschaft mit vielen gleichen Technologie-Stacks geschaffen werden und nur in sehr seltenen Edge Cases sollte davon abgewichen werden.
