Atomic Spin

Softwareentwickler sind gut darin, Muster zu erkennen. Vielleicht ist es eine angeborene Fähigkeit, die uns in diesen Beruf zieht. Oder vielleicht ist es der Prozess der Softwareentwicklung, der diese Fähigkeit entwickelt. In jedem Fall ist „Wiederhole dich nicht“ (DRY) eine natürliche Anwendung dieser Fähigkeit.

Wie auch immer, Wiederholung an sich ist nicht der Feind, den dieses Prinzip darstellt.

Don’t Repeat Yourself

So intuitiv „Don’t repeat yourself“ auch sein mag, The Pragmatic Programmer fasst es folgendermaßen zusammen:

Jedes Stück Wissen muss eine einzige, eindeutige, maßgebliche Darstellung innerhalb eines Systems haben.

Es ist nicht schwer, sich die Vorteile einer Reduzierung oder Beseitigung von Wiederholungen vorzustellen.

• Weniger Duplikation bedeutet weniger zu wartenden Code. Und wenn der beste Code gar kein Code ist, klingt das nach einer guten Sache.
• Eine einzige Quelle der Wahrheit verhindert, dass Dinge aus dem Takt geraten. Eine Geschäftsregel hat sich geändert? Aktualisieren Sie sie an einer Stelle, und das war’s.
• Code ist wiederverwendbar. Sie haben einen Prozess, der von drei Dingen geteilt wird, und Sie fügen einen vierten hinzu? Der größte Teil der Arbeit wurde bereits erledigt.

Manchmal wiederholen Sie sich

Wenn man sich zu sehr darum bemüht, scheinbare Doppelarbeit zu vermeiden, kann das mehr Probleme schaffen als lösen. Ich sage „scheinbare Duplikation“, weil manchmal Dinge, die ähnlich aussehen, nicht wirklich miteinander verwandt sind. Zum Beispiel können zwei Datenstrukturen mit identischen Eigenschaften und Typen zwar strukturell, aber nicht semantisch gleich sein.

Eine gängige Strategie zur Reduzierung von doppeltem Code besteht darin, die gemeinsamen Teile herauszufiltern und hinter einer Abstraktion zu verstecken. Ein unerwünschter Nebeneffekt dabei ist jedoch, dass alles, was die Abstraktion verwendet, gekoppelt wird. Jede Änderung an der Abstraktion wirkt sich auf alle ihre Konsumenten aus. Und ebenso kann es sein, dass die Abstraktion gebogen werden muss, um die Anforderungen eines einzigen Konsumenten zu erfüllen.

Diese Zunahme der Kopplung geht auch mit einer Abnahme der Flexibilität einher. Nehmen wir an, Sie haben einen Prozess, der an drei Orten verwendet wird. Er ist an allen drei Orten nahezu identisch, mit nur wenigen wichtigen Unterschieden. Also implementieren Sie den Prozess als ein einziges Modul, das ein paar Parameter benötigt, um die Unterschiede abzudecken.

Eine Anpassung des Prozesses für nur einen einzigen dieser Anwendungsfälle ist nun unmöglich: Jede Änderung an einem wirkt sich auf alle drei aus. Sicher, man kann weitere Parameter (oder Sonderfälle!) hinzufügen, wenn die Anwendungsfälle voneinander abweichen. Aber es wird schnell unmöglich werden, die wichtigen Teile des Prozesses von der Infrastruktur zu unterscheiden, die die Anwendungsfälle trennt.

Fragen, die man sich stellen sollte

Beim Refactoring von bestehendem Code oder beim Schreiben von neuem Code, der möglicherweise dupliziert wird, frage ich mich:

Ist dies ein einzelnes Stück Wissen, das dupliziert wurde, oder ist dies nur eine Infrastruktur, die zufällig ähnlich aussieht?

Sie haben also das CSS durchforstet und eine Klasse gefunden, die zufällig die gewünschten Stile hat. Das ist wahrscheinlich kein ausreichender Grund, um die Definition einer weiteren Klasse zu vermeiden.

Wie oft wurde diese Sache wiederholt?

Solange eine wirklich redundante Sache nicht mindestens dreimal auftaucht, wäre ich sehr skeptisch gegenüber einer Wiederholungsreduzierung, die die Komplexität erhöht.

Wird es durch die Verringerung der Wiederholungen schwieriger, einzelne Fälle in der Zukunft anzupassen?

Es hat etwas Befriedigendes, einen Haufen von Copy-and-Paste-Code in etwas schlankeres und wiederverwendbares umzuwandeln. Aber den Code so eng zu sperren, dass jede Änderung Sonderfälle einführt, ist kein guter Kompromiss.

Wenn ich diese Duplikation reduziere, wie ist das Verhältnis zwischen der Größe der Abstraktion und der Anzahl der Parameter, die sie benötigt?

Bibliotheken und Frameworks sind großartig, weil sie wiederverwendbaren Code mit relativ wenigen Parametern für die Anpassung bieten. Aber stellen Sie sich eine anwendungsspezifische Funktion zur Darstellung eines Dialogfelds vor, die gewachsen ist und jetzt 20 Parameter akzeptiert. Was auch immer der Vorteil der Reduzierung von Wiederholungen war, als sie noch 2 Parameter hatte, ist nicht mehr vorhanden.

Schlussfolgerung

Wie bei vielen Grundsätzen der Softwareentwicklung ist „Wiederhole dich nicht“ eher eine Richtlinie als ein Mantra.