Comment instaurer des standards de code (sans se faire d'ennemis) ?

Cet article est la suite de l'article sur la cohérence de code, que je vous invite fortement à lire au préalable afin d'avoir un avis plus nuancé sur le sujet ;)

Tout uniforme

Soyons clairs, tous les développeurs aiment la cohérence de code, et c'est normal. L'idée qu'il soit écrit partout pareil est ultra-satisfaisante, et donne l'impression que des gens sérieux et disciplinés se sont mis au travail.

De ce fait, imposer des standards de code semble être une bonne idée. Il ne s'agit que de simples conventions à suivre, rien de bien méchant.

Mais si l'idée est formidable sur le plan collectif, elle l'est beaucoup moins sur le plan individuel, car imposer aux développeurs la manière dont ils doivent faire leur travail, c'est mettre le feu aux poudres.

Qu'est-ce qu'on s'en fout de tous ces rabat-joies, il faut penser à l'équipe d'abord !

C'est un peu facile comme réponse. Pour montrer en quoi c'est vraiment problématique, prenons un exemple qui n'a rien à voir avec l'informatique : la méthode 5S.

Sans rentrer dans les détails, il s'agit d'une méthodologie permettant d'organiser un espace de travail, qu'il s'agisse d'une boite à outils, un plan de travail ou un bureau.

Le quatrième S, seiketsu pour standardiser, dit que lorsqu'on a plusieurs espaces de travail identiques, ils doivent tous être rangés exactement de la même manière.

L'idée est géniale, ça veut dire que si quelqu'un a besoin de quoi que ce soit, même s'il est dans le bureau d'un autre, il saura immédiatement où le trouver.

Mais le revers de la pièce, c'est que les employés ont interdiction d'organiser leur bureau comme ils le souhaitent. Donc si vous avez vos petites habitudes, ou que vous aimez décorer votre bureau, c'est terminé. Vous n'avez plus le droit à votre zone de confort.

Vous vous doutez bien que ça risque de faire des mécontents, en particulier ceux qui avaient trouvé le bureau parfait pour être ultra-efficace. C'est exactement la même chose lorsqu'on instaure des standards de code.

Si un développeur a l'habitude de coder d'une certaine manière et qu'on l'oblige à faire autrement, on ne peut plus attendre de lui le même niveau de productivité. L'humain ne fonctionne pas comme ça.

Pourtant, c'est souvent ce qu'il se passe : quelques têtes pensantes mettent en place des standards, et c'est aux autres de devoir se démerder. C'est un désastre pour la productivité.

Ça l'est encore plus quand ces fameux standards ne sont pas aussi intelligents qu'ils en avaient l'air.

Durant mes recherches, j'ai lu l'histoire d'une personne dont les génies à la tête de son entreprise ont imposé aux développeurs de préfixer chaque nom de classe par le nom de l'entreprise.

Aucun problème, jusqu'au jour où l'entreprise a été rachetée et que les développeurs ont dû changer le nom toutes les classes. Sympa, non ?

Tout ça pour dire que la cohérence de code n'est pas aussi rose qu'elle en a l'air.

Ouais, mais fait chier quoi, ça veut dire qu'on doit se priver des standards de code justes pour ne pas brusquer certaines personnes ?

Je vous rassure, non ! Faire de la cohérence est tout à fait possible, mais c'est beaucoup plus délicat que ça en a l'air, et ça va vous demander quelques tours dans votre sac :

• Du leadership afin de fédérer votre équipe à votre cause.
• De la communication et du travail d'équipe afin de vous accorder avec vos coéquipiers pour trouver un terrain d'entente.
• Des outils afin d'assister l'équipe dans cette démarche.

En vous y prenant bien, vous allez tendre vers l'objectif ultime : avoir du code cohérent tout en préservant l'espace personnel des développeurs.

Avant de se lancer

