Clean Code Developer: 3. Gelber Grad - Zusammenfassung

Also, dann auf zum dritten Grad...

1. Prinzipien

1.1 Interface Segregation Principle

Warum? Leistungsbeschreibungen, die unabhängig von einer konkreten Erfüllung sind, machen unabhängig.

• Interfaces sollten möglichst klein sein, um unnötige Kopplung zu vermeiden.
• Interfaces sollten nur Dinge enthalten, die wirklich eng zusammen gehören (hohe Kohäsion).
• Ziel: möglichst geringe Kopplung ziwschen den Komponenten

1.2 Dependency Inversion Principle

Warum? Punktgenaues Testen setzt Isolation von Klassen voraus. Isolation entsteht, wenn Klassen keine Abhängigkeiten von Implementationen mehr enthalten – weder zur Laufzeit, noch zur Übersetzungszeit. Konkrete Abhängigkeiten sollten deshalb so spät wie möglich entschieden werden. Am besten zur Laufzeit.

• High-Level Klassen sollen nicht von Low-Level Klassen abhängig sein, sondern beide von Interfaces.
• Interfaces sollen nicht von Details abhängig sein, sondern Details von Interfaces.
• Mindestanforderung im 3. Grad: Abhängigkeiten über Konstruktoren injizieren

1.3 Liskov Substitution Principle

Warum? Wer mit Erben zu tun hat, möchte keine Überraschungen erleben, wenn er mit Erblassern vertraut ist.

• Kernaussage: Subtypen müssen sich so verhalten wie ihr Basistyp
• allgemeiner: ein Subtyp darf die Funktionalität eines Basistyps lediglich erweitern, aber nicht einschänken
• Empfehlung: über Vererbung genau nachdenken
  
  • siehe Favor Composition over Inheritance (FCoI), roter Grad
  • bei Vererbung über Verhalten nachdenken, nicht nur über Struktur

1.4 Principle of Least Astonishment

Warum? Wenn sich eine Komponente überraschenderweise anders verhält als erwartet, wird ihre Anwendung unnötig kompliziert und fehleranfällig.

• Software sollte überraschungsarm implementiert sein. Jede Überraschung stellt eine Unterbrechung dar und stört den kreativen Prozess der Softwareentwicklung.
• Die testgetriebene Entwicklung fördert überraschungsarme Schnittstellen.

1.5 Information Hiding Principle

Warum? Durch das Verbergen von Details in einer Schnittstelle werden die Abhängigkeiten reduziert.

• Je mehr Details von außen sichtbar sind, desto höher ist die Kopplung zwischen der Klasse und ihren Verwendern.
• Benutzen die Verwender einer Klasse erstmal ein Detail, wird es schwerer, dieses Detail zu verändern.

2. Praktiken

2.1 Automatisierte Unit-Tests

Warum? Nur automatisierte Tests werden auch wirklich konsequent ausgeführt. Je punktgenauer sie Code testen, desto besser.

• Regressionstests, um Korrektheit von Änderungen sicherzustellen und Angst vor Änderungen zu nehmen
• Automatisierung notwendig, da händisch nicht praktikabel
• Automatisierte Tests sparen Zeit und nehmen Angst.

2.2 Mockups (Testattrappen)

Warum? Ohne Attrappen keine einfach kontrollierbaren Tests.

• Will man eine Komponente isoliert testen, müssen die Abhängigkeiten zu anderen Komponenten abgetrennt werden.
• Beim Isolieren werden sogenannte Mockups anstelle der echten Komponenten verwendet.
• andere Bezeichnungen für Attrappen: Stub, Dummy, Fake (teilweise mit unterschiedlichen Funktionsweisen)

2.3 Code Coverage Analyse

Warum? Traue nur Tests, von denen du weißt, dass sie auch wirklich das Testareal abdecken.

• Unit Tests sollten nach Möglichkeit alle Pfade durch unseren Code abdecken.
• Die Code Coverage Analyse dient dazu, Bereiche im Code aufzudecken, die noch nicht während der automatisierten Tests ausgeführt werden.
• Mögliche Metriken:
  
  • C0-Überdeckung = Anweisungsüberdeckung
  • C1-Überdeckung = Entscheidungs- / Zweigüberdeckung
• Ziel: theoretisch 100% Überdeckung, praktisch mehr als 90% Überdeckung

2.4 Teilnahme an Fachveranstaltungen

Warum? Am besten lernen wir von anderen und in Gemeinschaft.

• Gedankenaustausch, Diskussionen, Erfahrungen austauschen, "über den Tellerrand blicken"
• z.B. regionale User Groups, überregionale Entwicklerkonferenzen

2.5 Komplexe Refaktorisierungen

Warum? Es ist nicht möglich, Code direkt in der ultimativen Form zu schreiben.

• Erweiterung zum roten Grad
• unbedingte Voraussetzung: automatisierte Tests