Tu démarres ta session de développement. Tu as les idées claires sur ce que tu veux faire, mais pas forcément sur comment tu vas le faire. Ça touche une partie du code que tu ne connais pas, et tu as peur de casser quelque chose. Tu sais déjà que la journée va être longue. Tu te lances. Tu cherches à comprendre où tu pourrais te brancher. C’est laborieux. Enfin, tu trouves. Fatigué, tu fais une pause café. Tu t’y remets, et tu codes la nouvelle fonction.  Comme tu es un peu coincé dans ce code legacy que tu n’oses pas trop toucher, tu fais au mieux pour coder ce que tu avais en tête. Tu livres sur develop, et tu montres ça à ton PO. Il y a pas mal de trucs à revoir. Cela va t’obliger à reprendre les morceaux que tu n’avais pas envie de toucher. Tu joues la montre et retournes faire une pause. Bon, faut y aller : tu t’attaques au gros morceau. C’est une bataille épique et stressante, mais tu finis par y arriver. C’était épuisant, mais tu pourrais presque être satisfait.
Le seul hic, c’est que tu viens d’ajouter trois bugs dont un critique dans l’application.
Tu rentres chez toi frustré de ton travail.

Imagine maintenant : tu commences ta session de développement. Tu as clarifié ta user story, et tu es prêt à y aller. Tu te sens complètement serein, parce que tu sais déjà que ça va bien se passer. Tu démarres ta nouvelle fonction, et tu te plonges à fond. Le travail est fluide. Tu es tellement concentré que tu ne vois pas l’heure passer ! Tu es dans le flux, totalement absorbé par ce que tu fais. Tes neurones carburent à fond, et c’est bon ! À la fin d’une longue session de travail, tu livres ça sur develop. Tu fais une démo à ton PO qui y apporte quelques ajustements. Tu corriges, et pouf, c’est prêt à passer en validation. C’est facile & direct.

Quand tu utilises un langage objet, tu peux avoir l’impression que les objets sont naturels, qu’ils sont faciles à créer.
C’est comme dire que, par-ce qu’un téléphone ou un ordinateur est facile à utiliser, c’est facile de le fabriquer.
En fait non, c’est tout le contraire. C’est difficile de créer des objets qui sont faciles à utiliser.

Dans ce second module, on entre en plein dans le code et on voit : 

Après s'être occupé d'une classe, on pourra voir les interactions entre classes dans le prochain module.

Les tests unitaires, c’est important.
Et pourtant, tu n’en écris pas.
Ça fait peut-être même partie de ta "définition de terminé", la règle dans le SCRUM qui dit quand tu as fini une story. Mais, en réalité, personne n'en écrit vraiment.

Alors, soyons clairs : les tests unitaires, c’est pas un truc important.
C’est LE truc fondamental. C’est la base de ta stratégie de tests.

Avec des tests, tu éradiques les bugs, t’es ultra zen, tu peux refactorer ton code à volonté et en continu.

Les tests unitaires, c’est le premier pas vers un monde épanouissant. Et oui, le monde des Bisounours existe.

Les tests, c’est la vie du code !

Dans ce module : 

On y parlera bien sûr TDD qui est pour moi la seule manière d’écrire des tests valables.

Mon objectif est que tu sois en capacité d’écrire tes premiers tests d’ici la fin du module. 

As-tu déjà remarqué comme la spec était un sujet courant d’embrouille dans un projet ?

Si en plus c’est ce qui définit le cadre commercial, les choses peuvent devenir vite rigides… 

Pour moi, une bonne spec remplit les critères suivants :

Dans ce module, je te montre comment utiliser le BDD, et le transformer en un véritable levier de communication avec ton client.

Je te montre aussi comment je l’utilise concrètement au quotidien depuis des années pour mener à bien mes projets.

Il est fini le temps où un développeur seul pouvait révolutionner une industrie.
Aujourd’hui, pour conquérir un marché, il faut bien souvent plusieurs développeurs, et toute une équipe avec des compétences variées, ce qu’on appelle aujourd’hui une feature team.

C’est là que l’équipe peut faire une grosse différence : va-t-elle être capable de jouer en équipe, ou va-t-elle être en mode cowboy solitaire ?

Ce module est centré sur les pratiques d’équipes qui viennent non seulement renforcer, mais aussi amplifier les pratiques techniques que l’on a vues jusqu’à maintenant. On y voit notamment les 4 pratiques essentielles du tueur de bugs. On en profitera pour pourfendre les mythes et les idées fausses autour du binômage
On y parlera auto-organisation, amélioration continue, responsabilité collective, rythme durable, conception émergente, ou encore du principe de petites livraisons.

On revoit aussi les questions de règles de codage, TDD et intégration continue, cette fois sous l’angle non plus technique, mais de la pratique d’équipe.

On fera aussi un passage du côté du dark agile pour apprendre à débusquer les pièges de l’agilité.

Enfin, on visitera la dimension psychologique du code : car oui, coder propre rend heureux !