En programmation, il arrive souvent que des problèmes se révèlent plus compliqués que prévus. Il arrive même parfois que nous passions carrément à coté de leur difficulté, et que nous nous en rendions compte beaucoup plus tard, à nos dépends. Il arrive parfois aussi que face à un problème compliqué nous passions à coté de LA solution simple et efficace. Par manque de réflexion préalable nous avons alors perdu notre temps à écrire du code lourd et alambiqué. Après avoir assisté à plusieurs conférences, Robert C. Martin confronte cette réflexion au TDD dans un billet d’Octobre 2011 :

« Rich Hickey, le créateur du langage Clojure, a donné une excellente conférence à Strange Loop 2011 intitulée « Simple Made Easy ». Je vous recommande vivement de consacrer une heure à l’écoute de cette conférence. Elle vaut chaque seconde que vous lui accorderez. Il y aura des choses dans cette conférence avec lesquelles vous ne serez pas d’accord. Lorsque cela se produit, arrêtez-vous et réfléchissez – réfléchissez bien – vous n’êtes probablement pas réellement en désaccord. Et si vous l’êtes, vous ne devriez probablement pas l’être.

Par exemple, Rich fait quelques remarques apparemment désobligeantes sur le TDD, l’Agile et le Refactoring – les vaches sacrées de la communauté Agile. Si vous êtes attaché à cette communauté, vous pourriez réagir négativement. Ne le faites pas. Rich ne dénigre pas les pratiques. Il dénigre la religion – l’absence de réflexion.

Rich compare les tests unitaires aux garde-corps. Puis il fait un très bon point. Il dit que lorsque vous avez un bug, ce bug a échappé à vos tests. Et maintenant ? Vous devez trouver le bug. Et si le système n’est pas simple, ce ne sera pas facile. (Notez que j’ai utilisé les mots simple et facile ici. Le début de la conférence de Rich porte sur les définitions très différentes de ces mots. Je vous suggère de vous arrêter à ce stade et d’écouter les dix premières minutes de sa conférence puis de revenir à ce paragraphe.)

Rich souligne que les sprinters courent vite, mais pas longtemps. Puis il dit qu’Agile a « résolu » ce problème en tirant simplement le coup de départ encore et encore rapidement. Il sourit, et le public rit. Puis il ajoute que courir en continu ne rend pas nécessairement les systèmes simples, et que la simplicité est la véritable clé de la vitesse.

Il a bien sûr raison. C’est le même point que Martin Fowler a fait dans son article sur le « Scrum flasque« . Et c’est le point que beaucoup d’entre nous dans la communauté Agile ont fait. Que de courtes itérations, sans bonnes pratiques techniques, ne conduisent pas à un développement rapide. Au contraire, cela conduit à un gâchis.

Rich se moque de l’idée qu’une suite de tests vous permet de changer le code. Il dit que les tests sont un filet de sécurité, rien de plus. Nous, les TDDers, savons qu’une suite de tests est essentielle si nous voulons changer le code sans crainte. Mais Rich a raison sur le filet de sécurité. Un filet de sécurité peut aider à garder un système simple, s’il est déjà simple. Mais un filet de sécurité sous une grosse boule de boue sera d’une aide marginale pour démêler le gâchis. Oh, ne vous méprenez pas. Je veux ces tests ! Mais le travail ne sera pas facile.

Dans une autre conférence « Hammock Driven Development« , Rich nous encourage à réfléchir au lieu de simplement écrire des tonnes et des tonnes de code.

Voici le point. Rich est préoccupé, et à juste titre, que nous ayons une culture de complexité. Que lorsque les programmeurs reçoivent une tâche, ils se précipitent et écrivent des masses de code enchevêtrées, utilisant des cadres et des outils « faciles », sans donner à la question la réflexion qu’elle mérite. Nous confondons la facilité avec la simplicité. (Par exemple, Rails est facile, il n’est pas simple.) Sa plainte concernant les tests est que nous les avons utilisés pour remplacer la réflexion. Nous sommes fiers de nous parce que nous avons écrit des tests, et pourtant nous n’avons pas vraiment consacré le temps nécessaire au problème. Nous n’avons pas rendu le problème simple. Nous avons juste fait ce qui était facile.

La vérité est que la communauté Agile, et l’ensemble de la communauté logicielle, est infectée par cette maladie. Trop souvent, nous faisons ce qui est facile, au détriment de ce qui est simple. Et donc nous faisons un gâchis. Mais ce n’est pas maintenant, ni ne l’a jamais été, une valeur du développement agile. Et ce n’était certainement pas une valeur du Software Craftsmanship ! En effet, faire ce qui est simple plutôt que ce qui est facile est l’une des caractéristiques définissant un artisan logiciel.

Au final, je pense que la perception qu’a Rich du TDD est faussée par ce qu’il voit dans l’industrie. Franchement, je pense qu’il passe à côté. J’imagine qu’il découvrirait que la pratique lui est aussi utile qu’elle l’a été pour moi. Non pas comme un moyen d’éviter de réfléchir et de se précipiter vers un gâchis ; mais plutôt comme une façon disciplinée d’être minutieux, prudent et réfléchi.

Maintenant, demandez-vous ce que TDD signifie pour vous. Est-ce une discipline que vous utilisez pour faciliter les choses ? Ou est-ce une discipline que vous utilisez pour être réfléchi, prudent et pour garder les choses simples ? »