👉 si t’écris du code, t’écris des tests, idéalement avant. TDD, yeah.
💡si t’écris moins de code, tu dois écrire moins de tests.
Avant de m'allumer, merci de regarder ou re-regarder ce talk magistral "Simple Made Easy". Rick Hickey, inventeur du langage de programmation Clojure, y fait la promotion du purement fonctionnel :
▶️ https://www.infoq.com/presentations/Simple-Made-Easy/
Ce moment hilarant en particulier où il se demande si on se laisse conduire sur l’autoroute grâce aux rails de sécurité. ➡️ bang ⬅️ bang ➡️ bang.
L’invitation à réfléchir autant qu’à coder frénétiquement n’est pas neuve. Parmi ses principaux ambassadeurs, on retrouve :
👉 Backus : fonctionnel plutôt qu’impératif
👉 Dijkstra : structured programming plutôt que goto
👉 Hoare : preuve/raisonnement plutôt que tests
👉 Brooks : requis plutôt qu’implémentation
👉 Codd : interroger les données plutôt que les naviguer
👉 Harel : des modèles plutôt que du code
(lire le "plutôt que" à la sauce du manifeste Agile : while there is value in the items on the right, we value the items on the left more)
On retrouve en trame de fond une dualité vieille comme l'informatique : mathématique vs. ingénierie, déclaratif vs. impératif, science vs. craft.
Si vous êtes super-pro-TDD et que tout ceci vous choque ou vous interpelle, lisez le blog post intitulé "The Transformation Priority Premise" de Uncle Bob (2013) :
📚 https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
La pratique du TDD proposée consiste à faire de l'induction : on part d'exemples et on généralise au fur et à mesure pour découvrir les règles générales et l'implémentation qui couvre l'ensemble des exemples.
C'est une technique géniale, que je conseille à tout le monde. Elle évite de prendre le besoin d'abstraction en plein face, s'en remettre à elle est une preuve d'humilité face à la complexité.
De l'autre côté du spectre, cela dit, une autre humilité : admettre que les mathématiques existent, que le déclaratif existe, que la capacité de raisonnement pur offerte par la science existe.
Tout simplement parce qu'à un moment il FAUT sauter le pas de l'accumulation d'exemples (les tests) à la spécification. Si vous n'en êtes pas convaincu c'est l'article "A fundamental duality of software engineering" chez Bertrand Meyer qu'il fait lire (spoiler : c'est évidemment matheux).
📚 https://bertrandmeyer.com/2012/10/14/a-fundamental-duality-of-software-engineering/
#SoftwareEngineering #History