Si vous croyez savoir, vous ne savez pas.

Les personnes intéressées par l'apprentissage et la pédagogie connaissent probablement la taxonomie (révisée) de Bloom. Formulée pour la première fois en 1956 et dans une seconde version en 2001, elle précise le sens du mot "savoir" en lui attribuant 6 nuances possibles : se souvenir / comprendre / mettre en œuvre / analyser / évaluer / créer.

Laissons le soin aux académiques de détailler cette gradation, qui va de la simple capacité à restituer un savoir sans même le comprendre à la capacité à en percevoir les limites conceptuelles, quitte à proposer un cadre théorique plus adapté.

Ce modèle a ses limites, comme tout modèle, mais il a ceci de bénéfique qu'il nous incite à nous demander où nous en sommes, nous qui, peut-être, pensons savoir.

Votre serviteur, par exemple.

Ma connaissance de la cryptographie asymétrique est minime : je comprends les notions de clé privée et clé publique et sais m'en servir pour générer un certificat HTTPS. Mais l'utilisation pratique de ce savoir passe par des outils du marché, élaborés par des personnes qui, elles, accèdent à un niveau bien plus élevé (évaluation ou création). De sorte que mon savoir, lui, se limite à la compréhension.

Ma connaissance du protocole OAuth2 va un cran plus loin, celui de la mise en œuvre. En effet, ma compréhension est suffisante pour identifier les pièges classiques, à commencer par le fait que vérifier la validité cryptographique d'un jeton d'authentification ne suffit pas : il faut également vérifier qu'il n'a pas été invalidé (cas d'un utilisateur déconnecté). Ce qui suppose de maintenir une base de données des jetons révoqués. Ma compréhension du sujet me permet donc d'établir une architecture qui ne se tire pas d'emblée un balle dans le pied. 👍

En revanche, sur le Test-driven development (TDD), j'ai franchi un cap le jour où j'ai commencé à porter un regard critique sur la pratique. Oui, parfois le TDD ne m'aidait pas vraiment, voire devenait contre-productif. Il est à présent clair pour moi que développer des composants React en TDD n'a aucun intérêt. Vouloir à tout prix faire du TDD, c'est enfoncer des vis à l'aide d'un marteau. Mieux vaut changer d'outil. Le niveau de l'évaluation est donc celui de la nuance. On perçoit les limites d'une approche.

Et cela nous mène à découvrir une pratique du TDD qui nous est propre. Sans doute avez-vous comme moi votre manière bien personnelle de mêler les approches outside-in et inside-out, de faire ici du TDD et là du test-after. Peut-être que le TDD vous a, comme moi, mené à la programmation fonctionnelle et que vous ne savez plus faire autrement. Votre façon de programmer ne porte peut-être pas de nom, mais vous êtes en mesure de la justifier, tout en acceptant de la confronter à d'autres manières de faire.

Au final, des connaissances de base en sécurité, qui me permettent d'être efficace tout en évitant les dégâts, et de la hauteur de vue sur le cœur de mon expertise (qualité logicielle / artisanat logiciel). Logique 😊

Et vous ?