JavaScript est un langage de script orienté objet principalement utilisé dans les pages dynamiques et interactives mais également, et cela de plus en plus, il est utilisé côté serveur. Comme pour tout autre langage, pour écrire un code qui exploite au mieux ses capacités, il est nécessaire de respecter certaines règles et de bonnes pratiques selon Cory House, expert développeur et Microsoft MVP.Règle n°1 : Écrire du JavaScript dans un fichier séparé
On pourrait être tenté de coder en dur ses scripts JS car ceux-ci sont généralement constitués seulement de quelques lignes de codes. Cependant le fait de les écrire dans des fichiers à part a l'avantage de permettre une meilleure lisibilité et une bonne structuration de son code. Contrairement aux scripts codés en dur, les fichiers JS sont stockés dans la mémoire cache évitant ainsi des aller-retour au serveur qui peuvent s'avérer coûteux en bande passante.
Règle n°2 : Le code Javascript doit être "statique"
Certains développeurs utilisent des langages comme C#, Ruby ou encore Java pour générer coté serveur du code JS dynamique. Cela est à éviter ne serait-ce que pour bénéficier de la coloration syntaxique dans son éditeur. Il faudrait plutôt utiliser JSON pour donner un comportement dynamique à son application sans pour autant que le code JS change en soit. Ce mécanisme est utilisé notamment par Stackoverflow comme vous pouvez le voir sur cette portion de code source dans laquelle des paramètres personnels comme isNoticesTabEnabled sont injectés. Ce faisant, JSON fournit les données nécessaires pour un rendu dynamique coté client en gardant son code "statique".
Règle n°3 : Le code Javascript doit être minimaliste
Le code JS doit être le plus minimaliste possible. Cela permet de faciliter le chargement des fichiers .js allégeant ainsi le serveur. Cela nous fait gagner en performance qui, rappelons le, est un critère de qualité d'une application. Il existe plusieurs manières de réduire la taille des fichiers .js, l'une d'entre elle est l'utilisation de task runners tels que Gulp.
Règle n°4 : Inclure le Javascript en bas de page
Le fait d'inclure la balise <script> dans le tag <head>de la page bloque le chargement de celle-ci. En effet le contenu du <head> doit obligatoirement être chargé avant que le contenu du <body> puisse être affiché. Pour éviter cela, il est donc préférable d'inclure les .js en fin de page juste après le tag </body>pour ne pas être obligé d'attendre le chargement des scripts avant de pouvoir afficher le reste de la page.
Règle n°5 : Écrire des fonctions de test automatique pour tester son code
Javascript est de plus en plus utilisé côté serveur avec beaucoup de logique métier derrière. Dès lors, vouloir tester son code JS manuellement devient presque un casse-tête. Il devient donc impératif d'automatiser les tests. Il existe une variété d'outils d'automatisation de test. Pour les tests unitaire par exemple, Jasmine est un assez bon choix quand on est débute dans le test Javascript mais pour des gens expérimentés dans le domaine, Mocha avec Chai est un meilleur choix.
Règle n°6 : Utiliser le pattern Module pour encapsuler son code Javascript
L'utilisation du pattern Module est pressenti par certains développeurs comme étant l'avenir de l'encapsulation de code JS. Même s'il n'est pas encore pris en charge par les navigateur, on peut aujourd'hui utiliser Module ES6 pour "transpiler" via Babel. Pour ceux qui n'utilisent pas ce mécanisme, CommonJS est un bon choix pour le moment.
Règle n°7 : Les dépendances Javascript doivent être explicites
Cette règle est étroitement liée à la règle précédente. Une fois que vous avez commencé à encapsuler votre code JS, vous avez besoin d'un moyen facile de faire référence à d'autres modules. C'est à ce niveau que des modules modernes comme CommonJS et ES6 nous facilitent la vie. Cela se fait simplement en spécifiant vos dépendances au début du fichier, un peu comme une importation ou une déclaration en utilisant Java ou C#.
Règle n°8 : Utiliser des framework et des bibliothèques
Il existe une panoplie de framework Javascript dans le monde du développement logiciel. Le choix est large, de Backbone à Angular en passant par Backbone ou encore Ember. Ce qu'il ne faut éviter à c'est d'essayer de partir de zéro, il faut toujours partir d'un base solide avec un de ces frameworks et selon les besoins et les préférences on pourra juger nécessaire d'en adopter un autre ou de continuer avec le premier.
Règle n°9 : Séparer la présentation de la logique métier et de l'accès aux données
A ce niveau il ne s'agit pas simplement de faire une séparation en modèle, vue, contrôleur comme c'est le cas avec les framework MVC tels qu' Angular ou encore Knockout. Il s'agit plutôt de raisonner comme un développeur côté serveur en séparant votre présentation de la logique métier ainsi que de l'accès aux données. Pour ce faire, les appels AJAX doivent tous être à un seul endroit et vous devez créer une couche d'accès aux données centralisée côté client. Cela implique également que toute logique ne faisant pas partie de la couche présentation doit résider dans des classes POJO (Plain Old Javascript Object). Les modules contenant la logique métier doit ne doit contenir que du code Javascript simple, c'est à dire qu'il ne faut pas utiliser de code spécifique à un framework à ce niveau.
Règle n°10 : S'assurer que son site continue de tourner sans Javascript
Javascript permet de rendre les sites plus agréables du points de vue de leurs contenu. Cependant il ne doit pas être indispensable à un site pour être opérationnel. Cela peut être une assez mauvaise chose pour l'accessibilité du site.
Règle n°11 : Initialiser les variables au début du script
Initialiser les variable au début du script permet :
- de rendre le code plus lisible
- de regrouper les déclarations de variable à un seul niveau
- d'éviter d'avoir des variables non initialisées
Règle n°12 : Éviter l'utilisation de la fonction eval()
La fonction eval() est utilisée pour exécuter du texte comme du code mais dans presque tous les cas son utilisation n'est pas obligatoire. C'est une fonction qui permet d'exécuter du code arbitraire ce qui peut présenter un problème de sécurité dans bien des cas.
Sources : Blog, W3Schools, Github
Et vous ?
Quel est votre point de vue ? 
Envoyé par Sodium
.
.
