Atomic Spin

Les développeurs de logiciels sont doués pour reconnaître les modèles. C’est peut-être une compétence inhérente qui nous attire vers cette profession. Ou peut-être que c’est le processus d’écriture de logiciels qui développe cette compétence. Quoi qu’il en soit, « ne pas se répéter » (DRY) est une application naturelle de cette compétence.

Cependant, la répétition en elle-même n’est pas l’ennemi que ce principe fait passer pour tel.

Don’t Repeat Yourself

Aussi intuitif que puisse être le « don’t repeat yourself », The Pragmatic Programmer le résume ainsi :

Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d’un système.

Il n’est pas difficile d’imaginer les avantages de la réduction ou de l’élimination des répétitions.

• Moins de duplication signifie moins de code à maintenir. Et si le meilleur code est l’absence de code, cela semble être une bonne chose.
• Une source unique de vérité élimine la possibilité que les choses soient désynchronisées. Une règle de gestion a changé ? Mettez-la à jour à un seul endroit, et c’est terminé.
• Le code est réutilisable. Vous avez un processus qui est partagé par trois choses, et vous en ajoutez une quatrième ? La plupart du travail a déjà été fait.

Parfois, répétez-vous

S’acharner à réduire la duplication apparente peut créer plus de problèmes que cela n’en résout. Je dis « duplication apparente » parce que parfois, des choses qui semblent similaires ne sont pas réellement liées. Par exemple, deux structures de données avec des propriétés et des types identiques peuvent être les mêmes structurellement mais pas sémantiquement.

Une stratégie commune pour réduire le code dupliqué est de factoriser les parties communes et de les cacher derrière une abstraction. Mais un effet secondaire indésirable de ceci est qu’il couple tout ce qui utilise l’abstraction. Tout changement dans l’abstraction affecte tous ses consommateurs. Et de même, l’abstraction peut avoir besoin d’être pliée pour répondre aux exigences d’un seul consommateur.

Cette augmentation du couplage s’accompagne également d’une diminution de la flexibilité. Disons que vous avez un processus qui est utilisé dans trois endroits. Il est presque le même dans les trois endroits, avec seulement quelques différences importantes. Vous implémentez donc le processus comme un module unique qui prend quelques paramètres pour couvrir les différences.

Travailler le processus pour un seul de ces cas d’utilisation est maintenant impossible : toute modification de l’un affecte les trois. Bien sûr, vous pouvez ajouter d’autres paramètres (ou des cas particuliers !) à mesure que les cas d’utilisation divergent. Mais il deviendra rapidement impossible de distinguer les parties importantes du processus de l’infrastructure qui sépare les cas d’utilisation.

Questions à poser

Lorsque je refacture du code existant ou que j’écris du nouveau code qui peut potentiellement être dupliqué, je me demande :

S’agit-il d’une seule pièce de connaissance qui a été dupliquée, ou s’agit-il simplement d’une infrastructure qui se trouve être similaire ?

Donc vous avez fouillé dans le CSS et trouvé une classe qui se trouve avoir les styles que vous voulez. Ce n’est probablement pas une raison suffisante pour éviter de définir une autre classe.

Combien de fois cette chose a été répétée?

Jusqu’à ce qu’une chose vraiment redondante apparaisse au moins trois fois, je serais très sceptique sur toute réduction-répétition qui augmente la complexité.

La réduction de la duplication maintenant rendra-t-elle plus difficile la personnalisation des cas individuels à l’avenir ?

Il y a quelque chose de satisfaisant à refacturer un tas de code copié-collé en quelque chose de plus rationalisé et réutilisable. Mais verrouiller le code si étroitement que tout changement introduirait des cas particuliers n’est pas un bon compromis.

Si je réduis cette duplication, quel est le rapport entre la taille de l’abstraction et le nombre de paramètres qu’elle prendra?

Les bibliothèques et les frameworks sont formidables parce qu’ils fournissent un code réutilisable avec relativement peu de paramètres pour la personnalisation. Mais imaginez une fonction spécifique à une application pour présenter une boîte de dialogue qui a grandi et accepte maintenant 20 paramètres. Quel que soit l’avantage de réduction de la répétition qui existait lorsqu’elle avait 2 paramètres, il n’existe plus.

Conclusion

Comme pour de nombreux principes de développement de logiciels, « ne vous répétez pas » est une ligne directrice plus qu’un mantra.