Ich stell hier mal meine Notizen zu CleanCode rein.
Evtl. ist es für jemanden interessant (der das buch noch nicht kennt) oder jemand bemerkt einen Fehler bei mir (Falsches oder Vergessenes)
Es ist nur eine Liste der wichtigsten Prinzipien und Praktiken von Cleancode an die man sich halten sollte. Detailinfos muss man sich selbst im Netz ziehen.
http://clean-code-developer.de/
Evtl. ist es für jemanden interessant (der das buch noch nicht kennt) oder jemand bemerkt einen Fehler bei mir (Falsches oder Vergessenes)
Es ist nur eine Liste der wichtigsten Prinzipien und Praktiken von Cleancode an die man sich halten sollte. Detailinfos muss man sich selbst im Netz ziehen.
DRY – Dont Repeat Yourself
KISS – Keep it simple, stupid
YAGNI – You ain´t gonna need it
FcoI – Favour Composition over Inheritance
SLA – Single Level Abstraction
SRP – Single Responsibility Principle
SoC – Seperation of Concers
OCP – Open Closed Principle
ISP – Interface Segregation Principle
DIP - Dependency Inversion Principle
LSP – Liskov Substitution Principle
POLA - Principle of Least Astonishment
IHP - Information Hiding Priciple
Tell, don´t ask
Law of Demeter – Don´t talk to strangers
Pfadfinderregel
Issu Tracking
Iterative Entwicklung
Root Cause Analysis
Optimierungen
Source Code Conventions
Implementation und Entwurf überlappen nicht
Implementation spiegelt Entwurf
Komponentenorientierung (Contract-first-design)
Inversion of Control – Container
Continuous Integration & Delivery
Refaktorisierung durch
Automatisierte Integrationstests
Automatisierte Unit Tests
Mockups (SUT) System Under Tests
Code Coverage
Code Reviews
Statische Codeanalysen
Test first
- Wiederholung vermeiden, erkennen und auflösen
KISS – Keep it simple, stupid
- einfach und verständlich schreiben, PairProg sinnvoll
YAGNI – You ain´t gonna need it
- Entscheide erst zur letzten Möglichkeit, bei Zweifel immer dagegen
- Fokus auf Aufwand/Kosten/Nutzen aus Kundensicht
FcoI – Favour Composition over Inheritance
- Komposition der Vererbung vorziehen
SLA – Single Level Abstraction
- Pro Funktion nur ein Abstraktionslevel /-niveau verwenden
- Funktionen nach Level(wie Zeitung) aufbauen: Einfach, Details, Rest
SRP – Single Responsibility Principle
- Pro Klasse nur eine Verantwortlichkeit/Aufgabe
SoC – Seperation of Concers
- Übermengen von Verantwortlichkeiten trennen, nicht mischen
- Klare Aufgaben für „Code-Einheiten“
OCP – Open Closed Principle
- Offen für Erweiterungen, geschlossen für Modifikationen
ISP – Interface Segregation Principle
- Interfaces klein halten, wenn nötig aufsplitten, Doppellungen möglich
- Nur Funktionen die der User wirklich benötigt
DIP - Dependency Inversion Principle
- Auf Ebenen bei Vererbung achten, keine vertauschte Abhängigkeit erzeugen
- Hohe Ebene gibt Interface vor, niedrige Ebene verwendet Interface
LSP – Liskov Substitution Principle
- Verhalten der Basisklasse berücksichtigen
- Erben dürfen übernehmen und erweitern, aber nicht einschränken
POLA - Principle of Least Astonishment
- Überrasche niemals den User
IHP - Information Hiding Priciple
- sichtbare Details immer soweit wie möglich einschränken
Tell, don´t ask
- ohne öffentliche Details entstehen Objekte mit Verhalten
Law of Demeter – Don´t talk to strangers
- Methoden verwenden der: eigene Klasse, Parameter, Superklasse, selbst erst. Obj.
Pfadfinderregel
- Hinterlasse einen Ort immer in einem besseren Zustand
Issu Tracking
- alle Aufgaben notieren: erinnern, überwachen, delegieren, priorisieren
Iterative Entwicklung
- jede Phase liefert Erkenntnisse für die Phase davor
- klar definierte Iterationsziele
Root Cause Analysis
- Frage mindestens 5x „Warum?“ (5-Why´s)
Optimierungen
- Verständlichkeit (Lesbarkeit) und Evolvierbarkeit (Grundstruktur für Modifikationen)
- Grund, Nutzen, Messung immer 2x überdenken -> YAGNI
Source Code Conventions
- PSR nutzen und einhalten
Implementation und Entwurf überlappen nicht
- dünne Schnittstelle für Kommunikation und Anpassungen pflegen
Implementation spiegelt Entwurf
- physische Codeeinheiten entwerfen und implementieren
Komponentenorientierung (Contract-first-design)
Inversion of Control – Container
- automatisches Laden der Abhängigkeiten
Continuous Integration & Delivery
Refaktorisierung durch
- Einfach: „Methode extrahieren“ und „Umbenennen“
- Komplex: Integration von Tests
Automatisierte Integrationstests
- Frontend und Backend
Automatisierte Unit Tests
Mockups (SUT) System Under Tests
Code Coverage
- welcher Code wird nocht nicht getestet <90% sehr schlecht
Code Reviews
- 4-Augen-Prizip → KISS
Statische Codeanalysen
Test first
Kommentar