shop-cart

Vous lisez actuellement: Bon code : dix règles pour forger un code de qualité

Bon code : dix règles pour forger un code de qualité

Vous le savez sûrement, il y a beaucoup de raisons techniques d’avoir honte de votre code. Je vous livre ici dix règles importantes qui permettent de forger un bon code, si elles sont appliquées.

Peu importe le language ou la stack tech que vous utilisez, si vous pouvez décrire votre code avec ces adjectifs, vous pouvez déjà être content. Si ce n’est pas le cas, vous aurez alors quelques clés pour réfléchir 😉

Débogable

La plupart des environnements modernes vous permettent d’obtenir un mode debug. Pour preuve, même Node.js peut être débogué avec Visual Studio. Vous devriez toujours écrire votre code avec un débogueur activé, pour comprendre ce qu’il se passe à la moindre ligne.

Il est souvent compliqué de comprendre toutes les implications d’un code source, surtout quand il n’est pas écrit uniquement par vous, mais par votre équipe. Avec des points d’arrêt, vous allez gagner un temps fou à comprendre et à travailler.

Pour bien commencer, utilisez un débogueur quand vous n’en avez pas besoin. Allez y étape par étape. Vous allez vite vous rendre compte de la puissance de cet outil et surtout savoir si votre code est écrit pour être débugé.

Journalisé

Même si vous disposez d’un débogueur que vous pouvez associer à votre envrionnement de dev, ce n’est pas suffisant. Votre code peut s’exécuter ailleurs qu’en local, il peut être serverless, il peut être multithread ou distribué, ou il peut fonctionner sur un cloud quelque part. Dans ces environnements, il peut ne pas se comporter de la même manière que chez vous.

Donc, vous allez avoir besoin d’un système de log. Et cela signifie que vous avez besoin de définir un cadre de journalisation. Vous devez écrire le code et configurer la journalisation d’une manière qui rende le journal de log lisible ou au moins digeste, avec une façon simple pour consulter ce journal. Vous devez intégrer cette partie à votre logiciel.

Si vous ne le faites pas, vous serez un jour confrontés à des problèmes en production qui devriendrons un cauchemar à résoudre.

Testé et testable

Ok, là il y a deux mots, mais en fait, ils vont ensemble !

Ecrivez des tests unitaires ! Ce doit être est une ligne rouge à ne pas franchir, ne pas tester automatiquement un code est très dangereux. Ne postuler à aucune entreprise qui vous dirait que “tester un logiciel est une perte de rentabilité”, c’est une idée reçue, stupide et sans fondement.

Un bon code testable est décomposée en petites fonctions simples qui font de petites choses vérifiables simplement. Les logiciels testables fonctionnent mieux et sont plus résistants dans le temps. Ils sont améliorables avec sérénité.

Si vous avez un code existant qui ne dispose pas de test, écrivez des tests lorsque vous modifiez ce code et faites en un bon code. Mais écrivez-les avant si vous le pouvez ! Si vous devez restructurer quelque chose pour le rendre testable, faites-le, petit à petit, mais faites-le !

Terminable

C’est une règle assez simple, et pourtant, elle change pas mal de chose. Posez vous une question : “quand est-ce que ma fonction doit terminer”.

Souvent, elle peut (et donc doit) terminer si il n’a pas les bonnes données, ou le bon objet déjà embarqué dans la classe. Et si le code doit s’arrêter pour x ou y raison, vous devez sortir le plus vite possible. Vous pouvez aussi ajouter un message d’erreur, qui indiquera à un autre développeur le pourquoi du comment.

Pour les, souvent trop utilisés, comportements en if/else, essayez de trouver comment supprimer le else. Car bien souvent, ce que vous faites dans le if, terminera de lui même l’execution de la fonction. Avez-vous vraiment besoin du else dans ce cas là ? ou un petit return suffirait-il dans le if ? Simplifiez ce qui est possible pour obtenir un bon code.

Immuable

Si vous ne connaissez pas cette technique, je vous renvoi au très bon article Wikipedia sur les objets immuables.

Pour faire simple, on peut dire qu’une classe immuable est une classe dont les objets, une fois instanciés, ne peuvent plus changer d’état.

