JavaScript est le langage qui a le vent en poupe depuis plusieurs années. Avec un même language, on peut aussi bien produire des solutions appelées « backend » (en Node.js) comme des interfaces « frontend » (React, Angular, Vue.js). Le JavaScript est particulièrement apprécié par certains développeurs pour sa souplesse. Mais cet avantage devient une limite quand on souhaite un code de qualité. Comment s’assurer que le code JS (JavaScript) écrit sur les projets de ses équipes est de qualité ?
Les outils automatisés de formatage de code
Au premier chef des solutions pour améliorer la qualité d’un code (lisibilité, respect de standard d’écriture, etc.) il faut mentionner les outils automatiques, bien sûr. Il en existe de nombreux, et dans tous les langages. Dans l’univers JavaScript, les plus connus et utilisés sont sans doute ESLint, JSLint et JSHint.
Ces outils proposent de nombreuses options qui permettront à chaque projet d’atteindre le niveau de qualité souhaité, en fonction de sa maturité. Maintenant que votre code est correct et lisible, c’est le moment de vérifier sa sécurité.
La sécurité du code de votre projet
Si les outils précédents améliorent la lisibilité et la validité du code, la sécurité devra être analysée indépendamment. Citons deux outils : « npm audit » et Helmet. Le premier vérifie que les librairies tierces dont dépend votre projet utilisent des versions sans faille de sécurité détectée. Le second, Helmet, vous aidera quant à lui à protéger votre application des attaques HTTP les plus répandues sur le web.
Rappel : HTTP est le protocole faisant communiquer votre navigateur avec un serveur ou une application avec un serveur.
Le code passé aux cribles des scripts automatiques, rien de tel qu’une inspection par un expert : la revue de code.
La revue de code par un architecte logiciel
Une relecture humaine reste encore aujourd’hui incontournable et complémentaire aux outils cités ci-dessus. La revue de code (« Code review » dans la langue de Shakespeare) permettra de détecter des erreurs métier, d’identifier du code à commenter ou bien des noms de fonction à rendre plus explicites.
À travers ces 3 illustrations, nous venons de voir qu’il est simple et accessible (pour une équipe de développement) d’améliorer grandement la qualité du code produit. On pense souvent, et les équipes de développement les premières, que c’est une contrainte qui va ralentir et coûter plus cher. C’est vrai au début. Mais un projet est fait pour durer et mieux un projet est écrit, moins il coûtera à maintenir !