Avant de plonger la tête la première dans la création d'une charte de développeur (ensemble des standards de code), vous devez vous assurer de certaines choses qui vont peut-être perturber votre enthousiasme, mais qui sont nécessaires pour ne pas faire n'importe quoi.

Nécessité

La première chose, et je dis bien la PREMIÈRE chose à faire, c'est de s'assurer qu'une charte soit vraiment nécessaire.

La cohérence de code est là pour résoudre un problème, qu'il s'agisse d'une codebase pourrie ou de développeurs malpropres. Si votre projet ne possède pas ses problèmes, elle ne va rien accomplir hormis vous faire passer pour le pinailleur de l'équipe.

Je répète ce que j'ai dit dans mon article sur la cohérence : les bons développeurs écriront toujours du code élégant et lisible, peu importe leur style.

Parlez-en

Se rendre compte d'un problème est une chose, le faire comprendre à votre équipe en est une autre, et pour cela, il faut en parler.

Mais attention, ça ne veut pas dire débarquer dans une réunion en déblatérant votre envie de cohérence, on risque de vous regarder avec des gros yeux (et à raison).

Allez-y progressivement, commencez par parler du problème avec vos collègues au détour d'une conversation, mais sans sauter à la conclusion. Plantez des graines, et le jour où vous annoncerez votre plan, ils seront immédiatement de votre côté sans une once d'hésitation.

Meilleur moment

