Ouarzy's Blog

Ouarzy's Blog

DRY, ce faux ami

Don’t Repeat Yourself. Tout développeur qui se respecte connaît ce principe qui veut que, au nom de la sainte réutilisabilité, on ne répète jamais un code identique. Evidemment ça semble une excellente idée, mais revoyons la définition donnée par Wikipédia: « Chaque partie du système doit avoir une représentation qui fait autorité, unique et non ambigu ». 

 

Le principal problème, c’est que suivant votre contexte, la définition d’un objet peut devenir ambigu, ou non. Par exemple un utilisateur ou un client… Suivant le contexte de ce que vous voulez réaliser, il se peut qu’il soit plus judicieux de multiplier les classes clients (en les renommant), plutôt que de faire une seule classe qui gère toutes les problématiques du métier liées à un client.

 

Au final, seul le métier est capable de dire si un objet a une représentation ambigu. Et malheureusement trop peu de développeurs prêchant le DRY s’occupent du métier. (Probablement trop peu de développeurs tout court, mais c’est une autre histoire)

 Unique1.jpg

Au contraire, il s’agit la plupart du temps d’une vision extrêmement technique. Un partage de fonctions de bas niveau, décontextualisées, donnant naissance à des “Common” ou des “Tools” partagés par la terre entière.

 

Sur le papier, c’est moins de travail pour le développeur qui va utiliser votre algo qui répond parfaitement à son besoin. En pratique, comme toute librairie, vous répondez à 97% de son besoin, et il va passer 90% de son temps à adapter les 3% restant. Soit en modifiant votre code, puis en corrigeant les effets de bord induit par sa modification sur le reste de la terre (car heureusement tout le monde a écrit des tests!). Soit en étant obligé de modifier son code, pour s’adapter à la logique existante, par peur de casser quelque chose (car malheureusement rien n’est testé). Ou encore en dupliquant votre code dans une autre fonction avec un nom peu expressif, faisant grossir cette librairie et continuant sa transformation inexorable en God Object immaitrisable.

 

godObject.jpg
Dans tous les cas, vous rajoutez un couplage fort dans votre code. Et ce couplage ne devrait se justifier que fonctionnellement, pas techniquement.

 

Je ne dis donc pas qu’il ne faut jamais se préoccuper de DRY. Simplement qu’il ne faut pas se contenter de sa vision technique, sans quoi on ne fait que complexifier et coupler du code. A partir du moment où les concepts à regrouper ont un sens pour l’expert métier, alors il devient très intéressant de le faire. Tout simplement parce-que cette fois ci, les fonctions partagées seront contextualisées. Une fois de plus : « Context is the key ! »


Alors Don’t Repeat Yourself, mais veillez à ne pas induire de complexité et/ou de couplage inutile pour respecter ce principe, sous peine de voir apparaître un joli sac de nœud.

 Noeud.png



29/08/2013
0 Poster un commentaire
Ces blogs de Informatique & Internet pourraient vous intéresser