L’immuabilité à de nombreux avantages, dans des environnements où la mémoire est gérée de manière automatique. Elle permet souvent à une application de pouvoir souffler et de ne pas avoir à stocker la terre entière avec des duplications complètes de données.

Cette règle là, qui n’est pas une obligation en soit, vous permettra cependant de rendre une partie du code non-modifiable, et de vous prémunir d’effets de bords indésirables.

Lisible

Quand la programmation fonctionnelle est devenue à la mode, les développeurs ont eut tendance à l’oublier, mais un code doit être lisible. Et ce fût la même chose avec le code orienté objet.

On pense souvent à tort qu’un code qui s’execute est un bon code. Mais souvenez-vous toujours que votre travail en tant que développeur consiste à écrire du code qu’une autre personne peut lire. Et cette autre personne pourrait ne pas être développeur et s’y retrouver.

N’ayez pas peur de faire des noms de variables / de fonctions / de classe à rallonge, tant qu’on y comprend quelque chose et qu’il est simple de naviguer dans les appels. Vous devriez presque pouvoir l’exécuter vous même, en le lisant.

Gardez aussi en tête qu’il existe maintenant, pour n’importe quel langage, des standards de code, que vous trouverez sur internet et qui vous expliquent comment coder proprement et en respectant des règles.

Modifiable

Il n’y a pas longtemps, je voulais faire une modification super-simple dans un bout de code : récupérer le nom d’utilisateur de la session. En raison de la façon dont ce code était écrit, ça m’a prit un temps incroyable pour le faire. En d’autres termes, le code n’était vraiment modifiable que par celui qui l’avait écrit. Quel que soit la façon dont il s’y est pris, le code n’était ni documenté, ni lisible.

Chaque classe, module, fonction, etc. doit être écrit avec l’idée que les choses peuvent changer. Vous pouvez avoir besoin d’un élément de données supplémentaire à n’importe quelle moment de la vie de l’application. Il y a presque toujours une version 2 de n’importe quoi, alors écrivez du bon code avec l’idée que cela arrivera un jour ou l’autre.

Documenté

Un bon code devrait simplement être auto-documenté. Les classes, les fonctions et les variables, bien écrites, sont auto-documentées. Mais ajouter un peu de documentation en JsDoc (ou l’équivalent de votre language), ça ne mange pas de pain.

C’est aussi une question de conception de votre code.

Si vous ne pouvez pas documenter “cette partie de code” et “ce qu’elle fait” sans faire référence à dix autres choses, peut-être que vous devriez repenser votre conception.

Modularisé

Le bon code est divisé en parties logiques que vous pouvez exécuter et modifier indépendamment. Donc, si vous trouvez que vous avez trop de logique à un endroit, ou que vous pourriez sûrement utiliser un bout de code à deux endroits différents, faites des services, pensez modularité.

Vous y gagnerez beaucoup. Ne serait-ce que pour tester un bout de code de façon unitaire. La modularité, ça va de paire avec la testabilité.

Constructible

Si d’autres développeurs ne peuvent pas simplement récupérer votre code depuis Git et lancer le build, vous avez loupé un truc. Si cela nécessite un processus d’une semaine, plusieurs jours ou plusieurs heures, alors votre build a besoin d’être travaillé.

Une application doit être opérationnelle sur un nouveau poste de travail en moins de trente minutes et votre phase de build vous servira dans de nombreux cas, lors d’une mise à jour, d’une remise à zero et même pour un déploiement en prod.

A story about

, ,

,

Avec

797

Vues


Écrit par

Julien Moulin

Julien est le lead-developer / CTO de blueanchor. Développeur fullstack, il évolue d’abord dans le monde Php/Symfony (chez SensioLabs), puis s’oriente vers Javascript pour performer en Angular. Formateur chez Linkedin learning, il met à profit son savoir auprès des utilisateurs de tout bord, en tentant de faire découvrir le monde du web au plus grand nombre.


Afficher la conversation (0)

Recommander cette page

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

0 People Replies to “Bon code : dix règles pour forger un code de qualité”