Votre projet marche, mais c'est le chaos. Comment arrêter de dépendre de ces "héros" sur qui tout repose ? Présentation vidéo : https://youtu.be/aClcNdOqtsE

1. Sortir de l’ère des héros
Jean-PierreLambert

2. Connaissez-vous l’expression
« l’ère des héros » ?
• Organisation chaotique
• Mais ça tourne quand même, le projet est une réussite
• Comment l’expliquer ?
• On a des héros, qui font ce qu’il faut : jouer au pompier, être proactif sur les
sujets importants… Corriger les problèmes des autres !

3. Pas cool les héros ?
Si ça fonctionne comme ça, faut-il s’inquiéter ?
• Ca ne repose que sur les épaules de ces héros…
• … Ce qui est très fatigant et frustrant pour eux…
• … Et tout risque de s’effondrer à leur départ…
• … D’autant plus probable que c’est un environnement usant !
• Quelle alternative ?

4. Alternative à l’ère des héros : sortir du chaos
• S’outiller, industrialiser les process
• Du code maintenable = tracé par des tests de non-régression
• Construire une culture de la qualité, qui se transmettra de pair en pair

5. Morceaux choisis : ce qu’on me dit
Attention, c’est du vécu !

6. « On n’a pas le temps d’écrire les tests »
• = « On va dans le mur, mais c’est pas grave, il vaut mieux s’éclater la cervelle
dans le mur à l’heure que de l’éviter (et risquer d’être en retard). Après tout,
on n’est pas là pour livrer un logiciel qui fonctionne. »
• = « Ecoute, je connais mieux ton travail que toi, alors faisons comme ça.
Après tout je passe mes journées en réunion alors que toi tu codes, tu fais de
l’archi et de la veille, tu as acquis une expérience unique. Mais bon, il est
évident que je suis la référence. »

7. « On n’a pas le temps d’écrire les tests »
• Non-sens : en fait c’est un gain de temps d’en écrire !
• Vous vous considérez ingénieurs logiciels ou pisseurs de code ?
• N’écoutez pas ceux qui ne connaissent pas (ou plus) votre métier…

8. « Il n’est pas possible d’écrire
des tests unitaires sur ce code »
• = « Je ne SAIS pas comment tester ce code. »
• = « Ce code n’a pas été prévu pour être testé, je n’ai pas le temps de tout
réécrire. »

9. « Il n’est pas possible d’écrire
des tests unitaires sur ce code »
• Problème du code legacy ! Il faut bien commencer un jour… Prendre les
bonnes habitudes sur le nouveau code ! (TDD)
• Expertise à acquérir : savoir casser/minimiser les dépendances
• Votre meilleur ami : votre IDE
• But : pas réécrire, pas embellir, mais couvrir de tests – ensuite on nettoie !
• Faire des dojo ! S’entraider ! Réfléchir à plusieurs ! Persévérer !

10. « La génération de build sur Jenkins
est tout le temps cassée. »
• = « Les scripts de génération de build sont tout pourris. Ils cassent tout le
temps, on n’arrive pas à les mettre à jour, les tests sont aléatoires… Bref, on
se porte mieux sans ! »

11. « La génération de build sur Jenkins
est tout le temps cassée. »
•  « Jenkins a besoin d’amour ! »
• Il faut passer le temps nécessaire dessus : le jeu en vaut la chandelle !
• Ces exécutions répétées vous éviteront de vous taper les problèmes au
dernier moment

12. « Quand on fait un gros refactoring, c’est normal
qu’il y ait une phase de stabilisation, c’est obligé
d’avoir des bugs quand on modifie autant le code. »
• = « Quand on modifie du code en profondeur, on casse forcément quelque
chose. Du coup, il faut éviter de modifier du code si ce n’est pas absolument
nécessaire. Si le code marche pourquoi le modifier ? »

13. « Quand on fait un gros refactoring, c’est normal
qu’il y ait une phase de stabilisation, c’est obligé
d’avoir des bugs quand on modifie autant le code. »
• Bien sûr, si on n’a pas de filet de non-régression !
• On usurpe ici le terme refactoring : pas de refactoring sans tests de non-
régression

14. «Vous n’avez qu’à écrire du meilleur code, sans
bug, comme ça plus besoin de test. »
• = «Vous êtes nuls. En tous cas, le jour de votre entretien annuel pour parler
augmentation, vous êtes mal barrés. »

15. «Vous n’avez qu’à écrire du meilleur code, sans
bug, comme ça plus besoin de test. »
• Un manque total de respect pour vous ?
• Ou une totale ignorance de votre métier ?

16. Alors concrètement, on fait quoi ?

17. On écrit les tests
• Sans autorisation
• Parce que corriger des bugs c’est 1000 fois plus chiant que d’écrire des tests !
• Parce que c’est la seule manière pérenne de coder
• Et parce que c’est vous les experts techniques, les ingénieurs !

18. On utilise une intégration continue
• En donnant la priorité à la réparer plutôt que les fonctionnalités et les bugs
• Parce qu’un test qui n’est pas lancé automatiquement n’existe pas vraiment
• Parce que les process doivent être reproductibles, et qu’ils doivent être
joués à répétition pour vraiment marcher le moment venu

19. Merci !
Questions ?
Jean-PierreLambert
https://www.linkedin.com/in/jp-lambert
https://medium.com/@jplambert
https://twitter.com/@stblifebringer