Une tentative de formalisation des modèles de développement JS

En 2015, Alexander Kondov, ingénieur principal chez News UK, a adopté Node.js car il considérait la capacité de JavaScript à s’exécuter à la fois dans le navigateur et sur le serveur comme une fonctionnalité importante qui pourrait permettre à son équipe. Sur la base de son apprentissage, il a créé le Tao of Node, qui “contient des règles et des directives éprouvées pour créer de meilleures applications”.

La permissivité de Node pour réutiliser les bibliothèques, la logique et les types dans les applications front-end et back-end a donné naissance à l’archétype du “développeur full-stack”: un ingénieur suffisamment habile pour travailler sur n’importe quelle partie de l’application dont il a besoin. L’accent mis sur la liberté et la flexibilité, sans imposer de normes de codage ou de structures d’application strictes, l’a amené à un point tel que chaque application de nœud semble suivre une approche différente.

S’appuyant sur son expérience dans la création de diverses applications, il a défini une série de principes pour une expérience améliorée lors de l’écriture d’applications de nœuds.

InfoQ l’a contacté pour en savoir plus sur ces principes.

InfoQ : Bonjour, Alex. Merci d’avoir pris le temps de répondre aux questions de nos lecteurs. Pouvez-vous décrire vos responsabilités et ce qui vous a motivé à écrire le Tao Of Node ?

Kondov: Je suis actuellement ingénieur principal chez News UK, à la tête de deux de nos équipes de facilitateurs qui construisent des bibliothèques, des outils de développement et une infrastructure pour le reste des ingénieurs. Mes responsabilités quotidiennes ne sont pas si différentes de celles de n’importe quel autre développeur, mais je lis et révise plus de code que j’écris.

L’objectif derrière Tao of Node était de formaliser certains des modèles communs que j’ai utilisés avec succès dans ma carrière et de faire gagner du temps aux ingénieurs qui débutent. L’écosystème Node valorise la liberté et le choix, mais il est parfois utile d’avoir un ensemble de principes de départ. Faire de bons mouvements vous place dans de bonnes positions, un peu comme aux échecs.

InfoQ : Bonne lecture, mais longue. Top 5 des plats à emporter pour le lecteur ? Avez-vous l’intention de les rendre exécutoires grâce aux linters ?

Kondov: Tout d’abord, je pense que la structure de l’application est essentielle, donc je conseillerais aux gens de toujours organiser leurs services Node autour de composants et d’entités de domaine plutôt que de responsabilités techniques.

Deuxièmement, colocalisez les fonctionnalités associées et créez des modules imbriqués.

Troisièmement, établissez des couches entre la logique de transport, de domaine et d’accès aux données.

Quatrièmement, pour les performances, assurez-vous de ne pas bloquer la boucle d’événements avec des opérations intensives et vous résoudrez la plupart de vos soucis de vitesse.

Enfin, ne vous inquiétez pas des changements de base de données en ce qui concerne les abstractions – si jamais vous avez besoin de changer le stockage d’une application en production, les données qu’elle contient devraient être votre plus grande préoccupation.

Même si j’envisageais de créer un plugin ESlint, au final, j’ai préféré les garder comme lignes directrices. De cette façon, je ne limite pas la créativité des gens, car de nombreuses règles dépendent du contexte.

InfoQ : Comment recommanderiez-vous de mettre la théorie en pratique ? Comment l’implémenter sur des projets existants ?

Kondov: pièce par pièce. Commençant par améliorer la structure, cela implique le moins de refactoring. La réorganisation de la base de code nécessite principalement des changements de chemin d’importation. Avec une meilleure structure, vous pouvez aborder chaque module à la fois, en séparant les couches et en divisant la logique. Comme pour une étagère en désordre, tout doit sortir avant que vous puissiez le réorganiser.

Un effet secondaire possible de la refactorisation pourrait être la diminution de la qualité du code. Une fois le gâchis réglé, vous disposerez d’une application plus organisée et plus productive avec laquelle travailler.

InfoQ : Quelle serait votre plus grande préoccupation lorsque vous examinez l’écosystème JS ? De quoi auriez-vous besoin ?

Kondov: Node.js est un outil puissant que j’utiliserais pour toute application qui ne nécessite pas de calculs lourds ou de manipulation de grandes structures de données. Il brille particulièrement lorsqu’il s’agit d’E/S à volume élevé, mais il peut facilement s’essouffler s’il est utilisé pour un problème qu’il ne peut pas résoudre. Sa communauté est assez ingénieuse, mais elle a certainement besoin d’une normalisation, en particulier pour l’outillage.

Beaucoup de nouvelles fonctionnalités ont été ajoutées à JavaScript récemment. Ce n’est pas mauvais en soi, mais gonfler la bibliothèque standard n’est pas la bonne façon de le faire. Le besoin de compatibilité descendante se traduit par un langage qui ne cesse de croître. La prise en charge de JS pour les paradigmes fonctionnels et orientés objet le rend attrayant pour les ingénieurs, mais il peut être très déroutant pour les nouveaux arrivants.

Tao of Node est ma tentative de formaliser certains des modèles de développement, mais la communauté JS, en général, peut bénéficier d’un seul outil qui gère la chaîne d’outils – TypeScript, testing, linters, etc.

Sept ans après la version 1.0.00 de node, Alexander Kondov a célébré cet anniversaire en publiant The Tao Of Node, un ensemble de principes avisés qui devrait créer une approche uniforme pour le développement d’applications backend en JavaScript.

Entre-temps, le langage autrefois réservé aux navigateurs a gagné en popularité et a reçu la médaille d’argent du rapport sur l’état du serveur sans serveur de DataDog, tandis que les statistiques linguistiques de GitHub le désignent comme l’un des principaux langages utilisés au premier trimestre 2022. .

Conformément à sa popularité, la responsabilité de JavaScript s’est également accrue, The Tao Of Node tentant de normaliser les différentes approches que la flexibilité de node permettait d’apparaître.

.

Leave a Comment