Dimitri Dumont

Développeur front-end freelance

13 novembre 2020

Clean code, écrire du code de qualité - Partie 1

Bonjour, je suis Dimitri Dumont, développeur front-end freelance. Je suis passionné par les notions qui tournent autour du “software craftsmanship”.

J’ai récemment acheté le livre Clean Code — A Handbook of Agile Software Craftsmanship de Robert C. Martin (ou Uncle Bob). J’ai décidé de partager mes notes personnelles prises durant sa lecture.

Si vous souhaitez lire la deuxième partie qui porte sur le nommage, vous pouvez la retrouver en cliquant sur ce lien : cliquez-ici

Il est intéressant de prendre des notes lorsque nous lisons un livre. Cela permet de mieux retenir les notions abordées et de les approfondir.

Ce livre est destiné aux développeurs qui souhaitent s’améliorer. Il aborde le sujet de “clean code”, qui est une notion importante dans notre métier de développeur. Ainsi, le but de cet article est de vous partager mes notes personnelles concernant le premier chapitre de ce livre. Chaque article de cette série vous permettra de découvrir les notions que je trouve importantes. Si le sujet vous intéresse vraiment, vous pourrez acheter le livre et le lire.

Enfin, un autre objectif de cet article, est de proposer du contenu sur la thématique de “clean code” en français.

Clean Code : écrire du code de qualité — Partie 2 Pourquoi et comment écrire du code de qualité (clean code) en tant que développeur ? Quelle est l’importance des noms…

Le code représente les détails des fonctionnalités d’un système. Malgré les progrès du no-code, les avancés technologiques et techniques sur les langages, contrairement à ce que certaines personnes disent, nous aurons toujours besoin de développeurs pour créer des systèmes, des applications ainsi que des sites internet. Il est donc nécessaire de porter une attention au code produit.

Un code de mauvaise qualité est un code développé sans discipline. Nous avons tous écrit du code de mauvaise qualité un jour. On reconnaît ce genre de code au fait de ne pas le comprendre et de ne pas pouvoir y toucher sans avoir peur de tout casser.

La raison la plus récurrente est que le développeur se dépêche de terminer une fonctionnalité ou un projet. Ainsi, il développe rapidement sans discipline pour finir à temps. Il ne prend pas le temps de nettoyer son code produit dans l’urgence. Il se dit qu’il le fera plus tard, que pour le moment il faut se dépêcher de terminer les fonctionnalités qu’il a promis de faire. Il ne reviendra jamais dessus pour faire du refactoring.

Le problème avec le fait de produire du code de mauvaise qualité, c’est que pour le maintenir ou ajouter une nouvelle fonctionnalité, cela devient très compliqué et demande de plus en plus de temps.

Au début de chaque projet, il est facile et rapide de créer et de modifier des fonctionnalités. Mais au fur et à mesure du développement, sans discipline et en voulant aller vite, cela devient de plus en plus compliqué. Il faut alors de plus en plus de temps pour développer le projet.

Ce qui est problématique, c’est que si les développeurs manquent de plus en plus de temps pour développer les nouvelles fonctionnalités, ils créaient de plus en plus de code mauvais. C’est une boucle dangereuse qui fait diminuer la productivité au fil du temps.

Certains développeurs pensent qu’ils sont obligés de produire du code de mauvaise qualité car leur manager, leur client ou tout autre personne leur demande de respecter les délais. Ainsi, ils se contraignent parfois eux-mêmes à travailler rapidement sans porter une attention à leur travail.

Vous avez certainement déjà entendu ou même dit :

• “pas besoin de faire des tests, ça prend du temps, ça va ralentir l’avancée du projet”
• “c’est bon, ça fonctionne, c’est le principal. Je vais refactor plus tard, pour le moment, il faut livrer.”

Ce type de remarques est généralement dites soit par des personnes qui n’ont pas connaissances des effets à ne pas produire du code de qualité, soit par des développeurs pour qui manquent de compétences (ou qui n’ont pas envie de travailler correctement, par fainéantise).

Le but d’un développeur n’est pas uniquement de créer une fonctionnalité et qu’elle soit fonctionnelle. C’est aussi de la rendre facilement maintenable et évolutive.

Si le problème ne vient pas de vous en tant que développeur, mais d’une personne externe qui vous dirige. Elle qu’elle vous oblige à ne pas travailler correctement, rappelez-vous que vous êtes le professionnel. C’est donc vous qui savez comment aller vite en produisant un code solide et durable.

Pour cela, il existe plusieurs solutions, en voici deux :

• vous pouvez échanger avec cette personne, si elle est compréhensive et que vous démontrez les avantages de faire correctement votre travail, il comprendra et vous laissera faire
• si elle est totalement contre le fait de travailler avec les bonnes pratiques, alors ne lui en parler pas. Ne dites pas que vous faites des tests, du refactoring, etc. Etant donné que vous ne perdrez pas du temps et que vous en gagnerez, cette personne ne se souciera pas de la manière dont vous travaillez

Parfois, certains développeurs proposent de réaliser une refonte du projet. Le problème avec cette pratique, c’est que sans discipline, le résultat sera exactement le même que le projet initial.

Vous n’êtes pas obliger de reprendre le projet à zéro, ou d’effectuer des grandes phases de refactoring. Par exemple, lorsque vous devez ajouter une nouvelle fonctionnalité, ou lorsque vous devez en modifier une, vous pouvez commencer par modifier les noms des variables qui ne sont pas définies correctement ou par améliorer une condition if sur le code où vous allez intervenir.

Un code de bonne qualité est un code qui a été développé par des développeurs soucieux de leur travail.

Il est facilement compréhensible grâce au choix du nom des variables, des fonctions, des classes, etc. Vous devez comprendre ce qu‘il fait rapidement.

Ce code doit être correctement organisé grâce au formatage, aux différents design patterns et à son architecture.

Il ne contient pas de duplication, il est facilement testable et a peu de dépendances.

Pour conclure, croire que se dépêcher et qu’écrire du code sans discipline vous aidera à aller plus vite est une erreur. Car comme nous l’avons vu, c’est une boucle qui diminue votre productivité au fil du temps et fait perdre de l’argent au client.

Dans les prochains articles, nous verrons comment écrire du “clean code”.

Si vous souhaitez lire la prochaine partie qui porte sur le nommage, vous pouvez la retrouver ici : cliquez-ici