Der Begriff Clean Code stammt aus der Softwaretechnik und hat seinen Ursprung im gleichnamigen Buch von Robert Cecil Martin, auch bekannt als „Uncle Bob“.
Schlechter Code ist schwer zu verstehen und komplexer als er sein sollte. Häufig ist er auch nicht einfach zu testen und frustriert andere Entwickler. Während es kurzfristig etwas länger dauern kann einen sauberen Code zu schreiben, ist es unbestritten, dass das Schreiben von sauberem Code jedem in einem Team Zeit und Mühe spart und somit letztendlich auch Geld.
Sauberer Code verlässt sich nicht auf sprachspezifische Regeln. Stattdessen gibt es sprachunabhängige Prinzipien und Praktiken, auf die sich die Entwicklergemeinschaft geeinigt hat. Im Folgenden werden wir die wichtigsten Clean Code Regeln hier präsentieren.
KISS: Keep It Simple Stupid
Halte es so einfach wie möglich. Das Prinzip besagt, dass die meisten Systeme so einfach wie möglich gehalten werden sollten (aber auch nicht einfacher, wie Einstein sagen würde). Unnötige Komplexität sollte vermieden werden. Die Frage, die man sich beim Schreiben von Code stellen sollte, lautet: „Kann dies auf einfachere Weise geschrieben werden?“
DRY: Don’t Repeat Yourself
Wiederholungen vermeiden. Eng verwandt mit KISS und einer minimalistischen Designphilosophie. Das Prinzip besagt, dass jeder Code eine einzige und eindeutige Repräsentation innerhalb eines Systems (Codebase) haben muss. Abweichungen von DRY werden als WET bezeichnet: We Enjoy Typing, Write Everything Twice, Waste Everyone’s Time.
YAGNI: You Aren’t Gonna Need It
Man wird es nicht brauchen. Ein Entwickler sollte keine Funktionalität hinzufügen, es sei denn es wird als notwendig erachtet. YAGNI ist Teil einer Methodik, die die Softwarequalität verbessern und die Adaptierbarkeit von Kundenanforderungen erhöhen möchte. YAGNI sollte in Verbindung mit kontinuierlichem Refactoring, Komponententests und Integration verwendet werden.
FCoI: Composition over Inheritance
Bevorzuge Komposition über Vererbung. Für die Wiederverwendung von Funktionalität kennt die objektorientierte Programmierung zwei sehr bekannte Kandidaten: Die Vererbung und die Komposition. Bei dem Prinzip der Komposition verwendet eine Klasse eine andere. Dies fördert die Entkopplung, wenn man dazu eine klar definierte Schnittstelle nutzt. Die Komposition wird von vielen Entwicklern der Vererbung vorgezogen. Hierbei sind Sie gezwungen früh in einem Projekt eine Klassifizierung von Objekten zu erstellen, wodurch Ihr Code für spätere Anpassungen flexibler wird.
Begünstigen Sie die Lesbarkeit:
Nur weil eine Maschine den Code lesen kann, muss dies nicht auch ein anderer Mensch können. Bevorzuge insbesondere bei der Arbeit mit mehreren Personen an einem Projekt immer die Lesbarkeit gegenüber der Prägnanz. Es hat keinen Sinn prägnanten Code zu haben, wenn die Leute ihn nicht verstehen. Es gibt viele Möglichkeiten Ihren Code lesbarer zu machen. Zwei Beispiele sind das Platzieren allgemeiner Zahlen in wohlbekannten Konstanten und das Erstellen von längeren Namen, die aussagekräftiger gegenüber von kürzeren Namen sind.
Clean Code Praxiskonsistenz:
Dies ist wohl das übergreifende Prinzip aller Clean-Code-Prinzipien. Wenn man sich dazu entscheidet etwas auf eine bestimmte Weise zu tun, sollte man auch während des gesamten Projekts dabeibleiben. Wenn man keine andere Wahl hat, sollte man in den Kommentaren erklären, warum man von der ursprünglichen Wahl abgewichen ist.
Version Control System:
Es ist essenziell wichtig seinen Code unter den Schutz eines Versionskontrollsystems zu stellen. Ob dies nun Git, Subversion oder ein anderes System ist, spielt dabei keine Rolle. Hier geht es nur darum, dass keine Arbeit an Code durchgeführt werden sollte, ohne ihn in einem Versionskontrollsystem zu pflegen. Der Grund dafür ist einfach: Ein Versionskontrollsystem nimmt dem Entwickler die Hemmungen, Änderungen an der bestehenden Codebase durchzuführen. Das ist allerdings nötig, um die Clean-Code-Prinzipien konsequent anzuwenden.
Root Cause Analysis:
Im Sinne von Clean Code sollte es immer das Ziel sein, die wahre Wurzel der Ursache eines Problems zu finden und diese zu eliminieren. Man sollte sich hier nicht mit einer oberflächlichen Behandlung des Problems beschäftigen. Ein Beispiel dazu: Es sollen Daten im Speicher sortiert werden, die Sortierung ist jedoch zu langsam. Oberflächlich könnte man dies nun behandeln, indem man versucht einzelne Anweisungen und Funktionen zu beschleunigen oder auch eine Parallelisierung in der Verarbeitung zu probieren. Eine genauere Analyse des Problems hätte jedoch ergeben, dass ein naiver und nicht optimierter Algorithmus die Problemursache ist. Diesen zu verbessern ist die saubere Lösung, statt schwerer verständliche Optimierungen auf niedrigeren Abstraktionsebenen durchzuführen.
Unit Tests
Beim Schreiben von Clean Code sollten die sogenannte Unit Tests nicht fehlen. Hierbei werden die einzelnen Einheiten auf ihren ordnungsgemäßen Betrieb hin überprüft, sodass festgestellt werden kann, ob der Code wie beabsichtigt funktioniert. Vor allem bei der agilen Software Entwicklung ist das häufige Ausführen von Unit Test eine wichtige Maßnahme, da dadurch die Qualität der Software gesichert wird.
Boy Scout Rule:
Zum Fundament des Clean Code gehört eine Faustregel, die sich auch im Buch von Robert C. Martin befindet: „Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast.“ Auf die Software Entwicklung angewendet bedeutet dies, dass Code immer eher den Clean-Code-Prinzipien entsprechend hinterlassen werden sollte.
Clean Code bei ISEO
Ob App oder Software: Unsere Entwickler halten sich an die oben genannten Regeln und programmieren Softwarelösungen in hoher Qualität. Schaue dir hier die Leistungen innerhalb unserer Individualprogrammierung an und sichere dir eine kostenlose Erstberatung für dein digitales Vorhaben.
