Prévenir > Guérir
TDD est une stratégie Diviser pour Régner appliquée aux vérifications et aux refactorings de votre code. Le R.O.I, ce que vous gagnez à acquérir et renforcer cette compétence, dépend de la taille de la base de code sur laquelle vous travaillez.
Comparer une solution dont le code est 90% vérifié à une solution dont le code n'est pratiquement pas vérifié peut être particulièment trompeur. Cela revient à comparer deux choses différentes, et ne considérer que le prix. 🪣 🤓 🧯
Bien sûr quand nous développons du logiciel, nous devons être vigilants sur les coûts, nos ressources sont limitées. Nous avons aussi besoin d'être responsabilisés sur nos décisions (entre autres : celles qui concerne les méthodes qui vont continuer de s'appliquer quand nous serons partis). Notre solution doit aussi être soutenable en termes de coûts, de qualité et de facilité de maintenance.
Quand on adopte une stratégie Code & Fix sur un projet complexe, on proclame :
- on va faire ce projet en Code & Fix, parce que c'est moins cher ! 🪙 💪
Il serait honnête de dévoiler le raisonnement complet, avec ses conséquences :
-
tous les chemins d'exécution possibles du code ne seront pas vérifiés : ni au niveau unitaire, ni au niveau intégration 🕳
-
nous ne savons pas exactement lesquels seulement seront testés 🎰
-
nous ne comptons pas le calculer, mais intuitivement, nous savons que l'alternative TDD serait du gâchis 🔮
🤷♂️
🗺🪜🧯
TDD est une instance de stratégie de prévention des défauts.
La prévention des défauts est elle même une instance d'ingénierie bien comprise, telle que les humains la développent en vue de faire face à la complexité, et à l'irreversibilité du temps.
Il vaut mieux prévenir que guérir :
-
Nous protégeons les biens dont nous savons qu'ils seraient difficiles à remplacer s'ils disparaissaient. 🔐
-
Nous dépensons un peu d'énergie à maintenir de l'ordre dans un système qui marche, pour éviter de dépenser une énergie incommensurable sur un système en désordre qui ne marche plus. 🗃
Le bien que je protège en écrivant un check (ou "test unitaire" 😒) c'est la compréhension précise que j'ai de ce chemin possible d'exécution du code au moment où j'écris le code. 🗺
Le désordre dont je me protège est celui qui serait créé par un chemin d'exécution défectueux enfoui parmi des milliers de chemins d'exécution possibles, eux mêmes liés à des centaines d'états possibles. C'est une forêt épaisse et opaque, une botte de foin numérique dans laquelle je n'ai aucune envie d'avoir à chercher une aiguille. 🤯
Mon avis :
-
ne vous enfermez pas dans un tunnel de code jusqu'à vous trouver au sommet d'une solution ingérable, à vous demander : attends, est-ce que ça marche, au fait ?
-
apprendre une nouvelle technique est plus facile au début d'un projet qu'au milieu d'une crise
-
est-ce qu'il faut vraiment TOUT construire comme si les solutions que nous créons n'avaient aucun avenir ?
Stay Tuned !