La philosophie TDD (2/2)
Cette article (comme son nom l'indique) est la suite de La philosophie TDD (1/2).
C'est un ensemble de points qui montrent l’intérêt concret du TDD, au quotidien.
4> Délivrer le code en temps et en heure
Je suis le premier à lutter « contre » les estimations. L’estimation est trop souvent l’ennemi du changement. Plus précisément, je mets toujours en opposition le coût d’une estimation précise avec le bénéfice réel qu’on va en tirer.
Mais le fait est que, pour l’alignement avec le marketing, il est indispensable d’estimer régulièrement les livraisons. Et le TDD vous rendra beaucoup plus précis à ce niveau pour une raison simple : vous intégrerez naturellement les coûts des tests et des corrections dans vos estimations. Et ça tombe plutôt bien, car les tests et les corrections font partie des choses particulièrement dur à estimer sur un cycle de développement classique.
5> Détecter les problèmes au plus tôt
La philosophie TDD peut se résumer en 2 objectifs:
- Faire expliciter au développeur ce qu’il veut produire avant de le produire
- Forcer ce même développeur à réfléchir en utilisant son propre code
Grâce à cela, le code est naturellement mieux organisé, plus simple (qui a envie de se compliquer la vie?) et les problèmes qui émergent plus tôt sont plus rapidement corrigés. Or la facilité de correction d’un bug est inversement proportionnel à sa durée de vie dans le système.
6> Documenter son code
La seule documentation à jour : c’est le code. Un bon jeu de test qui met en avant la façon d’utiliser une classe, et ses limites vaut largement 200 pages de documentation sous Word. De la même façon, il est souvent plus efficace de tester un bout de code inconnu pour bien comprendre son fonctionnement, plutôt que de lire une documentation associée rarement à jour.
4>Optimiser le temps de dev
Un dernier point qui pourrait sembler être un détail, mais qui est loin d’en être un. Vous devez tester une fonctionnalité qui se trouve en bout de Workflow. A chaque fois vous relancez le logiciel, enchainez les 14 cliques et 12 formulaires qui vous permettent d’arriver sur la fonctionnalité à tester. Tout ça pour constater que votre clique déclenche un NullPointerException…
En TDD vous vous surprendrez à n’exécuter réellement votre logiciel qu’une ou deux fois par jour. Le reste du temps, vous n’exécuterez que des tests. Et cerise sur le gâteau, quand vous exécuterez réellement, vous n’aurez quasiment aucune erreur !
En résumé
Personnellement je ne connais pas d'autre méthode qui permette d’atteindre un tel niveau de professionnalisme avec si peu d’efforts (et donc en si peu de temps). En tout cas je vous garantis qu’un développeur qui produit un soft de qualité est autrement plus épanoui qu’un développeur qui a l’impression de ramer dans un océan de spaghettis. Prenez cet aspect en compte avant de penser qu'un logiciel produit en TDD est plus couteux qu'un logiciel produit de façon plus classique.
Un développeur heureux est un développeur productif!
