Faire simple est un challenge

Il y a un défaut communément répandu chez les développeurs : leur capacité à fournir une solution complexe à un problème simple.

Souvent c’est involontaire : certains d’entre eux ont une tendance naturelle à aller vers ce que l’on appelle l’over-engineering (le fait de construire un objet ou une réponse ayant une complexité superflue à un usage ou un problème). Il s’agit de se faire passer pour quelqu’un de brillant :

Extrait de The Software Craftsman :
Dans certaines équipes on mesure la qualité et la compétence d’un développeur à sa capacité à écrire du code que personne ne comprend. C’est un non-sens, une des première qualité d’un code source c’est sa clarté et sa maintenabilité.

Le pompier pyromane

On va traiter d’entrée ce cas là. Parfois c’est volontaire : là c’est grave, quand il s’agit de gens dont l’objectif est de se rendre indispensable au projet cela peut coûter très cher à votre entreprise.

Heureusement je pense que l’immense majorité des gens n’est pas dans ce cas. Toutefois, s’il vous arrive de croiser un profil dans ce genre-là sur un projet je vous conseille de :

  • Option 1 : Tenter d’y mettre fin rapidement (soyez courageux : ils détestent être démasqués)
  • Option 2 : Changer de projet le plus rapidement possible.

“C’est évolutif !”

La principale difficulté avec le code compliqué c’est que le type qui l’a écrit a toujours une bonne raison de l’avoir écrit comme cela.

L’argument que j’ai trop souvent entendu est “C’est évolutif” : On a tous passé des heures et des heures à construire une solution évolutive pour un besoin qui au final n’a… jamais évolué.

Je pense qu’il est important lorsque l’on conçoit un système d’information de penser aux axes d’évolutions pertinents (ils ne le sont pas tous) : rapprochez vous des gens qui portent le métier (votre Product Owner) pour identifier les éventuelles évolutions de votre système. La plupart des gens que j’ai croisé dans ma carrière qui avaient tendance à pratiquer l’over-engineering montraient peu d’intérêt pour l’aspect métier : ils sont bien plus intéressés par le comment que par le pourquoi.

“On pourra le modifier à chaud”

C’est l’autre argument qui revient souvent…

J’ai déjà vu sur un projet la construction d’une usine à gaz pour stocker et charger à chaud des templates d’email que devra envoyer l’applicatif ainsi que tout un système de priorités sur le template à utiliser dans tel ou tel cas, cela pour pouvoir modifier le comportement “sans redéployer”. C’est louable mais j’y vois deux contre-arguments :

  • Le contenu de ces emails et les priorité associées devront-ils changer régulièrement en dehors de la phase de construction ? Si ce n’est pas le cas il aurait été plus malin de consommer cette charge sur un autre poste comme écrire des tests unitaires par exemple (une autre lacune courante chez l’over-engineer).
  • Honnêtement en 2017, à l’heure où des gens pratiquent le déploiement continu si tu as peur de faire un déploiement de ton applicatif c’est qu’il y a un sérieux problème dans la manière dont ton organisation fonctionne.

Un problème ne vient jamais seul

En général les over-engineer que j’ai pu croiser avaient deux grosses lacunes : la documentation et les tests unitaires :

  • Pour la documentation je veux bien les comprendre, documenter une usine à gaz n’est pas une tâche aisée et cela risque de mettre en évidence cette complexité superflue.
  • Pour les tests unitaire je pense que c’est parce qu’ils sont dans le paradigme “les tests unitaires c’est pour le code mal écrit ou pour les débutants” et donc que cela ne les concerne pas.

Comment limiter les dégâts ?

Dans certaines équipe l’over-engineer est sollicité sur les démarrages de projets et ensuite il confie “son bébé” au reste de l’équipe qui souffre pour en assurer la maintenance et le support pendant que notre ami travaille à pondre une autre usine à gaz…

Un conseil simple : les gens qui produisent un applicatif doivent être impliqués de très près dans la maintenance de celui-ci, c’est la base de notre métier de produire des applications maintenables. Quand il aura passé quelques soirées au bureau à tenter de déboguer en urgence le fruit de son travail vous verrez qu’il envisagera les prochains projets que vous lui confierez avec plus d’humilité.

Pour aller plus dans le détail, le billet ci dessous est très intéressant