Lectures & ressources
Les livres, articles et talks qui façonnent ma façon de coder, avec ce que j'en retiens.
Je note ici les ressources que je lis et regarde à partir d'août 2026, avec mon résumé. Avant, je ne les listais pas : je me force donc à (re)lire et (re)voir, et cette page s'enrichit au fil du temps.
- LivreEn cours de lecture
Modern C++ Programming with Test-Driven Development
Jeff Langr · 2013
Ce que j'en retiens : En cours de lecture. Comment pratiquer le TDD concrètement en C++ moderne : rythme red-green-refactor, conception guidée par les tests et gestion des dépendances dans un langage à compilation. Résumé et points clés à venir une fois le livre terminé.
- TDD
- Tests
- C++
- Craft
- LivreEn cours de lecture
Growing Object-Oriented Software, Guided by Tests
Steve Freeman & Nat Pryce · 2009
Ce que j'en retiens : En cours de lecture. La référence sur le TDD « outside-in » et l’usage des mocks pour faire émerger le design : partir des tests de bout en bout, écouter ce que les tests nous disent du couplage, et laisser la conception orientée objet grandir au fil des cycles. Résumé et points clés à venir une fois le livre terminé.
- TDD
- Tests
- Mocks
- Design
- Craft
Ce que j'en retiens : On teste des comportements, pas des classes. « Une classe de test par classe de prod » et un mock par dépendance produisent un harnais qui interdit tout refactoring — l’inverse de la promesse du TDD. Le déclencheur d’un test, c’est un requirement, jamais la création d’une classe. La réponse était déjà dans le livre de Kent Beck (2003) ; on l’avait juste mal lu.
Points clés
- L’« unité » d’un test unitaire, c’est l’isolation du test, pas la classe : un test peut traverser plusieurs classes.
- RED-GREEN-REFACTOR : on passe au vert « salement » (au plus vite), le refactoring est l’étape non-négociable.
- On ne couple aucun test aux classes extraites au refactoring : sinon le moindre changement casse tout.
- Mocker à outrance = coupler ses tests au design courant. Tester au « port » (hexagonal), pas les détails internes.
- TDD
- Tests
- Craft
Ce que j'en retiens : Un dialogue qui pose enfin le vocabulaire des « test doubles ». Tout n’est pas un mock : Dummy, Stub, Spy, Mock et Fake sont cinq objets distincts, chacun bâti sur le précédent. Seul le Mock vérifie un comportement (il sait ce qu’on attend de lui et fait échouer le test lui-même) ; le Fake, lui, a une vraie logique métier. Savoir lequel on utilise, c’est arrêter de sur-mocker.
Points clés
- Dummy : un objet passé mais jamais utilisé, juste pour remplir une liste de paramètres.
- Stub : renvoie des réponses figées pour piloter le chemin du test.
- Spy : un stub qui enregistre en plus comment il a été appelé (combien de fois, avec quoi).
- Mock : un spy qui connaît les attentes et valide/échoue le test lui-même. Le Fake, à part, embarque une vraie logique (ex. une base en mémoire).
- Tests
- Mocks
- TDD
Ce que j'en retiens : Réponse à ceux qui déclarent SOLID « dépassé ». Les principes ne parlent ni d’un langage, ni d’un framework, ni même de l’objet : ils décrivent comment regrouper fonctions et données en modules et gérer les dépendances entre eux. Tant qu’on écrit du logiciel qui doit changer sans tout casser, ils restent pertinents. Les déclarer obsolètes, c’est les confondre avec une implémentation datée.
Points clés
- SOLID vit au niveau intermédiaire du design : la structure des modules, pas la syntaxe.
- Les principes sont indépendants du paradigme et du langage — ils ne sont pas réservés à l’objet.
- Le vrai problème du logiciel — maîtriser les dépendances pour que le changement soit sûr — n’a pas changé.
- « SOLID n’est plus pertinent » revient presque toujours à confondre le principe avec un outil ou une techno particulière.
- SOLID
- Design
- Architecture
Ce que j'en retiens : La base de données n’est pas le cœur de ton application : c’est un détail, un plugin qu’on branche tard. Les règles métier ne doivent rien savoir de SQL, des tables ou de l’ORM — elles manipulent des objets. En gardant la base « dehors », on peut la choisir (ou en changer) le plus tard possible, et tester le domaine sans elle. Le schéma n’est pas l’architecture.
Points clés
- La base est un détail d’implémentation, pas le centre du système — on repousse la décision.
- Le métier dépend d’abstractions (des interfaces de dépôt), jamais du SGBD ou de l’ORM.
- Domaine testable sans base : les tests tournent vite, sans I/O.
- On garde la liberté de changer de stockage tant que le contrat reste stable.
- Architecture
- Database
- Design