Popularisé par Robert C. Martin (« Uncle Bob ») dans son livre intitulé « Clean Code: A Handbook of Agile Software Craftsmanship », le Clean Code ne représente pas un ensemble de dogmes mais désigne une pratique qui vise à concevoir et produire un code lisible, compréhensible, intuitif et facile à manipuler. Il est très facile à entretenir, et n’est pas dépendant de son développeur initial. Ce qui revient à dire que le code ainsi produit est immédiatement intelligible par n’importe quel développeur qualifié.
Si cette démarche qui prône la qualité et la maintenabilité est parfaitement compréhensible, sa mise en œuvre n’est pourtant pas aussi évidente. Nicolas Barlogis et Julien Vitte, coachs Software Craftsmanship, nous partagent leurs visions du Clean Code dans cette interview croisée.
Pouvez-vous nous donner votre définition du Clean Code ?
NB – Définir le Clean Code c’est souvent très compliqué, car tout le monde ne se fait pas la même idée de ce à quoi ressemble un code efficient, selon les développeurs, les contextes de projet, les entreprises… Mais définir ce que n’est pas le Clean Code, le « code sale », est beaucoup plus facile !
JV – En effet la pratique Clean Code vise à créer du code qui va être maintenable, ce qui peut être interprété différemment selon les personnes. Du code estampillé Clean Code est un code « propre » qui se comprend et qui se lit facilement, qui est intuitif, et qui permet d’onboarder de nouveaux développeurs sur un projet plus efficacement. Attention cependant, si certains principes sont assez objectifs et peuvent s’appliquer de manière identique dans 90% des cas, d’autres sont dépendants du contexte dans lequel ils sont mis en place.
NB – A mon sens un des principaux piliers du « code propre » est le nommage, qu’il s’agisse des classes, des variables, des méthodes… Il est possible de disposer d’un code qui n’est pas parfait techniquement, mais avec un nommage très explicite et qui incorpore du vocabulaire métier. Ce code est alors très facile à modifier et faire évoluer. Il est selon moi à préférer à un code disposant d’une architecture très intelligente, mais incompréhensible en dehors de celui qui l’a développé.
JV – Il faut limiter la charge cognitive lors de la lecture du code. C’est plus facile de lire quelque chose qui est proche du langage naturel. Et quand il faut apporter une nouvelle fonctionnalité, il n’est pas nécessaire de maitriser l’ensemble de la base de code pour y arriver. Si la complexité technique est « masquée », le programmeur peut alors vraiment se focaliser sur la partie à modifier. C’est ce qu’on appelle du détail d’implémentation.
Pour en savoir plus sur notre parcours de formation dédié au Clean Code !
Quelle est la relation entre le Clean Code et la démarche Craftsmanship ?
NB – Le Software Craftsmanship est une démarche d’ouverture d’esprit, car il faut se mettre dans une posture d’amélioration continue, et donc de remise en cause permanente. Il faut apprendre constamment de nouvelles choses, donner du sens à son travail et apporter de la valeur aux utilisateurs. C’est prendre conscience qu’il faut arrêter de délivrer des logiciels ou des fonctionnalités qui deviennent inmaintenables au bout de deux ans, avec une qualité de code discutable et comportant de nombreux bugs… Il faut être fier de son code et ne pas avoir à le cacher.
JV – En effet l’idée du software Craftsmanship est essentiellement basée sur une démarche d’amélioration continue. C’est un principe Agile qui peut s’appliquer aux compétences d’un développeur. Il met en avant la fierté et la satisfaction du travail bien fait, la démonstration d’un savoir-faire, mais tout en gardant une démarche pragmatique parce qu’il faut répondre à des besoins utilisateurs. Une démarche que l’on retrouve jusqu’au cœur du code avec le Clean Code. Les deux concourent à une plus grande maintenabilité et évolutivité des applications.
Est-il facile de faire du clean code au quotidien ?
NB – Il suffit de casser des réflexes basés sur des habitudes de programmation qui n’ont plus de sens aujourd’hui, comme le nommage très contraint. L’époque où il fallait stocker un nom de variable sur quelques octets, avec moins de dix caractères, est bien loin.
JV – Ces limites n’existent plus aujourd’hui, il est possible de faire de longues phrases, et même de coder avec des accents pour écrire en Français ou intégrer des espaces insécables.
NB – Pourtant encore beaucoup de développeurs redoutent de mettre des noms longs ou très explicites. Si l’un d’entre eux cherche un nom pour nommer « ça » qui est une variable qui stocke « ceci » ou « cela » en « faisant ça », pourquoi ne pas simplement dire ce que fait cette variable, en faisant une phrase. Qui plus est, il existe aujourd’hui des IDE (Integrated Development Environment), des environnements de développement, avec des fonctions d’autocomplétions. Ça ne prend donc pas plus de temps d’écrire des noms explicites ou de faire des phrases que de perdre du temps à trouver un nommage court incompréhensible.
JV – C’est le paradoxe de notre métier, car beaucoup d’ingénieurs logiciels utilisent des principes théorisés dans les années 70, avec des limites techniques qui n’existent plus, mais qui freinent encore certaines façons de faire.
Quels sont vos conseils pour commencer à faire du clean code ?
JV – Il faut déjà que tout le monde dans un projet s’accorde sur une définition du clean code. Car j’ai pu voir, dans mes ateliers, des équipes avec des bonnes pratiques de code reviews, mais qui ont du mal à se mettre d’accord sur ce qui est « clean ». Une approche collaborative est ainsi nécessaire pour établir des conventions de codage partagées au sein de l’équipe, par exemple en matière de nommage, de structuration des classes, de documentation, commentaires…
Il existe des ateliers pour bien débuter comme le Crappy-Driven Development. Son but est de partir d’une base propre et de la « salir », pour obtenir une liste « d’anti-patterns » à éviter, et trouver ce qui est voulu à partir de ce qui est identifié comme n’étant pas voulu. C’est un raisonnement inversé que l’on retrouve dans l’approche TDD, Test Driven Development, qui vise à écrire le test d’un code avant décrire le code même. Une fois que l’équipe a des standards de code explicites et partagés, elle est capable de s’assurer qu’ils sont respectés dans le code produit. Elle dispose ainsi d’un point de départ pour enrichir ses compétences.
NB – Si à l’issue des ateliers de formations les intervenants sont convaincus de la démarche, ce n’est pas pour autant si facile de se lancer la première fois. Je conseille toujours de travailler au moins à deux au début, même si les deux développeurs sont débutants. Car c’est avec les compréhensions et les interprétations de chacun, les discussions, les échanges, qu’ils arriveront à comprendre la logique, évoluer et monter en compétence. Et pour acquérir les bons automatismes il faut également faire de nombreux exercices, des katas, avec des exemples restreints sur lesquels il faut appliquer une technique. L’intérêt étant de choisir des katas disposant de résolutions consultables en ligne, faites par des architectes logiciels de renom. Ces résolutions sont d’autant plus intéressantes quand leur auteur donne également des explications sur son flux de pensées, et guide son raisonnement pas à pas.
Le Clean Code est un code qui se comprend et qui se lit facilement, qui est intuitif, et qui permet d’onboarder de nouveaux développeurs sur un projet plus efficacement.
Chez Inside, nous accompagnons les entreprises dans l’adoption des meilleures pratiques de développement, dont le Clean Code. Notre expertise en Software Craftsmanship et en coaching technique nous permet de vous aider à intégrer ces principes au cœur de vos projets.
Vous souhaitez en savoir plus sur la manière dont le Clean Code peut transformer vos processus de développement ? Échangez avec nos experts et découvrez comment Inside peut vous accompagner pour améliorer la qualité de vos logiciels et maximiser votre efficacité !
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la pratique Clean Code, c’est par ici !