Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

Le bon code

Le bon code est vivant, il est en rework constant, il est maintenable et élégant. Le bon code est écrit par plusieurs personnes, sur des standards partagés, et surtout il est testé. La preuve par l’absurde du caractère indispensable du TDD : votre code fonctionne, mais vous êtes choqués par certains passages anciens, pas assez compréhensibles, pas optimisés que vous venez de croiser au détour d’un développement. Bref, vous sentez bien qu’il faut retoucher et que ça ne serait pas professionnel de laisser repartir ce code en l’état. Mais ce faisant on risque de casser un morceau de code qui finalement fonctionne cahin-caha. Pourquoi cette peur de le casser ? Parce qu’il n’y a pas de tests sûrement. Et quel aurait été le meilleur moyen d’avoir ces tests ? En les faisant avant le dev. Un chapitre résume bien la responsabilité des développeurs face à leur code : « QA should find nothing ». Reste ensuite à creuser les outils à dispo, surtout pour les tests fronts. Mais le jeu en vaut la chandelle.

Gérer son projet

Beaucoup de mises en situation présentées dans l’ouvrage ramènent au fondamentaux de l’agilité. L’artisanat du code demande ce cadre de travail pour pouvoir apporter les bonnes réponses aux clients directs et clients finaux. Au delà du scrum, il fait reposer son discours sur les valeurs du software craftsmanship.

Il valorise énormément le métier de développeur, qu’il reconnait difficile et exigeant, et l’extirpe du rôle de bout de chaîne dans lequel il se retrouve parfois (par fatalisme personnel ou par organisation déficiente). Au centre de la création de valeur, le développeur doit imposer son expertise grâce à une relation transparente et courageuse avec les collaborateurs et partie prenantes.

Il dessine le quotidien d’un développeur professionnel disponible mais intransigeant et ferme. Périmètre fonctionnel, estimations, gestion des dépassements, conflits… Tout cela illustré par de nombreuses mises en scènes.

Il en profite également pour casser quelques mythes. Je note en particulier son passage concernant la « flow zone » à éviter, ce moment où le développeur se sent galvanisé (tard la nuit, ou en musique) et où il pense souvent à tort qu’il déroule des centaines de lignes avec maestria. Quand il sent qu’il entre dans la « zone », il trouve un pair pour casser ce rythme faussement productif. À méditer la prochaine fois qu’on se sentira hyper productif.

L’apprentissage

Le développeur doit apprendre tous les jours, se remettre en question, découvrir de nouveaux horizons. Il valorise énormément les notions de mentoring, de craftsmanship à travers les Dojos, Katas, Pair Programming. Les seniors ont un rôle prépondérant vis à vis des nouveaux arrivants, tant dans l’exemplarité que dans leur capacité à partager leur expérience. Lui qui a connu les cartes perforées parvient à un niveau assez vibrant de discours. C’est le rôle des aînés, pas des écoles ou de l’université d’amener les développeurs à cette attitude professionnelle globale.

Je recommande chaudement la lecture de l’ouvrage à tous ceux qui pense que le métier ne consiste pas qu’à développer. C’est très pertinent, le ton est enlevé et souvent drôlement honnête pour faire passer de grosses pilules de remises en question. Nous en avons commandé une palette qu’on va distribuer à l’équipe pour en discuter et progresser. Prochain point en interne en mode club de lecture, thé, biscuits bières, chips et gros paquet de post-its pour la TODO des semaines à venir.