Comment aborder le sujet du Clean Code en entreprise?

Développement
#1

Salut :)

J’aimerais proposer un atelier clean code à mes collègues de travail mais je ne sais pas trop comment aborder le sujet. Je sais qu’ils sont à priori intéressés par l’idée parce que j’ai fait un petit sondage et les retours ont été plutôt positifs.

Maintenant mon principal soucis c’est de réussir à proposer un atelier qui d’une part puisse intéresser tout le monde car nous n’avons pas tous le même niveau (ingénieurs séniors, ingénieurs juniors, stagiaires alternants) et qui d’autre part éviterait de vexer les gens.

Moi-même je ne suis pas le plus expérimenté donc il pourrait aussi se poser la question de la légitimité à aborder un tel sujet.

L’idée est d’évoquer les points qui pourraient être améliorés au niveau du code source (structure du code, utilisation des commentaires, choix du nommage des variables et des méthodes, utilisation de l’anglais, organisation des packages, etc.) mais aussi des pratiques comme les code review (avec l’utilisation d’outils spécifiques et/ou entre collègues)

Avez-vous déjà eu à créer ce type d’atelier ou bien y avez-vous déjà participé? Auriez-vous des conseils à me donner à ce propos ou des ressource disponibles sur le sujet?

Merci :)

1 « J'aime »
#2

C’est toujours délicat d’avoir une rigueur commune à l’ensemble de l’équipe. Comme tu l’indiques, il ne faut vexer personne. Nous avons tous nos sensibilités et nos avis tranchés sur des points sensibles (tab vs space pour l’indentation pour ne citer que ce débat antédiluvien).

Pourtant, pour le bien du projet je considère qu’un point de convergence des pratiques est nécessaire. S’il est utopique de vouloir l’imposer avec des guidelines que peu liront et encore moins respecteront c’est à la machine de nous aider.

Bouleverser et remettre à plat des années de code legacy est une tache très délicate. En revanche cet atelier Code Clean est bien l’occasion de discuter ce sur quoi on aimerait tendre, pour le code à venir. Une fois qu’un premier consensus est trouvé, je pense qu’il faut le sceller avec des conventions comme http://editorconfig.org, et les linters qui vont bien dans les différents langages (eslint en js par exemple) en commitant le fichier de conf dans chaque projet.

2 « J'aime »
#3

Effectivement, pour ma première approche, l’idée n’est pas d’imposer des guidelines mais plutôt de discuter pour expliquer pourquoi il faut améliorer le code et de quelle façon y parvenir en essayant de mettre le plus de monde possible d’accord :)

#4

Animer ça veux pas dire que tu connais tout ou même que tu as tout le temps raison.

Avoir un support écrit avec des références directs vers le code (genre OpenGrok) en production est nécessaire je pense, avec un système de contribution facile.

#5

Salut,

Pour ma part, j’organise une keynote/meetup interne mensuelle :
une fois par mois, une personne de l’équipe présente une techno, un langage, un projet, une méthodo, un paradigme, un pattern, etc. qui l’intéresse.
ex : la dernière keynote portait sur une démo de NodeJS, et des frameworks qui l’accompagnent.

Ce rendez-vous mensuel pourrait aussi être l’objet d’un “atelier de clean code”.
L’objectif global de l’équipe est de toujours progresser : il n’y a aucune raison que le sujet soit compliqué à aborder.

ps. Bien sûr ces keynote/meetup internes se passent pendant le temps de travail.

#6

Merci pour vos retours :)

#7

Si tu penses que tu as un souci de légitimité, ne fais pas un cours magistral mais des questions. Impossible de tirer sur le messager s’il n’y a pas de messager.
Commence par “j’ai lu ça, ça m’a intrigué”, ponctue éventuellement d’exemples perso, et termine par “qu’en pensez-vous ?”

Je te propose de trouver un article, un blog, un extrait de livre reconnu.
Par exemple un livre de Martin Fowler, un PragProg, une citation de Grace Murray Hopper…

Bon courage et bon code :)

#8

Ou Clean code :)

Sinon lorsque vous aurez trouvé un terrain d’entente pense à fournir des outils et pas seulement des documents. Car par experience sur le papier tout le monde est d’accord mais après quand il faut respecter il y a plus personne.

Néanmoins il faut quand même écrire ces documents (ils feront foi) mais je te conseille par la suite de t’aider d’outils d’analyses comme Sonar, JSHint ou d’autre en fonction de ton environnement qui peuvent grandement contribuer à garder le code clean.

Après dans mon cas même Sonar est insuffisant (car on est en post-push analyse), les gens y vont une fois par mois donc ce que je veux faire comprendre c’est qu’il faut une bonne alchimie entre la formation des gens et leur simplifier la vie avec des outils mais l’un sans l’autre risque d’être vouer à l’échec.

#9

@abelar_s Oui, c’est c’est comme ça que je pensais faire au départ. Prendre des cas concrets et demander ce que les autres en pensent. Comme c’est une première, je ne veux pas déjà partir sur des règles imposées mais plus amener chacun à réfléchir sur pourquoi telle ou telle façon de coder pourrait être améliorée.

@kakawait J’ai ce livre chez moi, mais en version française ^^ Je vais sans doute l’utiliser effectivement.

#10

Je pense que si tu es sensibilisé sur le sujet, ça te donne déjà une légitimité pour animer ce type d’atelier. Et si quelqu’un ne va pas dans le sens de ce que tu exposés, ça crée un débat et c’est pas plus mal. J’ai déjà eu des bonnes douches froides en défendant le principe DRY : il y a des gens qui sont réellement contre, aussi étonnant que cela puisse paraître.

#11

@ethan de mon expérience, c’est effectivement délicat de bousculer les habitudes mais pas impossible.

Je pense qu’un bon moment pour évoquer ces questions sont les rétrospectives de sprint et venir avec un cas concret, c-à-d un cas du projet sur lequel vous travaillez, pour démarrer la discussion. L’idéal est de pouvoir également démarrer la discussion avec une suggestion en la présentant comme un point de départ pour avoir les opinions de tout un chacun.

Par exemple, tu as détecté une duplication dans le code et tu demandes ce qu’ils pensent du DRY et d’une éventuelle solution. Ou alors tu t’es rendu compte que tout le monde ne suit pas la même convention de style, que cela brouille les diff des commits, et que tu proposes la convention la plus proche du style majoritaire et un outil pour checker qu’elle est suivie.

Ainsi, cela génère des discussions collectives, concrètes et avec un résultat direct pour le projet. Dans un second temps, un atelier pourrait être une bonne solution pour dédier plus de temps à cette question. Je ne commencerais néanmoins pas par cela.

1 « J'aime »
#12

Merci pour ton retour :)

J’aime bien ton idée de commencer par des suggestions sur des erreurs repérées dans du code source plutôt que de rentrer tout de suite dans le vif du sujet.

#13

Hello @ethan

Tu peux regarder ce talk pour trouver des idées

Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s