La philosophie TDD (1/2)
On entend de plus en plus souvent parler du TDD, en bien ou en mal. Certain ne comprennent pas qu’on puisse encore s’en passer, d’autres ne comprennent pas pourquoi ils devraient se contraindre à l’utiliser, et la plupart ne l’utilisent pas par habitude ou à cause du « manque de temps parce-que nous c’est plus compliqué que les autres ».
Evidemment en temps qu’évangéliste des méthodes de développement agile, certains arguments me hérisse le poil, mais ce que je voudrais mettre en avant dans cette article n’est pas : « faites du TDD parce-que ça déchire », mais juste « voilà les valeurs et l’intérêt concret du TDD». Et si vous trouvez une autre méthode en accord avec cette philosophie, n’hésitez pas à l’employer plutôt que le TDD ! Mais si vous vous retrouvez dans un des points qui vont suivre, ne restez pas immobile simplement parce que « ça a toujours été comme ça ».
1> Ne plus avoir peur du changement
`
« Quoi, le modèle a encore été modifié ? », ou « Comment ça le client ne veut plus cette fonctionnalité ? Mais elle était prioritaire la semaine dernière ! ». Grande nouvelle amis développeurs, nous ne sommes pas des théoriciens de l’informatique. Notre boulot est de produire ce que le client VEUT, et non pas ce que le client VOULAIT.
Le code doit forcement pouvoir évoluer, puisque tout ce qui cause son existence même évolue ! (projet, équipe de dev, contexte commercial, technologique…etc). De fait, ça fait partie de notre travail d’être capable de faire évoluer en profondeur le code et les concepts qu’il manipule, sans pour autant perdre toutes les fonctionnalités à chaque remaniement.
2> Minimiser les régressions
« Mais je ne comprends pas, ça marché la semaine dernière ! », et pourtant, le jour de la démo devant le client, ça ne marche plus. Le professionnalisme, c’est aussi être capable de dire « c’est fini ».
Dans la définition du terminé, il y’a presque toujours « le code que j’ai produit fonctionne », mais il manque souvent « fonctionne, et en plus je serais capable de détecter automatiquement un effet de bord qui pourrait en affecter le comportement ». Pourtant c’est le seul moyen de garantir la non régression, et il n’y a rien de plus démoralisant (pour le développeur comme pour le client) que les régressions.
3> S'adapter aux besoins du client
Est-ce que vous proposeriez une Ferrari à une personne âgée qui veut faire ses courses ? Une C1 à un agriculteur qui veut vendre sa production sur des marchés itinérant ? Un tracteur à un pilote de F1 ?
Avec le TDD, et le design émergent en itération courte, si je devais garder la même image, on va d’abord proposer une trottinette à notre grand-mère. Elle va nous dire que c’est trop fatiguant, alors on ajoutera un moteur. Elle va nous dire qu’elle prend trop l’air, alors on va mettre une carrosserie. Elle va nous dire que c’est instable, alors on va mettre 4 roues. Elle va nous dire qu’elle ne peut pas poser ses courses, alors on va lui mettre un coffre. Tient, ça ressemble à une C1 ce que je lui ai fait ! Mais j’ai traité les problèmes petit à petit, et cette C1 a émergée. Je ne suis pas partie de l’apriori qu’il lui faudrait une C1, c’est tout à fait différent. Notez que si maintenant elle me dit qu’elle veut aussi emmener ses amies au club de bridge, je rajoute 1 siège arrière et 2 portières, et là voilà avec une C3 ! Faite ce dont vous avez besoin, ni plus, ni moins.
Transition
J'aurais aimé faire tenir cette article sur une seule page, mais il y'aurait eu moins d'images et plus de texte, ce qui fait que la pause café n'aurait pas suffit à lire l'article complet. A suivre pour la partie 2 donc...(lors de votre prochaine pause café!)
