Als Entwickler hören wir oft klischeehafte Sätze wie „Wiederhole dich nicht“. Wir nehmen solche Ideen und laufen mit ihnen, manchmal ein bisschen zu weit.

Es ist hilfreich, zurückzutreten und zu bewerten, warum wir diese Dinge tun. Schauen wir uns heute eine alternative Ideologie zur Trockenprogrammierung an.

DRY ist (laut Wikipedia) definiert als:

Jedes Wissen muss eine einzige, eindeutige, autoritative Repräsentation innerhalb eines Systems haben.

Manches davon mag ein bisschen pedantisch werden, aber das kann hilfreich sein, wenn man so etwas in Betracht zieht. Lassen Sie uns die Teile der Phrasierung dort aufschlüsseln.

Jedes Stück

Was ist „jedes Stück“? Können wir niemals einen Variablennamen wiederholen? Eine HTML-Entität?

Ok, ok. So können wir wiederholen <div> ’s ohne viel Problem und ich glaube nicht, dass jemand beleidigt sein wird. Aber das wirft die Frage auf – wann entscheiden wir, dass etwas zu einem „Stück Wissen“ geworden ist? In React könnte ein gutes Beispiel eine Komponente sein – aber ist das PrimaryButton und SecondaryButton oder bedeutet es eine verallgemeinerte Button Klasse? Die Antwort wird im Allgemeinen als „Was auch immer Ihre Organisation wählt“ angesehen, aber dies kann immer noch ein wenig Unklarheit darüber hinterlassen, was wir abstrahieren möchten.

Wissen

Dies ist ein weiterer zweideutiger Punkt – was definieren wir als Wissen? Betrachten Sie ein gestaltetes Schaltflächenelement mit einigen atomaren Klassen und reagieren Sie. Wenn ein leitender Entwickler 10 Sekunden zum Erstellen benötigt , hält er dieses Wissen möglicherweise nicht für abstrahierbar. Aber für einen Junior-Entwickler, der das System nicht gut kennt, könnte dieses Wissen eine gute Abstraktion sein. Andernfalls müssen sie möglicherweise die Klassen durchsuchen, sich daran erinnern, wie Schaltflächen funktionieren, und die Syntax für ein onClick . Wissen ist relativ und die Verwendung in einer Definition fügt Mehrdeutigkeit hinzu.

Update: Xander hat den folgenden Kommentar unten hinterlassen. Ich denke, dieser Artikel erklärt sehr gut, was „Wissen“ bedeuten sollte.

Ich wollte das hier nur für Leute lassen, die interessiert sind.

„Bei DRY geht es um Wissen, Code-Duplizierung ist nicht das Problem.“
verraes.net/2014/08/dry-is-about-k …

einzelne, eindeutige, maßgebliche Darstellung

Eine „einzelne“ Darstellung lässt zu wünschen übrig. Aus Sicht eines Devops-Ingenieurs kann eine einzelne Darstellung eine gesamte Anwendung sein, die er bereitstellen muss. Für einen Frontend-Entwickler könnte das eine Komponente sein. Und für einen Backend-Entwickler kann dies eine Methode für eine Klasse oder einen API-Endpunkt sein. Wo wird die Grenze gezogen?

Wir haben auch das Wort „eindeutig“ – aber wie ich gerade betont habe, definiert der Rest dieses Satzes mehr Mehrdeutigkeit. „Autoritativ“ ist sinnvoll – Ihr Quellcode sollte genau definieren, was er tut, und dieser Definition entsprechen. Dies ist jedoch nicht explizit auf TROCKENEN Code beschränkt.

system

Endlich haben wir das Welt- „System“ – dies kommt auf die „einzelne“ Aussage zurück, die wir vor einer Sekunde besprochen haben. Was ist ein „System“? In React kann es sich um eine Komponente oder eine Redux-Aktion / Komponente / Reduzierer handeln. Bei containerisierter Software könnte es sich um einen ganzen Pod oder nur um eine einzelne Instanz handeln.

Am Ende des Tages fördert DRY all to oft die Voroptimierung, was unnötig ist und manchmal sogar Ihre Fähigkeit, Code zu schreiben, beeinträchtigt. Manchmal ist es schwieriger, eine abstrahierte Komponente an einen bestimmten Anwendungsfall anzupassen. Sie fügen viel Komplexität hinzu oder brechen diese Komponente in etwas Neues auf – was nicht sehr TROCKEN ist. Sie können nicht jeden Anwendungsfall für Ihre Komponente am ersten Tag kennen.

Eine Alternative – Schreibe alles zweimal (NASSE) Programmierung

Stattdessen schlage ich NASSE Programmierung vor. Für mich wäre die Definition:

Sie können sich fragen: „Habe ich das nicht schon einmal geschrieben?“ zwei Mal, aber nie drei.

Mit dieser Definition entfernt sich der Fokus von der vorzeitigen Optimierung und ermöglicht es Ihnen stattdessen, ähnlichen Code ein paar Mal zu wiederholen. Es verschiebt auch den Fokus auf eine stärkere Darmreaktion. Es ermöglicht Ihnen, Entscheidungen basierend auf dem genauen Anwendungsfall zu treffen, den Sie betrachten. Wenn Sie eine Web-App erstellen, möchten Sie wahrscheinlich Ihre Schaltflächen in eine Komponente abstrahieren, da Sie viele davon verwenden werden. Aber wenn es eine einzelne Seite gibt, die ein spezielles Styling hat (vielleicht eine Preisseite?), dann müssen Sie sich nicht allzu viele Gedanken darüber machen, die Komponenten auf dieser Seite zu abstrahieren. Wenn Sie unter diesem System eine neue Seite benötigen, die dieser speziellen Seite ähnelt, können Sie einfach den benötigten Code kopieren / einfügen und ändern. In dem Moment, in dem dies ein drittes Mal geschieht, ist es jedoch an der Zeit, ein wenig Zeit damit zu verbringen, die Teile zu abstrahieren, die abstrahiert werden können.

Ich würde auch diese Bedingung hinzufügen (sowohl für die NASS- als auch für die Trockenprogrammierung):