En tant que développeurs, nous entendons souvent des phrases clichées comme « Ne vous répétez pas ». Nous prenons des idées comme celle-ci et courons avec elles, parfois un peu trop loin.

Prendre du recul et évaluer pourquoi nous faisons ces choses est utile. Alors aujourd’hui, regardons une idéologie alternative à la programmation SÈCHE.

DRY est défini (selon Wikipedia) comme:

Chaque connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein d’un système.

Une partie de cela peut devenir un peu pédante, mais cela peut être utile lorsque vous envisagez quelque chose comme ça. Décomposons les parties du phrasé là-bas.

Chaque pièce

Qu’est-ce que « chaque pièce »? Ne pouvons-nous jamais répéter un nom de variable? Une entité HTML ?

Ok, ok. Nous pouvons donc répéter <div> sans trop de problème et je ne pense pas que quiconque s’en offusquera. Mais cela soulève la question – quand décidons-nous que quelque chose est devenu un « savoir »? Dans React, un bon exemple peut être un composant – mais est-ce que PrimaryButton et SecondaryButton ou cela signifie-t-il une classe Button généralisée? La réponse est généralement considérée comme « Quel que soit le choix de votre organisation », mais cela peut encore laisser une bonne part d’ambiguïté sur ce que nous choisissons d’abstraire.

connaissance

Ceci est un autre point ambigu – que définissons-nous comme connaissance? Considérez un élément bouton stylé utilisant certaines classes atomiques et Réagissez. S’il faut 10 secondes à un développeur senior pour créer, il peut ne pas considérer que cette connaissance mérite d’être résumée. Mais pour un développeur plus junior qui ne connaît pas bien le système, cette connaissance pourrait être une bonne abstraction. Sinon, ils pourraient devoir traquer les classes, se rappeler comment fonctionnent les boutons et comprendre la syntaxe d’un onClick. La connaissance est relative et son utilisation dans une définition ajoute de l’ambiguïté.

Mise à jour: Xander a laissé le commentaire suivant ci-dessous. Je pense que cet article explique très bien ce que « connaissance » devrait signifier.

Je voulais juste laisser ceci ici pour les personnes intéressées.

« DRY est une question de connaissance, la duplication de code n’est pas le problème. »
verraes.net/2014/08/dry-is-about-k…

représentation unique, sans ambiguïté et faisant autorité

Une représentation « unique » laisse beaucoup à désirer. Du point de vue d’un ingénieur devops, une seule représentation peut être une application entière qu’il doit déployer. Pour un dev frontend, cela pourrait être un composant. Et pour un dev backend, cela peut être une méthode sur une classe ou un point de terminaison API. Où se dessine la ligne?

Nous avons aussi le mot « sans ambiguïté » – mais comme je viens de le souligner, le reste de cette phrase définit plus d’ambiguïté. « Faisant autorité » a du sens – votre code SEC doit définir exactement ce qu’il fait et être fidèle à cette définition. Cependant, cela n’est pas explicitement limité au code sec.

system

Enfin, nous avons le « système » mondial – cela revient à la déclaration « unique » dont nous avons discuté il y a une seconde. Qu’est-ce qu’un  » système  » ? Dans React, il peut s’agir d’un composant ou d’une action/composant/réducteur Redux. Dans les logiciels conteneurisés, nous pourrions parler d’un pod entier ou d’une seule instance.

À la fin de la journée, DRY all to favorise souvent la pré-optimisation, ce qui est inutile et nuit parfois à votre capacité à écrire du code. Il est parfois plus difficile de modifier un composant abstrait pour s’adapter à un cas d’utilisation spécifique. Vous ajoutez beaucoup de complexité ou vous décomposez ce composant en quelque chose de nouveau – qui n’est pas super sec. Vous ne pouvez pas connaître tous les cas d’utilisation de votre composant le premier jour.

Une alternative – Écrivez tout deux fois (programmation HUMIDE)

À la place, je propose une programmation HUMIDE. Pour moi, la définition serait:

Vous pouvez vous demander « N’ai-je pas écrit cela avant? » deux fois, mais jamais trois.

Avec cette définition, le focus s’éloigne de l’optimisation prématurée et vous permet à la place de répéter un code similaire plusieurs fois. Cela déplace également l’accent sur une réaction plus intestinale. Il vous permet de prendre des décisions en fonction du cas d’utilisation exact que vous examinez. Si vous créez une application Web, vous souhaitez probablement abstraire vos boutons en un composant, car vous allez en utiliser beaucoup. Mais s’il y a une seule page qui a un style spécial (peut-être une page de tarification?), alors vous n’avez pas à vous soucier trop de l’abstraction des composants sur cette page. En fait, sous ce système, si vous aviez besoin d’une nouvelle page similaire à cette page spéciale, vous pouvez simplement copier / coller et modifier le code dont vous avez besoin. Cependant, au moment où cela se produit une troisième fois, il est temps de passer un peu de temps à abstraire les parties qui peuvent être abstraites.

J’ajouterais également cette stipulation (à la programmation HUMIDE et SÈCHE):