DRY (Don't Repeat Yourself)

Code: Funktionen, Klassen, Module. CSS: Variablen nutzen (--primary-color: blue), statt überall #0000FF schreiben. Datenbank: Normalisierung (Speichere den Namen des Kunden nur in Tabelle Kunden, nicht in jeder Rechnung).

1. WET (Write Everything Twice)

Manchmal ist DRY schlecht. "Duplication is far cheaper than the wrong abstraction." (Sandi Metz). Wenn zwei Klassen zufällig gleich aussehen, aber fachlich nichts miteinander zu tun haben: Verbinde sie nicht. Sonst änderst du später eine Klasse und machst die andere (die nichts damit zu tun hat) kaputt. Warte auf das dritte Mal ("Rule of Three"), bevor du es zusammenfasst.

2. Incidental vs. Essential Duplication

• Essential: Die Logik muss gleich sein (Steuerberechnung). -> DRY anwenden.
• Incidental: Der Code sieht gleich aus, ist aber Zufall (zwei Listen sehen gerade gleich aus, entwickeln sich aber anders). -> DRY vermeiden.

3. DRY in Tests

In Unit Tests ist DRY oft schädlich. Tests sollen lesbar ("DAMP" - Descriptive And Meaningful Phrases) sein. Wenn ich erst in 5 Helper-Funktionen springen muss, um zu verstehen, was der Test testet, ist der Test schlecht. Lieber etwas Copy-Paste im Test-Setup, dafür sofortige Lesbarkeit.

1. Die Metrik der Kupplung (Coupling)

Blindes DRY führt zu exzessivem Coupling (Zusammenbinden) der Code-Knoten. Nehmen wir an, du fusionierst das Formular "Lieferadresse" und "Rechnungsadresse" in eine einzige Mega-Komponente GenericAddressForm(). Genial! Code halbiert. Das Marketing sagt nun: "Rechnungsadresse braucht zwingend ein Feld für die USt-IdNr., außer es ist nach Österreich". Die Lieferadresse braucht hingegen die "Stocwerke / Flur"-Infos außer DHL ist Spediteur. Wenn du all diese Wenn/Aber-Switches per if-statements parametrisierst (Booleans reinknallst), wird GenericAddressForm() zu einem unlesbaren, fragilen Spaghetti-Monster. Du hast Kopplung statt Klarheit geschaffen ("Premature Abstraction is the root of all evil").

2. Das WET und AHA Paradigma in der Praxis

Wenn das DRY-Prinzip kippt, stützen sich Architekten auf Folgekonzepte: WET (Write Everything Twice): Die offizielle Devise der Google-Engineering-Guides. Wiederhole dich bis zu zwei Mal, weil harte Duplikation (Copy/Paste) billiger im Warten ist, als eine fehlerhafte falsche Abstraktionsbrücke einzureißen. AHA (Avoid Hasty Abstractions): Kent C. Dodds Prinzip. Es besagt, dass "ein bisschen Copy/Paste" explizit als Übergangslösung in der Code-History verweilen muss, bis die wirkliche, fundamentale architektonische Überschneidung zweier Module 100% verlässlich geklärt ist. Formt sich das Muster erst nach Monaten exakt ab, zieht man dann die Architektur zueinander (Rule of three).

3. DRY in Datenmodellen (Die 3. Normalform)

DRY in der SQL-Datenbank-Ebene heißt Normalisierung. Wenn du ein E-Commerce-System programmierst, schreibst du in der Tabelle Orders nicht in jeden Kauf "Apple iPad Pro M2 11 Zoll" als String in die Spalte. Ändert der Hersteller den Namen auf "M3", müsstest du (teuer) in einer 500 GB riesigen Table per Regex operieren (Update Anomalie). Du beziehst DRY auf Storage: Man packt den Namen stumpf auf eine id (item_id=4) des Pointers nach Products. Die Information existiert als Single-Source-Of-Truth an einem Ort. Ändert man ihn, updaten sich alle Sales-Kacheln der Invoice-Historie der User simultan.