Cet article s’adresse à toutes les personnes concernées de près ou de loin par du code et/ou par du travail en équipe, aux développeurs, aux futurs développeurs, aux simples curieux.
Aujourd’hui, les lignes de code occupent une place de plus en plus importante dans notre société. On entend sans cesse parler d’ “algorithmes”, les objets connectés deviennent omniprésents dans notre quotidien et de nombreux métiers sont contraints de plonger dans la programmation. Les personnes concernées se retrouvent à coder sans jamais avoir appris les principes de base pour réaliser du code de bonne qualité… Et j’irais même jusqu’à dire que les développeurs qui sortent de formation sont pour la plupart incapables d’en produire, les enseignements étant davantage orientés sur la rapidité et la technicité de la production plutôt que sur sa qualité.
Par ailleurs, il y a quelques années, j’ai découvert “Les quatre accords toltèques”. Les accords décrits dans ce livre sont rapidement devenus un moteur pour essayer de m’améliorer au quotidien. Grâce à eux, j’ai pu progresser dans beaucoup de domaines, et l’ensemble m’a permis d’améliorer considérablement ma prise de recul, mes capacités à interagir avec autrui et par conséquent mon bien-être.
Récemment, j’ai réalisé que les bonnes pratiques de code et ces quatre accords se rejoignaient en de nombreux points. En appliquant les accords au développement et aux équipes de développeurs, je me suis rendu compte que ça facilitait la mise en place des bonnes pratiques et leur conservation dans le temps
Je vais donc, pour chacun des accords, expliquer brièvement en quoi il consiste et comment on peut l’appliquer aux développeurs.
Premier accord : Que votre parole soit impeccable
En substance, cet accord nous explique (confirme ?) que les paroles ont un pouvoir qui est bien au-delà ce qu’on pense. Elles peuvent agir insidieusement, sur le long terme, comme un poison. Il faut donc s’en méfier et prendre garde à ne prononcer que des paroles saines. Tout ce qui ressemble à une parole destructrice, à du jugement, de la médisance, des ragots, de l’intolérance, des insultes, des mensonges ou qui pourrait faire culpabiliser quelqu’un doit être banni. Heureusement, ça fonctionne également dans l’autre sens ! Et c’est également vrai quand ce quelqu’un est soi-même.
Au quotidien dans les relations avec les autres et donc avec les autres développeurs, c’est par exemple penser à féliciter les gens, faire des critiques constructives, éviter de critiquer tel membre de l’équipe devant les autres, valoriser les gens, etc. C’est en phase avec les méthodes de management basées sur la bienveillance qui émergent aujourd’hui. Ce sont aussi les principes qui sont utilisés dans la métaphore du “manager-jardinier”, qui part du principe qu’on ne fait pas pousser les plantes en tirant dessus.
Dans le développement, aussi vrai qu’il faut garder une parole impeccable, il faut écrire du code impeccable. Le code sera amené à être relu, modifié, inspecté, corrigé… Par vous, ou par d’autres. Il faut que cet exercice soit rendu le plus simple possible. Il y a différentes règles que l’on peut retenir pour ça, je vais en détailler certaines ici.
Utiliser des noms explicites
Les variables, les fonctions et méthodes et les classes doivent toutes être nommées de manière à ce que l’on sache à quoi elles servent. Si on n’est pas capable de trouver ce nom, il est vraisemblable que le périmètre soit mal défini, mal compris, mal appréhendé. Le nom doit définir l’intention et ne pas utiliser de termes génériques. Par ailleurs le rôle de chaque élément du code doit pouvoir être décrit facilement. Dans Coder proprement, Robert C. Martin donne l’astuce suivante : une classe doit pouvoir être décrite en 25 mots environ sans utiliser « si », « et », « ou » et « mais ». Si vous n’y arrivez pas, revoyez la conception et le découpage !
Respecter les niveaux d’abstraction
Une parole impeccable ne mélange pas tous les concepts, un vulgarisateur n’entre pas dans les détails techniques, un cours d’introduction énonce uniquement les grands principes et les enjeux. De la même manière, le premier niveau de lecture du code, celui par lequel on commence à appréhender le programme, doit être parfaitement intelligible d’un point de vue fonctionnel. J’ai pour habitude de dire aux personnes que je forme que la première couche de leur code doit pouvoir être lue et comprise par n’importe qui, développeur ou non. Plus on descend dans le code, plus il va être technique.
Respecter la règle de décroissance
Le code doit pouvoir se lire dans l’ordre. Dans une classe, on trouvera d’abord les méthodes fonctionnelles, de plus haut niveau d’abstraction. Elles-même appelleront des méthodes situées plus bas dans le code et plus techniques.
Faire court (encore plus court !) et simple (et encore plus simple !)
Quand une parole est courte et simple, il y a de grandes chances qu’elle soit comprise. Quand elle est longue et compliquée (imaginez une réponse typique de politique en 4 points ayant chacun 4 sous-parties), vous êtes à peu près sûr de ne plus comprendre votre question à la fin de la réponse. En programmation, c’est la même chose. Un code court et simple a toutes les chances d’être facile à comprendre plus tard, par autrui ou par vous-même. Un code très long et très complexe a toutes les chances d’être bogué jusqu’à la moelle et difficile voire impossible à corriger.
Dans la même idée, les signatures des méthodes doivent avoir le moins d’arguments possible. Ça aide considérablement à respecter la règle sur les niveaux d’abstraction et à écrire les tests pour lesquels vous n’aurez pas de multiples combinaisons d’arguments à tester.
Mettre en forme
Quand on parle et qu’on écrit, la ponctuation et les respirations sont fondamentales. Le fameux exemple “On va manger les enfants / On va manger, les enfants” représente bien le problème qu’une ponctuation défectueuse peut entraîner. Dans le code, c’est la même chose ! On dispose de moyens d’aérer le code en espaçant plus ou moins les lignes, son indentation permet d’identifier immédiatement les blocs d’instructions. Un code simple peut rapidement s’avérer illisible s’il est mal espacé et mal indenté.
Dans la même idée, le style doit être uniforme. Tous les développeurs de l’équipe doivent choisir un style ensemble. Pas leur préféré, pas celui qu’ils utilisaient sur leur projet perso y a deux ans, celui qui est choisi et accepté par toute l’équipe.
Second accord : Quoi qu’il arrive, n’en faites pas une affaire personnelle
Cet accord est essentiel. De nombreux conflits pourraient être évités s’il était respecté à tous les niveaux de notre société. Il nous explique que ce que les gens disent de vous n’est que la projection de leur vision des choses. Les gens ne sont pas omniscients, ils font des suppositions, leur parole n’est pas impeccable… Il faut vous immuniser contre ça. Vous savez pourquoi vous faites telle ou telle chose, et ça sera forcément mal perçu par certaines personnes. Cela ne doit pas vous atteindre.
Accepter les aides et critiques
Au quotidien, dans une équipe de développeurs, le second accord est essentiel pendant les phases de conception, de débogage et de revue de code. En effet, garder ça en tête permet d’être bien plus réceptif aux critiques et aux réactions des gens face à vos choix. Si on s’énerve à chaque fois qu’un bout de code qu’on a écrit est remis en cause, il faut arrêter de coder, ça arrivera tout le temps.
Vous voyez ce bug qui vous met en échec depuis 2 heures ? Deux heures de réflexion intense, de nœuds au cerveau qui feraient pâlir n’importe quel marin ? C’est en général là que quelqu’un passe, regarde rapidement par dessus votre épaule… Et vous explique que ce problème si compliqué se résout en 3 secondes avec la commande qui va bien. Et bien non seulement il faut l’accepter… Mais en plus il faut réussir à remercier cette personne !
Travailler en binôme
En informatique, il existe de nombreuses méthodologies de travail. L’une d’entre elle, appelée XP pour eXtreme Programming, prône, parmi d’autres concepts, le travail en binôme. Le principe est simple, appliqué de manière extrême, il n’y a qu’un poste pour deux développeurs. Ils travaillent toujours ensemble sur le même sujet. Un des deux a le clavier et la souris, l’autre observe l’écran. Le niveau d’interaction est très élevé : celui qui code explique son raisonnement et l’autre prend du recul et critique. Quand un point de blocage survient ou au bout d’un certain temps, les rôles sont inversés. C’est extrêmement efficace !
La taille et le mode de fonctionnement de l’organisation ne permettent pas toujours d’appliquer ça à 100%, mais il faut garder en tête cette méthodologie a minima pour les algorithmes compliqués ou pour démarrer les projets. Ainsi, la connaissance est mieux répartie et on est sûr de ne pas partir tête dans le guidon. Et dans ce cas là, ne pas faire une affaire personnelle des remarques de son binôme est indispensable.
Ce raisonnement est extensible à la revue de code et à chaque moment où on interagit avec les autres développeurs.
Troisième accord : Ne faites aucune supposition
Sans doute l’accord qui me sert le plus au quotidien. Ne pas supposer. Attendre ou chercher l’information avant de prendre une décision, avant de s’inquiéter, avant d’être en colère, avant de faire quelque chose qu’on regrettera. Dans la grande majorité des cas, la supposition est un fantasme qui mène à des situations compliquées sans raison.
Dans le développement, c’est extrêmement important. Ne supposez pas que le client désire telle ou telle chose. Il veut autre chose. Ne supposez pas qu’un autre développeur a eu telle intention. Son intention était différente. Ne supposez pas que ça va fonctionner. Ça ne va pas fonctionner. Ne supposez pas que vous allez vous en rappeler. Vous allez oublier.
Faites des spécifications, discutez avec les autres développeurs et surtout, faites des tests ! Et faites-les bien, ils doivent répondre au même niveau d’exigence que le reste du code, sinon ils sont inutiles. Là encore, le nommage impeccable est important, ça évite énormément d’occasions de faire des suppositions.
Travailler en TDD
Le TDD, Test Driven Development, est une méthode qui consiste à commencer par écrire les tests. Cela permet d’identifier très vite les endroits sujets à supposition. Si vous devez faire une supposition pour écrire un test, c’est que la spécification est mauvaise ou que la demande client n’est pas claire. Si vous vous lancez dans le développement à ce moment-là, vous êtes sûr de supposer des choses qui s’avèreront fausses par la suite.
Commenter utile
Un code qui est bien nommé et bien organisé n’a généralement pas besoin de commentaires. Si les noms des variables, des méthodes et des classes sont explicites, pas besoin d’ajouter un commentaire qui répète le titre. Un commentaire doit uniquement servir à aider un relecteur à prendre pied dans un morceau de code. C’est le cas par exemple pour un algorithme complexe.
Respecter le principe de responsabilité unique
Les variables, les fonctions et méthodes et les classes doivent toutes se cantonner à une responsabilité unique. Cela permet de comprendre tout de suite à quoi sert telle ou telle partie du code. On gagne ainsi un temps remarquable lors des phases de débogage… Quand il en reste. Ça va généralement de pair avec le nommage : une fonction dont le nom comporte un “et/and” ne respecte à coup sûr pas le principe de responsabilité unique. Dans les arguments des méthodes, proscrivez les booléens. Un booléen signifie que la méthode peut faire au moins deux choses, mettant encore une fois à mal le principe de responsabilité unique !
Quatrième accord : Faites toujours de votre mieux
Ce dernier accord est la clé pour réussir à appliquer les trois premiers. Personne ne peut, du jour au lendemain, avoir une parole impeccable, ne plus rien prendre pour soi et ne plus faire de supposition. Par contre, on peut avoir conscience de tout ça et, jour après jour, essayer d’analyser les fois où on a échoué, où on a dit quelque chose qu’on n’aurait pas dû, où on s’est rendu malade pour les paroles (qui n’étaient pas impeccables !) d’un collègue et essayer de faire mieux la fois suivante.
Personne ne peut du jour au lendemain écrire un code parfait. Il faudra essayer, rater, essayer encore, observer les autres développeurs, les voir échouer aussi. Réfléchir, remettre en question, ne pas avoir peur de recommencer. Il faut du travail, encore du travail. Il ne faut pas remettre à plus tard les améliorations et corrections de code, sinon ça ne sera jamais fait. Et toujours faire de son mieux !
A contrario, il ne faut pas vouloir faire du code parfait à tout prix. Il ne le sera jamais du premier coup. L’objectif principal reste que le code produise le résultat attendu, c’est la première chose à obtenir. Une fois qu’on a réussi, que les tests passent, on peut alors nettoyer et tendre vers le code parfait.
Cet article ne se veut pas et n’est pas exhaustif à propos des bonnes pratiques de programmation. Il en reste énormément et je vous invite à lire les livres cités à la suite si vous voulez en savoir plus. De manière générale, il n’est pas suffisant pour coder correctement, cet objectif n’étant atteignable qu’en travaillant énormément.
Cet article a été inspiré par les éléments suivants :
- Les quatre accords toltèques – Miguel Ruiz
- Coder proprement – Robert C. Martin @unclebobmartin
- Coder efficacement – Philippe Dunski
- Programmez avec le langage C++ – Mathieu Nebra @m_nebra, Matthieu Schaller
- Mon expérience de développeur, de responsable de développeurs et d’être humain
Si vous voulez discuter de mon interprétation des accords et des bonnes pratiques de programmation, laissez un commentaire. Je serais ravi d’en débattre et d’améliorer mon article en conséquence !
2 comments for “Le développeur toltèque”