Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur le code dupliqué, code duplicate ou encore très souvent nommé “copier/coller à l’arrache”.

Le premier point sur ce sujet c’est tout simplement de comprendre pourquoi un code dupliqué est nuisible dans un projet unitaire. L’évidence même c’est tout simplement qu’au lieu d’avoir un bug, vous en avez autant de fois que vous avez dupliqué le code. Ca semble une évidence et pourtant.

Pour éviter ce genre de bourde nous utilisons plusieurs choses. La première c’est un outil simple et surtout automatique que vous pourrez intégrer dans jenkins. J’ai nommé : phpcpd

La seconde chose c’est l’échange entre les développeurs. Sans échanges au sein de l’équipe de développement il y’aura forcément du code dupliqué. Il est utopiste de penser que tous les développeurs d’un même projet ont la même connaissance de l’ensemble du projet. Chacun a ses préférences, d’autres ont travaillé plus de temps sur un point, et tout simplement tout le monde ne peut pas tout retenir.

Ok, très bien, qu’est ce qu’on fait de ce code dupliqué dans notre projet unitaire. C’est assez simple, il suffit d’en faire une librairie. Sortez le code dupliqué dans une fonction avec des paramètres d’entrées et la sortie qui va bien. Le tour est joué.

Quoi que… Il faudra faire attention à une chose. Le moment où ce code dupliqué utilisé par N autres personnes aura besoin d’une petite spécificité pour l’un d’entre eux. Il sera alors temps de ne surtout pas faire un petit “fix” à l’intérieur spécialement pour l’un pouvant impacter les autres.

Mais le véritable problème du code dupliqué c’est quand il est transverse à plusieurs projets. Là ça devient vraiment pas cool. La raison est toujours la même que précédemment, on va devoir corriger des bugs de partout. Et surtout c’est potentiellement des personnes différentes qui vont corriger le bug de façon différente.

Pour éviter ça, nous échangeons le plus possible à l’oral pour savoir qui fait quoi. Quand quelqu’un rencontre un problème avant de le corriger, on demande si quelqu’un l’a déjà rencontré. Les compétences de chacun sont ainsi tirées vers le haut, et l’émulation se crée au sein de l’équipe.

Une fois qu’on identifie des éléments dupliqués au sein de plusieurs projets nous en faisons si possible une librairie qui se retrouve ensuite en sous module des différents projets. Il faut faire attention à ce point et essayer de garder à jour un schéma de tout ça car ça peut devenir un nœud de spaghetti. Mais surtout la mise à jour du dépôt parent peut engendrer des effets en cascade sur les projets enfants.

Il n’y a pas de solution miracle, c’est l’échange, la revue de code, le pair programming qui restent à mon sens la clé du succès sur ce point même si des outils existent et peuvent attirer votre attention dessus.