Clean Code et bonnes pratiques
Ne soyez pas un exécutant, devenez un artisan
Dans cet article, je vais vous parler de mon retour d’expérience sur les aspects du clean code et le désavantage de ne pas être un artisan de la qualité !
Retour d’expérience
Je me suis aperçu au travers des différentes applications sur lesquelles j’ai eu l’occasion de travailler, que certaines règles de bonnes pratiques n’étaient pas respectées.
Ce qui est dérangeant, c’est qu’une bonne partie des développeurs expérimentés ont conscience du problème et qu’à la question : “Mais, si vous en avez conscience, pourquoi ne pas les mettre en place ?”, les réponses sont quasiment toujours les mêmes :
- “On n’a pas trop le temps de faire de la refacto, ou de perdre trop de temps sur ce sujet. Tant que ça fonctionne, c’est le principal.”
- “On doit livrer rapidement.”
- “L’objectif principal, c’est ce que le client voit.”
- “Oui, on a commencé à mettre en place des tests unitaires, mais nous n’avions plus de temps pour les maintenir.”, etc.
Même si ces réponses sont pour moi aberrantes, certaines peuvent être compréhensibles selon le contexte. On remarque dans la plupart de ces réponses que le “temps” ou “la peur d’être en retard sur le planning” reviennent souvent.
J’ai pu m’apercevoir, grâce à mes diverses missions chez des client au corps de métier totalement différents, que seuls quelques-uns sont réellement sensibles à la mise en place de bonnes pratiques visant la qualité.
En 2023, je trouve cela navrant et irréfléchi.
Pourquoi allez-vous me dire ? Car tout le monde a entendu parler des bienfaits du clean code, des pratiques de craftmanship et j’en passe.
Seulement, très peu les mettent en place et ce n’est pas pour leur bien, c’est une certitude !
De ce que j’ai pu observer, les deux raisons principales sont :
- Le je-m’en-foutisme total
- Le soi-disant manque de temps
Dans les deux cas, c’est perdu d’avance ! L’application est vouée à être instable et non pérenne.
Notre travail en tant que développeur n’est pas seulement de coder sans réfléchir, mais aussi d’apporter des conseils. Il est de notre devoir de faire comprendre aux clients et aux chefs de projet que la qualité n’est pas une option. Elle fait partie intégrante de notre travail !
Lorsque l’on construit des tests unitaires ou que l’on passe du temps à rendre compréhensible une fonction compliquée, en réalité ce n’est pas du temps perdu, bien que cela soit vu comme tel par certaines personnes.
Les vrais savent que ce n’est pas du temps perdu mais de l’investissement à long terme : d’éventuelles régressions pourront être évitées, les mises en production se feront sans douleurs et de manière plus rapides et sereines.
5 bonnes raison de devenir un artisan de la qualité !
1. Nous sommes des auteurs
Programmer / Developper, est l’art de dire à un autre “humain”, ce qu’il veut que l’ordinateur fasse -Donald Knuth
Un auteur de roman, écrit tout le temps. Son travail est bien d’écrire des livres non ?
Hey ! Mais attendez ce n’est pas ce que les développeurs font, écrire du code ? En tout cas une bonne partie de leur temps !
Un livre contient des chapitres, titres et références. Le code contient des namespaces, des classes, des attributs … On peut dire que nous sommes un peu des auteurs, non ?
Cependant, la grande différence entre un livre et du code, c’est que le livre est humainement compréhensible à l’instar des lignes de code. Enfin, cette dernière partie ne tient qu’à nous….
Imaginer l’espace d’une seconde lire un livre tel que Game Of Thrones et que le nom des personnages (et croyez-moi il y en a beaucoup !) soient écrits en abrégé.
La lecture du code doit être comme celle d’un livre. D’autres personne reprenant votre travail doivent pouvoir le comprendre rapidement.
Faites une petite expérience : revenez sur du code créé 2 semaines auparavant. Si vous n’arrivez pas à vous relire et à comprendre ce que font les classes, méthodes et autres attributs, il y a un souci !
Un développeur passe 10 fois plus de temps à lire du code qu’à en écrire, ne l’oubliez pas !
2. Bacle = lent
Bien que suivre les bonnes pratiques de développement, mettre en place des tests unitaires et adopter le craftmanship puisse paraître chronophage au départ, à long terme cela peut en réalité réduire les coûts de maintenance, de réparation de bugs et d’ajout de nouvelles fonctionnalités.
Tous ces points peuvent être plus ou moins regroupés dans un unique point qu’est la dette technique. Bien que beaucoup l’assimilent uniquement à la mise à jour de dépendances techniques ou obsolètes…
Quoi qu’il en soit, bien que les actions menées pour résorber cette dette ne soient pas visibles pour le client ou les responsables à court terme, elles sont pourtant nécessaires. Si cette dette n’est pas suivie et résorbée en temps et en heure, il est probable qu’après quelques mois voire années, vous soyez contraints de passer à la caisse et d’en rembourser les intérêts !
3. Le procrastinateur
Arrêtez de dire : “je mettrai en place la gestion des erreurs dans un second temps”, “je ferai les tests plus tard”, “la refacto attendra”… Arrêtez les TODO poussées sur la branche main et qui sont toujours là 2 ans plus tard !
Bref ! Arrêtez tout, tout de suite. Posez-vous 5 minutes et faites-le. Ça ne sera jamais fait sinon, avouez le ?! N’avez vous vraiment pas le temps ? Trouvez une astuce et forcez vous à le faire, ce n’est pas négociable !
Par exemple, créez une technical story dans votre tableau kanban. Dédiez-y du temps.
N’oubliez pas cette bonne vieille “qualité” ! Repousser à plus tard (entendons-nous bien, à jamais), c’est ignorer les principes même du craftsmanship.
Ne pas s’efforcer d’écrire un code de qualité entraîne une dégradation constante de la qualité du logiciel au fil du temps. Et peut rendre difficile, voire impossible, l’intégration de nouvelles fonctionnalités ou l’adaptation à de nouvelles exigences.
4. Croyez en vous, non à la magie
Combien de fois, j’ai entendu et vous aussi, j’en suis persuadé :
- “Il va falloir un miracle”.
- “On devrait brûler un cierge ou réciter une formule magique, pour qu’il n’y ait pas de bug lors de la mise en prod.”
Lorsque le code n’est pas testé de manière adéquate, difficile d’être certain qu’il fonctionne correctement. Ce qui peut entraîner un manque de confiance dans le logiciel et une hésitation à le déployer en production.
Le manque de tests unitaires et de tests automatisés augmente inévitablement la probabilité des bugs. Ces bugs, parfois mineurs, peuvent passer inaperçus jusqu’à ce qu’ils deviennent des problèmes majeurs dans un environnement de production, entraînant parfois des interruptions de service et les problèmes de réputation qui vont avec.
La grande inquisition et les chasses aux sorcières sont révolues
Respectez-vous ! Respectez vos collègues !
Il est vrai que l’on peut éprouver de la frustration devant un code désordonné et peu fiable laissé par un collègue.
Cela peut même parfois entraîner un taux élevé de turnover, car les développeurs talentueux peuvent se sentir découragés face à un code médiocre.
Avant de lever les bras au ciel ou de charger grossièrement un collègue de l’équipe (surtout quand il est parti en vacances), essayer de comprendre son code !
Le code est sale, désordonné, illisible… ? Qu’à cela ne tienne, améliorez-le ! Rendez-le compréhensible ! Soyez un “boy-scout”.
Une des règles du boy-scout est de laisser un campement encore plus propre qu’à l’arrivée ! Alors évitez de perdre votre temps en chasse aux sorcières inutile, utilisez-le plutôt à rendre le code meilleur.
En résumé
1- La lecture plus compliquée que l’écriture. Ecrivez le code que vous auriez envie de lire.
Il faut savoir qu’un développeur passe 80 % de son temps à lire du code afin de comprendre ce qui a déjà été mis en place. Autant lui faciliter la tâche en écrivant du code clair et compréhensible !
2- Ecriture bâclé = création d’une dette technique
Dites-vous toujours que bâclé = lent. Arrêter d’être quelqu’un de bâclé. Ce n’est pas perdre du temps que de le prendre. Bâcler un travail nous rattrape toujours à un moment ou un autre du fait de l’augmentation du nombre de bugs.
3- Ne remettez pas au lendemain ce qui peut être fait dès aujourd’hui
Il ne faut pas oublier que les 2 qualités récurrentes chez un développeur sont l’impatience et l’orgueil !
4- Évitez de vous tourner vers l’assistance divine ou l’opération du Saint Esprit pour espérer que la mise en production se passe correctement ! Testez. Eprouvez.
5- Ne cédez pas à la chasse aux sorcières.
Soyez professionnels et laissez une bonne impression de vous à vos collègues. Ce n’est pas parce que tout ce travail de fond ne se voit pas qu’il faut le négliger pour autant.
Et n’oubliez pas que votre code vit, même après votre départ 😋
Un grand merci à @Emeline Mangel, Julie Duliere, Grégoire Pouille et Thomas Vasseur, Kylian Brignon pour la relecture 👍👌💪 (Plus on est de fous, plus ont rit.)