Le meilleur moment pour créer une charte est en début de projet, juste avant la réalisation (l'implémentation). Ça permet de partir sur des bases solides, et ne pas tout foutre en l'air au bout d'une semaine.

Mais si la réalisation a déjà débuté, alors il faut agir maintenant.

Je ne vous le cache pas, remettre au propre du vieux code est super chiant, mais ce sera toujours moins chiant que de faire ça dans un an. Il vaut mieux tard que jamais.

Qualité > quantité

Votre charte ne sera jamais complète, ni même proche, ni même à moitié.

Non seulement c'est totalement impossible, car on peut trouver des milliers de standards avec un peu d'imagination, mais surtout, ça ne sert strictement à rien.

Noyer vos collègues dans une masse de standards est contre-productif, surtout quand ils n'ont pas été murement réfléchis. Il faut aussi leur laisser un peu de liberté.

Concentrez-vous plutôt sur les meilleurs, ceux qui contribuent le plus à la qualité de la codebase. Si votre équipe est déjà très professionnelle, il se peut qu'une petite dizaine fasse l'affaire. Rien de choquant à ça.

Le bon (et le mauvais) standard

Mettre en place des standards dangereux est le pire truc qui puisse vous arriver, bien pire que de ne pas en avoir du tout. Donc un petit aparté sur les critères d'un bon standard ne fait pas de mal.

Il y en a 5 critères sur lesquels j'apporte beaucoup d'attention. Aucun n'est plus important que l'autre.

Hormis le premier, il s'agit de critères nuancés. Plus un standard rentre loin dans ces critères, plus je le considère comme étant un bon standard.

Adaptation

Certains standards sont déjà forcés par votre langage ou votre framework, et il n'y a pas grand-chose à faire à part les suivre.

Typiquement, si vous développez en .NET, vous allez forcément devoir utiliser la bibliothèque System. Or celle-ci applique déjà ses propres standards : les noms de propriétés et de méthode sont en PascalCase, elles ne possèdent pas de caractères spéciaux, les noms de paramètres sont en camelCase, les noms sont tous en anglais…

Et comme Microsoft n'a pas l'intention de renommer tous ses modules pour votre projet, vous allez devoir vous plier aux règles.

Bénéfices

Les meilleurs standards sont ceux qui ont une utilité, même si elle n'est que cosmétique. Pour chaque standard, il est primordial de se demander pourquoi il est meilleur que ses alternatives.

Voici quelques exemples :

list.Any()
list.Count > 0 // Plus optimisé

list.SingleOrDefault(...) // Exception si plusieurs résultats
list.FirstOrDefault(...) // Plus optimisé

List<string> list // Plus lisible
var list // Moins de couplage

Simplicité

Il ne faut jamais mettre en place de standards non automatisables ou identifiables par un programme ou un IDE. Devoir appliquer la charte manuellement est bien trop chronophage pour être rentable.

Or, certains sont bien plus difficiles à faire respecter que d'autres, et généralement, il vaut mieux ne rien avoir du tout que des standards juste partiellement respectés.

Non-criticité

Les standards de code ne doivent pas être d'une utilité critique sur la codebase. Ils ne doivent pas être mélangés avec l'architecture, les performances ou la sécurité.

Pourquoi, ce n'est pas justement ça qui fait un bon standard ???

Non, car un standard n'est qu'une règle instaurée pour le confort des développeurs dans l'écriture et la lecture du code.

Ce n'est qu'un détail, souvent lié au langage ou à un framework, complètement détaché des exigences.

Bien sûr, certains standards peuvent avoir un bénéfice sur ces 3 domaines, mais ils ne révolutionnent jamais le design d'une codebase. Si vous me dites que si, alors vous avez surement affaire à un design pattern, et non pas un standard.

Préférence

Pas les préférences de la personne qui rédige la charte, mais de celles qui l'utilisent : l'équipe de développeurs.

Si une équipe arrive à se mettre facilement d'accord sur un standard, c'est très bon signe, car ça signifie qu'il est déjà présent dans la zone de confort de tout le monde, ce qui résout le dilemme des bénéfices individuels contre les bénéfices collectifs.

Par contre, j'ai un doute. Tu disais que ces critères sont nuancés, mais du coup, comment savoir si un standard est « assez bien » pour être retenu ?

Tout dépend de l'ampleur du problème.

Si une majorité des personnes de votre équipe est vraiment à l'ouest, mettez la barre basse pour uniformiser un maximum et empêcher les développeurs de partir en roue libre.

En revanche, si vous avez une équipe qui produit déjà du bon code, mettez la barre haute pour ne garder que les meilleurs, et laissez le reste ouvert à la préférence.

Choisir ses standards…

Quelle que soit votre méthodologie, la règle d'or est qu'une charte doit toujours être définie par les gens sur le terrain : les développeurs du projet.

Une règle simple, mais qui n'est que très rarement appliquée. En général, je vois plutôt les situations suivantes :

• Charte imposée par l'entreprise.
• Charte construite par une minorité de l'équipe.
• Charte repompée d'un ancien projet.
• Charte reprise des recommandations d'un outil (IDE, analyseur…) ou d'une entreprise (Google, Microsoft…).

C'est vraiment dommage, car chaque nouveau projet est l'occasion d'apprendre de ses erreurs et d'innover dans les standards retenus.

C'est pourquoi je recommande de remettre tous les standards à plat à chaque nouveau projet.

Cela ne veut pas dire qu'il ne faut pas s'inspirer d'autres sources, il ne faut juste pas les repomper comme un cancre.

Tout standard doit être requestionné par l'équipe, même si ça finit sur un accord unanime au bout de 10 secondes.

Mais comment on « requestionne » au juste ?

Bonne question ! Mon approche fétiche est celle de la réunion de définition des standards.

Toute l'équipe doit y participer, surtout les développeurs avec le plus d'expérience. Et comme vous êtes la personne qui a suggéré la création d'une charte, vous aurez la responsabilité de l'animer ! 😃

Cette réunion se déroule en 3 étapes (+1 pour vous seul).

Contexte

Il s'agit simplement de rappeler l'objectif et le plan de la réunion. En gros :

1. Rappelez la problématique (code horrible entrainant une perte de productivité), et la solution que vous voulez mettre en place pour y répondre (cohérence de code).
2. Annoncez l'objectif de la réunion : choisir les standards en équipe afin que tout le monde ait une voix.
3. Annoncez le plan de la réunion.

Brainstorming

Cette étape est plutôt simple : noter les idées de tout le monde sans aller dans les détails. Chaque idée représentera un point à aborder lors de la prise de décision.

Une technique efficace est celle du brainstorming où les gens proposent leurs idées de manière un peu désorganisées.

Je ne vais pas rentrer dans les détails, car ce n'est pas le sujet, mais voici quelques lignes directrices :

• Essayez de faire parler tout le monde.
• Faites en sorte que les personnes ne s'influencent pas les unes des autres, en utilisant une méthode telle que celle des post-its.
• Notez toutes les idées, même les absurdes. Vous aurez tout le temps de les dégager après.

Le but est principalement de définir la durée de la réunion. Plus il y a d'idées, plus la réunion sera longue, donc il faut savoir quand vous arrêter.

N'oubliez pas qu'il faut être qualitatif. Il vaut mieux couper court au brainstorming et passer à la suite directement (quitte à faire une seconde réunion), que de devoirs foncer et se planter sur la prise de décision.

Prise de décision

C'est l'étape principale de la réunion, et de très loin la plus longue.

Le but est de repasser sur chaque standard noté pendant le brainstorming, et de déterminer s'il fera partie de la charte ou non en vous inspirant des 5 critères que j'ai cités au-dessus.

Pour certains, ça prendra 30 secondes, les idées moisies seront rapidement rejetées, et les évidentes vite acceptées.

Le gros du travail se cache dans les points les plus controversés, car ils risquent de générer des débats houleux.

Même quand ces débats débouchent sur plein de très bonnes perspectives concernant les bénéfices et dangers d'un standard, il ne faut surtout pas négliger la préférence des utilisateurs.

S'ils arrivent à trouver un terrain d'entente, ou si une partie s'est laissée convaincre, c'est parfait.

Mais si vous remarquez que les développeurs sont bloqués sur leurs positions, il est préférable de couper court au débat et de laisser le standard ouvert à la préférence.

Vous n'aurez certes pas de cohérence à ce niveau-là, mais c'est moins grave que de démarrer une guerre idéologique, surtout quand les arguments des deux parties sont très bons.

Rédaction de la charte

Une fois la réunion terminée, tout le monde quitte la réunion bouillante de chaleur cognitive direction la machine à café pour le débrief. Sauf vous, car il faut bien que quelqu'un documente tout ce bazar.

Une charte de développeur est le document qui contient tous les standards. C'est un mode d'emploi sur ce qu'il faut faire et ne pas faire, comme la notice d'un médicament.

Le format que je recommande est le suivant :

• Faites tout dans un seul fichier, c'est plus simple pour la navigation et la recherche (CRTL+F).
• Écrivez de manière claire et concise, dans un Français digne des meilleures œuvres d'Hugo.
• Faites ça dans un fichier markdown, et mettez-le à la racine ou dans la section docs de votre dépôt. Ça permet de la consulter directement depuis votre logiciel de contrôle de code source (GitHub, GitLab…).
• Lister les standards un à un en indiquant leur intitulé en quelques mots, et si besoin, un paragraphe avec quelques détails (bénéfices, cas particuliers…).
• Ayez une logique dans l'ordre des standards, ne passez pas du coq à l'âne. Éventuellement, organisez-les en catégories, avec des titres et des sous-titres.

Je vous invite aussi fortement à renseigner en bas les standards ouverts à la préférence, afin de rappeler à l'ordre les développeurs qui veulent un peu trop imposer leur point de vue à tout le monde.

… et les faire respecter

Votre charte est sur pieds, c'est incroyable, je suis tellement fier de vous !

Mais une charte de développeur est inutile, le principal, c'est de la faire respecter.

Il y a 3 solutions qui s'offrent à vous, rangée de la meilleure à la pire.

1. Automatiser l'application de ces standards à la sauvegarde ou à la compilation.
2. Automatiser l'application de ces standards via un outil à lancer manuellement.
3. Signaler aux développeurs les endroits où la charte n'a pas été respectée.

Si aucune de ces 3 solutions n'est possible, ce n'est même pas la peine.

Beaucoup se contentent de la bonne volonté des développeurs, mais c'est juste contre-productif, en plus d'être approximatif.

Attention, ça ne veut pas dire qu'ils n'ont pas besoin de connaitre la charte, elle est primordiale pour mieux comprendre le code. Mais en pratique, ils ne devraient pas avoir à s'en occuper.

Toute leur attention doit être placée sur les exigences, la sécurité, les performances et l'architecture.

Malheureusement, la plupart des outils sont trop dépendants des langages pour que je vous en conseille en particulier, mais je vous ai quand même mis 3 pistes à explorer :

EditorConfig

Il s'agit d'un simple fichier .editorconfig que l'on place à la racine du code source afin de modifier légèrement le comportement de l'éditeur de code. Par exemple, passer des indentations d'espaces en tabs, enlever les espaces à la fin d'une ligne…

Ils sont ridiculement simples à configurer, compatibles avec énormément d'IDE et directement intégrés au code source. Ainsi, n'importe qui peut en bénéficier sans rien installer, hormis une extension pour certains IDE.

# All files
[*]
indent_style = tab
end_of_line = crlf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

Analyseurs statiques de code

Il s'agit d'outils, qui vont relever des alertes à l'IDE concernant la qualité du code. Par exemple : une méthode non statique qui devrait l'être, une ambiguïté dans la syntaxe, un irrespect des conventions de nommage…

Contrairement aux EditorConfig, ils ne lisent pas le code,ils savent comment il fonctionne, ce qui en fait de vrais petits assistants de codage.

La plupart sont directement rattachés au code source et installables sous forme de paquets. En revanche, ils ne sont pas multilangages, et ne fonctionnent qu'en présence d'un serveur de langage, car c'est lui qui fait l'interface entre l'analyseur et l'IDE.

Donc si vous avez l'habitude programmer avec Bloc-note, c'est mort.

Configuration d'IDE

Il s'agit de paramètres modifiables directement depuis l'IDE pour qu'il prenne en charge automatiquement les standards. Ils sont souvent représentés sous forme de fichiers (XML, JSON…).

Comme l'IDE héberge le serveur de langage et qu'il a un droit d'écriture sur le code, c'est probablement l'outil le plus puissant de cette liste, mais aussi celui avec le plus de contraintes.

En effet, ça demande déjà que tous les développeurs possèdent le même IDE, ce qui n'est pas forcement possible, par exemple, si l'on travaille avec des prestataires externes. Et si l'IDE en question est payant, ça peut vite chiffrer.

Mais en plus, ça couple votre charte avec votre IDE. Donc si vous changez d'outil, vous perdez toute votre capacité d'automatisation.

Voilà pour l'application des standards de code. Tout ce processus peut vous sembler un peu fastidieux, mais franchement, ne le négligez pas !

Trouver le juste milieu entre le confort des développeurs et la cohérence est déjà assez difficile, ça serait dommage de se viander par pure flemme !

Concernant la cohérence de code, avec l'article précédent et le bonus, je n'ai plus rien à ajouter, donc si vous avez tout lu, vous devez être au taquet sur sujet !

Si c'est le cas, soutenez le blog en partageant cet article (merci 💙) et venez me faire un coucou sur Twitter @ITExpertFr.

Et pour ceux qui aiment le code propre de chez propre, j'ai quelques articles pour vous :

• Cohérence de code : idée en or ou pétard mouillé ?
• La règle NUMÉRO 1 pour écrire du code impeccable.
• Ne vous répétez pas ! JAMAIS !!

Quant à moi, je vous laisse, je me suis préparé un bon bol de Miel Pops et j'ai hâte de le déguster.

À bientôt pour un nouvel article sur le blog des développeurs ultra-efficaces. Tchao !

Accéder au bonus : Notes inintéressantes sur les standards de code.