“It works on my machine” always holds true for Chuck Norris »
En ce début d’année 2013, et après les vacances de Noël, la reprise du travail rime toujours avec:

  • Bonne année et meilleurs vœux
  • Quelles sont vos résolutions pour 2013 :) ?

La coutume veut que chacun se fixe au début de chaque année de bonnes résolutions pour mieux vivre et réussir.
Pour moi, la meilleure résolution sera: Prévenir et/ou Guérir le syndrome du “Développeur Dieu” chez quelques développeurs que je sais affectés par cet étrange syndrome.

Syndrome de Dieu ? mais de quoi s’agit-il? Le but de ce billet de blog est de présenter ce syndrome dont souffrent beaucoup de développeurs et de lister les bonnes résolutions pour le guérir.

Le Diagnostic

Tout d’abord, le syndrome du Développeur Dieu est une expression qui traduit le fait qu’un développeur se prend pour un dieu du code : tout ce qu’il produit est sacré, pas d’erreur possible et même en cas d’erreur : c’est à cause des autres :)

A qui cela arrive ?

Ce syndrome atteint souvent des développeurs expérimentés, qu’ils soient agiles ou pas. Il peut aussi atteindre des développeurs qui ont connu quelques réussites et des éloges pour leur qualité de code.

Quels en sont les symptômes

  • L’assurance que son code fonctionne parfaitement et ne pas faire de tests unitaires
  • Quand un bug est remonté au développeur Dieu, sa première réaction: “je suis sûr de mon code, avez vous vérifié la configuration ?” :)
  • Quand un développeur Dieu qui faisait habituellement des tests unitaires arrête d’en faire en se disant: “Maintenant mon niveau de codage s’est amélioré, ça ne sert à rien que je fasse des tests, ça va me ralentir”

C’est grave docteur ?

La réponse est : OUI très grave !
Ce syndrome peut mettre en péril tout un projet :

  • En phase de développement, il impacte la relation des développeurs entre eux et des développeurs avec les autres équipes
  • Après livraison, la qualité du livrable peut en être atteinte, et la non régression risque de ne pas être assurée

Ok, j’accepte le diagnostic, donnez-moi l’ordonnance :

 

1. Tester avant ou après chaque classe développée (de préférence avant)

Le premier remède du « syndrome du Développeur Dieu » est de tester tout ce qu’on écrit; chaque classe développée doit avoir son test qui valide unitairement qu’elle fonctionne et qu’elle répond bien à ce qui est attendu.
J’ai vu beaucoup de développeurs qui prétendent que les tests ne servent pas à grande chose ou parfois ils testent à minima: ils valident uniquement les cas nominaux, pas les cas spécifiques ni les cas d’exception ; CECI EST EVIDEMENT FAUX. On ne peut être sûr de ce qu’on développe qu’avec un test unitaire, et croyez moi, un test unitaire n’est jamais une perte de temps. On se rend compte de son utilité lorsqu’on introduit des bugs en voulant corriger une petite erreur. Par ce que, tout simplement, il n’y avait pas de tests unitaires qui assureraient une non-régression.
Au passage, un proverbe marocain dit: “Celui qui a été mordu par un serpent, craindra à jamais une corde”; l’assurance de ne pas être mordu est de “Tester”.

2. Faire du xDD: TDD, ATDD et BDD

Toujours dans le cadre des tests, le TDD (Test Driven Development) est un principe très recommandé par les méthodes agiles. Son rôle est de se mettre dans la peau du contrôleur du code avant même de commencer à coder.
Pour se prémunir du syndrome du Développeur Dieu, ayez toujours le bon réflexe de commencer par coder le test avant de coder la fonctionnalité souhaitée. Avec ce réflexe, vous allez d’abord avoir un test qui prouvera que votre code fonctionne, par la suite, vous aurez un bon moyen pour assurer la non-régression de votre code. De plus, ce test constituera une documentation qui expliquera techniquement et fonctionnellement le besoin.

Si le TDD est destiné à faire essentiellement des tests unitaires avant de commencer à coder, l’ATDD (Acceptance Test Driven Development) et BDD (Behavior Driven Development) sont destinés à prouver fonctionnellement que le service souhaité est parfaitement rendu par le code. Dans tous les cas, c’est le test qui précède le code. Vous l’aurez bien compris, le TDD est pour soi (voire pour les collègues :)) et l’ATDD/BDD est pour les product owner (PO) et l’équipe fonctionnelle.

3. Avec le binômage, pas de syndrome de Dieu

Bonne nouvelle un vaccin existe : le binomage. Le binomage est une pratique très recommandée par les méthodes agiles pour améliorer à la fois la productivité et la qualité de code. Je ne vais pas me faire l’avocat de cette pratique dans ce billet de blog :), par contre je vais vous expliquer pourquoi cette pratique peut être un bon remède à ce syndrome chez un développeur Dieu.
Lors du binomage, un développeur confronte ses idées et sa méthode de développement avec un autre, voire plusieurs. Pour répondre à un besoin, ils existera forcément autant de façons de codage que de développeurs et une telle confrontation d’idée ne peut que pousser le développeur Dieu à prendre conscience qu’il n’y a pas que sa façon de coder et que la responsabilité du code est collective : il s’agit d’un bon remède au syndrome.

