Warum man Codeduplizierung nicht zu früh entfernen sollte
- Wenn das DRY-(Don't Repeat Yourself)-Prinzip zu strikt angewendet wird, kann es zu „premature“ Abstraktion führen, was spätere Änderungen komplexer machen kann
- Man sollte überlegen, ob die Duplizierung wirklich unnötig ist oder ob es sich um Funktionen handelt, die sich im Lauf der Zeit unabhängig weiterentwickeln werden
- Auch wenn Funktionen oder Klassen identisch erscheinen, können sie unterschiedliche Kontexte und Business-Anforderungen haben
- Wichtiger als den Code kürzer zu machen ist die Frage, ob der Zweck einer Funktion im Lauf der Zeit bestehen bleibt
- Risiken der Abstraktion: Wenn sich Funktionen wahrscheinlich unterschiedlich entwickeln werden, kann Abstraktion eher schädlich sein.
- Beim Entwurf von Abstraktionen sollte man Verhaltensweisen, die sich langfristig getrennt entwickeln könnten, nicht frühzeitig koppeln
- Im Zweifel sollte man Verhaltensweisen getrennt halten, bis sich im Lauf der Zeit genügend gemeinsame Muster zeigen, die eine Kopplung rechtfertigen
- In kleinem Maßstab kann es einfacher sein, Duplizierung zu verwalten, als die Komplexität vorzeitiger Abstraktion zu lösen
- Gerade zu Beginn der Entwicklung sollte man etwas Duplizierung zulassen und mit der Abstraktion warten
- Künftige Anforderungen sind oft nicht vorhersehbar
- Man sollte über das YAGNI-(You Aren't Gonna Need It)-Prinzip nachdenken
- Die Duplizierung wird entweder kein Problem sein oder mit der Zeit klar zeigen, dass eine gut durchdachte Abstraktion nötig ist
10 Kommentare
Ursprünglich sollte man DRY anwenden, indem man Wiederholungen reduziert, wenn sie tatsächlich auftreten,
aber wenn man Code von vornherein nach diesem Maßstab denkt, scheint das eine falsche Anwendung zu sein.
Unter den Meinungen auf Hacker News
finde ich diese am nachvollziehbarsten:
Ein Missverständnis des DRY-Prinzips: DRY soll nicht Code-Duplizierung, sondern die Duplizierung von Informationen/Wissen verhindern. Wenn man sich nur auf Code-Duplizierung konzentriert, kann das zu unnötiger Optimierung führen.
Hat man sich in Übergangsphasen nicht oft genau solche Gedanken gemacht? Perfekten Code gibt es nicht, also ist es wohl unser Job, uns ständig darüber den Kopf zu zerbrechen. Ich glaube, das hängt vom jeweiligen Fall ab.
In letzter Zeit tauchen immer wieder Texte auf, die Strukturen mit hohem Abstraktionsgrad skeptisch betrachten.
MSA, Clean Code, SOLID, DRY und so weiter ...
Ich habe den Eindruck, dass die Leute von solchen Begriffen allmählich ermüdet sind.
Tatsächlich sind das aber nur Wegweiser, an denen man sich orientieren kann, wenn man darüber nachdenkt, Code zu schreiben, der leicht zu lesen und zu verstehen ist, keine Speicherlecks hat, ohne Fehler läuft und schnell ist ...
Man muss sie eben mit Augenmaß und passend zur eigenen aktuellen Business-Situation anwenden.
https://velog.io/@kineo2k/…
Ein wirklich großartiger Artikel.
Gerade beim Wechsel vom Wasserfallmodell zum agilen Modell scheint das besonders wichtig zu sein.
Obwohl man agil arbeitet, versucht man die Zukunft zu sehr vorherzusagen.
Wie eilig muss es sein, damit es „vorschnell“ ist?
Die Antwort ist ganz einfach. Wenn man es einfach von Anfang an macht, ist es „verfrüht“.
Die etwas schwierigere Frage ist, wann man es tun sollte, damit es nicht „verfrüht“ ist.
Ein Wortspiel, aber wenn man es einfach von Anfang an nicht tut, wäre es wohl „nicht voreilig“^^;
Ja, besonders im Agilen.
Hacker-News-Kommentar
Frühe Anwendung des DRY-Prinzips: Es ist gut, das DRY-Prinzip von Anfang an anzuwenden. Statt ähnliche Daten getrennt zu behandeln, ist es effizienter, eine gemeinsame Codebasis zu verwenden.
Prioritäten bei Best Practices: Nicht alle Best Practices sind gleich wichtig. Es ist entscheidend, Lesbarkeit und Kohäsion zu priorisieren. Code zu schreiben ist der Prozess, die jeweils beste Praxis auszuwählen.
Missverständnis des DRY-Prinzips: Bei DRY geht es darum, die Duplizierung von Informationen/Wissen zu vermeiden, nicht von Code. Wenn man sich nur auf Code-Duplizierung konzentriert, kann das zu unnötiger Optimierung führen.
Probleme mit Wiederverwendbarkeit: Es gibt Fälle, in denen eine bestimmte Funktion in anderen Situationen nicht wiederverwendet wird. Um doppelte Arbeit zu vermeiden, ist ein besserer Ansatz nötig.
Probleme komplexer DRY-Lösungen: Manchmal ist wiederholter Code besser als eine komplexe DRY-Lösung. DRY zu früh anzuwenden kann zu unerwarteten strukturellen Problemen führen.
DRY ist keine Best Practice: Wiederholung ist oft ein Signal dafür, dass eine Abstraktion nötig ist. DRY unüberlegt anzuwenden, ist ein häufiger Fehler von Engineers auf mittlerem Niveau.
Ein einfaches Codebeispiel: Zwei Funktionen können zu einer einzigen Funktion zusammengeführt werden. Es ist wichtig, die Vor- und Nachteile des Refactorings klar zu erklären.
Wartungsprobleme bei DRY-Code: DRY-Code kann komplex werden und dadurch schwer wartbar sein. WET-Code ist dagegen einfacher, aber Änderungen sind besser vorhersehbar.
Nebenwirkungen des DRY-Prinzips: Das DRY-Prinzip kann eine Codebasis komplexer machen und die Wartung erschweren. Einige Clean-Code-Bücher haben der Branche negative Auswirkungen beschert.
Generalisierung und Performance: Generalisierung kann sich negativ auf die Performance auswirken. Code-Duplizierung, die auf bestimmte Datenmuster zugeschnitten ist, kann bei der Performance-Optimierung helfen.