Clean Coding Techniques — SOLID, Defensive Programming, DDD, Testable Code

Schlecht gestalteter Code, der „funktioniert", ist eine technische Schuld, die mit der Zeit immer teurer wird. Saubere Code-Praktiken sind nicht nur Ästhetik — sie sind Effizienz, Funktionalität und bessere Arbeitsweise. Dieser Kurs richtet sich an Entwickler aller Erfahrungsstufen und vermittelt die Prinzipien, die guten Code von schlechtem unterscheiden. Block Introduction to Clean Coding: was bedeutet Clean Code (lesbar, einfach, wartbar, testbar, intentional), die Kosten von schlechtem Code (geringere Produktivität, mehr Bugs, höhere Onboarding-Zeit für neue Entwickler, Burnout im Team), Boy-Scout-Rule (lasse den Code besser zurück, als du ihn vorgefunden hast), Naming Conventions (intent-revealing Names, vermeide Misleading Names, sinnvolle Abkürzungen). Block Funktionen schreiben: Small Functions (Robert C. Martin: 4-5 Zeilen ideal, 20+ ist zu groß), Do One Thing (Single Responsibility auf Funktions-Level), wenig Parameter (idealerweise 0-3, never mehr als 7), keine versteckten Side Effects, Command-Query-Separation (Funktion macht entweder oder gibt zurück, nicht beides). Block Defensive Programming: Input Validation (Trust Boundaries — wo verlassen Daten/wo betreten sie das System), Null-Safety (Optional in Java, Option in Rust, ? in TypeScript, NotNull-Attribute), Error Handling vs. Exception Handling (Exceptions nur für wirklich exceptional Fälle, nicht für erwartete Failures), Assertions als Dokumentation von Invarianten, Fail-Fast statt Silent-Failure. Block Model-View-Controller (MVC): Separation of Concerns als zentrales Prinzip, Model (Daten + Business-Logik), View (UI), Controller (Steuerung), MVP und MVVM als Varianten, häufige Fallen (Fat Controllers, Anemic Models). Block Domain-Driven Design (DDD): Ubiquitous Language (gleiche Begriffe zwischen Tech und Business), Bounded Contexts (Domain in Sub-Bereiche zerlegen), Aggregates und Aggregate Roots, Domain Events, Repositories für Persistence-Abstraktion. Block SOLID-Prinzipien: Single Responsibility Principle (jede Klasse hat genau einen Grund, sich zu ändern), Open-Closed Principle (offen für Erweiterung, geschlossen für Modifikation — meist via Vererbung/Composition), Liskov Substitution Principle (Subtypen müssen für Basistypen einsetzbar sein), Interface Segregation Principle (viele kleine Interfaces statt eines großen), Dependency Inversion Principle (depend on abstractions, not concretions). Block Testable Code: Unit-Tests als Spec, Test-Driven Development (TDD: Red-Green-Refactor-Cycle), Pure Functions als ideal (gleiche Inputs → gleiche Outputs, keine Side Effects), Dependency Injection statt new (für Testbarkeit), Mocking vs. Stubbing, Test Pyramid (viele Unit-Tests, weniger Integration-Tests, wenige E2E-Tests). Block Code Smells erkennen: Long Methods, Large Classes, Duplicate Code, Long Parameter Lists, Feature Envy, Data Clumps, Primitive Obsession, Switch Statements, Lazy Class, Speculative Generality.