Bien sûr, le binomage doit être accompagné d’autres pratique comme le TDD, faire du ping-pong: un binome code le test unitaire pendant que l’autre réfléchit sur la façon de passer ce test et donc de répondre au besoin fonctionnel exprimé. Ensuite, celui qui était en train de réfléchir prendra la main et commencera à développer sous l’œil attentif du premier. Le binomage doit être bien encadré pour réussir à éradiquer le syndrome du Développeur Dieu: on ne met pas de développeur expérimenté atteint par le syndrome avec un débutant. Le débutant serait en position de faiblesse.

4. Voyager léger

Une des pierres angulaires pour ne pas attraper le syndrome de Dieu et d’en guérir est de rester simple lors du développement: c’est ce qu’on appelle le voyage léger.
Pourquoi chercher à rendre un code hyper générique avec des variables partout alors que le besoin est simple. Pourquoi utiliser des librairies ou des « softwares tendance » alors que pour répondre au besoin exprimé, il existe une méthode plus simple voire native. Pourquoi développer, par exemple, un logiciel de traitement de données qui prend en entrée à la fois des fichiers, des webservices et un mode console, alors que le besoin se limite à un traitement à base de console (un main avec des read et println)…
C’est le syndrome de Dieu qui pousse généralement un développeur à privilégier des méthodes complexes parce qu’il se croit fort en développement et rien n’est complexe pour lui.
Soyons alors comme un “routard ou un marin du code » qui prend juste son sac à dos lors d’un voyage. Forcément, il ne mettra dedans que les outils utiles.
Un développeur doit faire pareil, ne faire que l’utile pas plus. Fini l’attitude de celui qui développe beaucoup plus par rapport à ce qui est demandé afin d’apparaître comme prévoyant.

5. La magie de l’expression “A MON AVIS”

La guérison du syndrome de Dieu passe certainement par une collaboration des collègues. Il faut donc un climat propice pour que ce processus de guérison puisse réussir.
J’ai découvert récemment comment en ajoutant l’expression “à mon avis” avant d’aborder un sujet, le climat devient très positif et ce qu’on avance est mieux accepté.
Le problème des développeurs qui ont le syndrome de Dieu est qu’ils pensent qu’eux seuls ont raison. Avec l’usage de “à mon avis”, le développeur prendra certainement conscience que ce qu’il pense n’est que Sa façon de coder, qui n’est pas forcément une vérité absolue partagée par les collègues. Ainsi, sera-t-il plus susceptible à accepter les idées et les propositions des autres.
D’un autre coté, face à quelqu’un qui dit “a mon avis”, les gens sauront qu’ils peuvent proposer autre chose, discuter et donc ils l’aideront à guérir de son syndrome.

6. Accepter le changement

Là j’avoue que je suis à fond dans l’agile :)
Si tous les autres éléments précédents peuvent être appliqués à un développeur dans un contexte autre qu’agile, l’intégration du changement est un des 4 piliers de l’agilité.
Accepter le changement implique de se rendre compte que votre code sera certainement modifié par un tiers (d’autant plus si vous souhaitez commiter sur des projets Open Source)
Accepter le changement implique aussi que techniquement le développeur doit fiabiliser son code avec des tests (ce qui rejoint le premier point de ce billet) et doit coder simplement (c-à-d le plus simplement possible). Mais accepter le changement est avant tout un état d’esprit d’ouverture; ouverture qui devrait nous prémunir du syndrome.

7. Le courage

Je termine par un des principes de la méthode XP : Le courage. Il faut être courageux pour se lancer continuellement dans un refactoring, pour faire systématiquement du TDD, pour se lancer dans une guerre de tests unitaires sur du code legacy…
Avec ce courage, on n’attrape jamais le syndrome du Développeur Dieu. Parce qu’on sait que le code est vivant et subit continuellement des améliorations, qu’il est une propriété collective de toute l’équipe. Personne ne dira donc il faut coder comme ceci parce que c’est le top, personne ne dira « je ne fais pas de test, je suis sûr de mon code ». En fait, le code sera testé et qui sait on peut découvrir beaucoup de bugs : Le syndrome de Dieu deviendra donc le syndrome de la Honte :)

Conclusion

En conclusion, le syndrome du Développeur Dieu est un syndrome très dangereux pour soi, pour l’équipe et pour les projets.
Pour résumer toute cette ordonnance : Pour prévenir ou guérir ce syndrome, SOYEZ AGILE, FIERS et HUMBLE :)

(1) https://wiki.jenkins-ci.org/display/JENKINS/ChuckNorris+Plugin