DRY - Don't Repeat Yourself

Hinter der Abkürzung DRY versteckt sich die Aufforderung »Don’t Repeat Yourself«. Das ist nicht weniger als die Basis für einen sauberen Programmierstil. Nur Programme ohne Wiederholungen sind übersichtlich und sauber. Jegliche Logik wird nur einmal implementiert. Egal ob Du Einsteiger oder fortgeschritten bist, das DRY-Prinzip ermöglicht es Dir, bessere Software zu schreiben.

DRY in der Theorie

Die Theorie hinter der DRY-Idee ist denkbar einfach zu erklären. Viel ergänzender Worter Bedarf es nicht, um die Bedeutung von »Don’t Repeat Yourself« zu erschließen. Übersetzt kannst Du Dir merken »Wiederhol Dich nicht«. Mit dieser Aufforderung im Hinterkopf verbesserst Du Deinen Code, spätestens beim Code Review.

Gibt es denn häufig Wiederholungen? Vielleicht hast Du die noch nie wahrgenommen? Und, sind sie wirklich vermeidbar? Ja und ja! Es gibt verschiedene Situationen, in denen in der Praxis Logik wiederholt wird. Im Buch der pragmatische Programmierer unterscheiden Andrew Hunt und David Thomas folgende Fälle.

Erzwungene Wiederholungen sind die erste Kategorie, in denen der Entwickler das Gefühl hat, es gibt keine alternative Lösung für sein Problem. Die sind, aus meiner Erfahrung, immer das Problem einer unzureichenden Architektur. Wer das Gefühl hat, es geht nicht anders, sollte das Blickfeld erweitern und einen Blick aus der »Vogelperspektive« auf die gesamte Software werfen. Dadurch erkennt man notwendige Änderungen an der Struktur, die das Problem beheben.

Unabsichtliche Wiederholungen sind die zweite Kategorie. Die sind schwieriger zu finden, da sie unabsichtlich passieren. Direkt bei der Entwicklung fallen solche unsauberen Stellen meist nicht auf. Mit ist ein Grund, warum es wichtig ist, dass Du Dir geschriebenen Code, mit etwas Abstand, noch einmal anschaust. Das nennt man Code-Review (sinnhaft übersetzt: Code-Sichtung oder Durchsicht).

Wiederholungen aus Ungeduld sind eine große Gefahr, wenn sich eine Deadline nähert. Kompromisse oder Abstriche bei der Architektur werden häufig in der Endphase eine Projektes eingegangen. Kurz gesagt: Nicht machen! Auch hier kann ich aus Erfahrung berichten, dass sich solche Fehlentscheidungen später um ein Vielfaches rächen! Die marginale Zeitersparnis bezahlt man teuer. Also immer mit Disziplin arbeiten.

Wiederholungen durch mehrere Entwickler entstehen dann, wenn keine ausreichende Planung gegeben ist. Die einzelnen Teile eine Software werden im Team entwickelt. Gemeinsam genutzte Objekte, Methoden, Funktionen, Schnittstellen und Bibliotheken müssen jedoch abgesprochen werden. Die doppelte Entwicklung von Logik wird am besten durch ausreichend Kommunikation verhindert.

DRY in der Praxis

Was bedeutet das also für Dich als Entwickler in der Praxis? Eigentlich ganz einfach. Es gibt drei Punkte, die Dir helfen.

Zum einen solltest Du Dich bei Lösungen immer an den Gepflogenheiten der genutzten Programmiersprache orientieren. Die Paradigmen, die eine Sprache mitbringt, helfen meist bei der Auflösung von strukturellen Problemen.

Außerdem muss schon vorab ausreichend geplant werden. Nur ein guter Entwurf ermöglicht eine passende Software Architektur. Das bedeutet also, dass vor der ersten Codezeile theoretisch erarbeitet wird, was eigentlich benötigt wird. Welche Erweiterungen soll es geben? Was ist das Ziel? Wie wird die Software genutzt? Welche Art von Anwendern gibt es? Die sogenannten W-Fragen helfen Dir ungemein!

Wiederverwendbarkeit hilt! Versuch jeden Teil einer Software so zu schreiben, dass er auch für jedes Projekt verwendet werden könnte. Es gibt natürgemäß Stellen, die sich auf ein konkretes Projekt beziehen. Man kann jedoch sehr viel wiederverwendbaren Code entwickeln. Das führt fast automatisch dazu, dass sich Wiederholungen minimieren, gerade unabsichtliche.

Ein paar Worte

Wir haben dazu auch ein Video für euch vorbereitet, in dem noch einmal das Thema DRY angesprochen wird. Viel Spaß dabei!

Du bist herzlich eingeladen, unseren Youtube Channel zu abonnieren, unsere Videos zu bewerten oder Kommentare zu hinterlassen! Wir freuen uns riesig!

Kommentare (3)

  • Roth

    4 Jahren ago

    Dry habe ich noch nie gehört. Ich habe vor sehr langer Zeit Basic gelernt. Wo eine Aufgabe gestellt und ein Ziel gesetzt wurde.
    Wir haben mehr Zeit mit Planung verwendet, als mit der eigentlichen Programmierung.Das hatte auch damit zu tun, das wir zu dritt!!! an einem Comodore c64 mit Datasette gearbeitet hatten. Der Lehrer hatte vom Sperrmüll die Fernseher sich geholt und dann selber repariert. Die meisten mussten den Computer von Zuhause mitbringen. Somit war der Erste EDV Kurs geboren. Eine strickte Arbeitseinteilung war da natürlich notwendig. Das Programm wurde erst auf ein stück Papier geschrieben und dann in den Computer eingegeben. Die Rem Zeilen, (Kommentare) waren überflüssig, weil mit 64K der Speicher sehr begrenzt war.
    Ich kann mich sehr gut an Diagramme erinnern mit Raute, If – then Anweisung und Programmablauf. Eingabe und Ausgabe. Arbeitsrutinen die immer wiederhohlt werden.
    Diese Rotinearbeiten werden jetzt in einer anderen Form dargeboten.
    Jetzt habe ich dies bei conrad Elektronik wiederentdeckt. Natürlich in verbesserter Form basic ++
    Leider bin ich beim Programmieren ein bischen eingerostet. Ich hätte schon gerne Hilfe mit den „Programmplan“ (Dry), weil es gerade dafür sehr wenig Literatur gibt. Vielleicht können sie mir ein Buch oder ein Link empfehlen.

    MfG Eugen

    • Jan Brinkmann

      4 Jahren ago

      Vielen Dank für den Kommentar! DRY ist ein Paradigma, eine Idee. Die kann in jeder Programmiersprache angewandt werden. Es geht darum, keinen Quellcode und keine Logik mehrfach zu implementieren. Ein gutes Buch zu dem Thema:

  • Roth

    4 Jahren ago

    Um ein Programm logisch aufzubauen (ohne Wiederholungen) sollte man immer ein Programmablaufplan erstellen.
    Link:http://de.wikipedia.org/wiki/Programmablaufplan

    Das ist das Fundament für allen Anfang. Bei der Entwicklung dieses Diagramms sind natürlich Spezielle Fragen notwendig, die sehr aufwendig sind.
    Sie haben es ja schon angedeutet.
    Es ist völliger Schwachsinn erst ein Programm zu schreiben und dann ein Diagramm zu erstellen. Die Leute die das machen haben denn Sinn von einem Flussdiagram oder Ablaufplan nie verstanden.

Leave a Comment to Jan Brinkmann Cancel reply

Your email address will not be published.