Étant donné que la demande en logiciels Web augmente constamment et que des tâches plus critiques sont confiées à JavaScript, appliquons les directives de codage de la NASA aux applications JavaScript / HTML pour des performances, une fiabilité et un monde meilleur.

Ses règles ont été écrite par les ingénieur de la NASA pour des raisons d'efficacité et de bonne écriture de code JavaScript. Ce afin de coder plus safement les plateformes Web

Cela ne signifie généralement pas plus de 60 lignes de code par fonction et cette règle convient parfaitement pour le JavaScript. Le code décomposé permet de mieux comprendre, vérifier et maintenir.

Ne pas utilisez d'instructions goto ni de récursion directe ou indirecte, La règle venant du C fait merveille. Nous n'utiliserons certainement pas goto ou setjmp dans JS, mais q le problème avec la récursivité est que les analyseurs de code statiques utilisés par la NASA réduisent les risques d’erreur. Les récursions rendent le code moins prévisible pour eux.

• Utilisez des constructions qui sont justifiées par la complexité .Si vous voulez écrire du code fiable - déposez-en pour en écrire un qui soit cool et qui prévisible à la fois.
• Définir le standard de codage et le suivre
• Utilisez l'analyse statique pour prendre en charge la norme et réduire les risques de défaillance : ESLint + Beaucoup de plugins, Preset
• Collecter des matrices : SonaQube, Scrutinizer , Plato
• Analyser les types : Flow / Google Closure Tools / Types

GC pourrait devenir votre ennemi

DevTools / Timeline

DevTools / Profile / Takeheap snapshot

• Gérez votre variable avec respect. Déclarez en haut de la portée pour augmenter la visibilité. ESLint vars-on-top. Trier pour la prévisibilité sort-vars
• Surveillez les liens mémoire, nettoyez les écouteurs et les variables lorsque vous n'en avez plus besoin .
• ESLint no-unused-vars
• Basculer JavaScript en mode d'allocation de mémoire statique via le regroupement d'objets.

L'analyse statique est plus efficace et permet d'éviter les boucles infinies. Si la limite est dépassée, la fonction retourne une erreur et prend le système en état d'échec. Pour la peine pas de nouveaux objets au moment de l'exécution et toutes les boucles doivent avoir une limite supérieure fixe.

   const pool = createObjectPool(256);
   let object = pool.getObject();
   pool.releaseObject(object);

La densité des assertions du code doit être en moyenne d'au moins deux assertions par fonction . Le plus simple pour cette approche est la mise en place des tests unitaires qui s'exécutent au moment de l'exécution.

• Plus la densité de test est élevée, moins vous obtenez de défauts
• La quantité minimale de test est 2 par fonctions .
• Surveillez les anomalies dans l'état du système pendant l'exécution. Générer et gérer des erreurs en cas de pannes critiques.
• Mesurer la couverture, mais attention, une couverture à 100% ne signifie pas nécessairement que vous avez un code bien testé.

L'intention derrière cette règle est simple: conserver les données dans le champ privé et éviter les accès non autorisés. Cela semble générique, intelligent et facile à suivre.

La valeur de retour de la fonction non vide doit être vérifiée par chaque fonction appelante et la validité des paramètres doit être vérifiée à l'intérieur de chaque fonction.

JavaScript est transpilé par chaque navigateur, nous devons donc surveiller les performances de notre code .Gardons à l'esprit que le code que vous écrivez n'est pas le code que vous exécutez !

Bon à savoir lorsque vous utilisez les performances des transpileurs des fonctionnalités de l’ES6 par rapport à celles de l’ES5.

L'utilisation de pointeurs doit être spécifiquement restreinte. Un seul niveau de déréférencement est autorisé . Les pointeurs sur les fonctions ne sont pas autorisés . Tout en sachant que JavaScript fonctionne de base avec les pointeurs. C’est la règle ou les développeurs JavaScript ne peuvent rien obtenir 😅

• Chaînes d'appel ( Niveau de référence )
• LoD = Loose Compling

  Dog.body.legs.run();
        vs
  Dog.run();

Tout le code doit être compilé le premier jour de développement, avec tous les avertissements du compilateur activés. Ne stockez pas les avertissements, ne remettez pas à plus tard les correctifs, gardez le code propre et perfectionniste en vous.

Si le code est au rouge 🔥⚠️

• Ne panique pas 🧘🏿‍♂️
• Simplement, prioriser
• Refactoriser et ajouter des tests pièce par pièce 🎨

En regardant la conférence je me suis rendu compte du niveau existant de l'automatisation, de la testabilité et d’infrastructure de projets et de code, la quantité de meilleures pratiques établies tirée de langages matures et la masse de connaissances que nous avons déjà sur le développement Web sont étonnantes. Mais quand même… C'est un long chemin à parcourir pour nous et beaucoup de défis à relever.