Comment les grandes applications JavaScript sont-elles censées être structurées?

On m'a récemment montré des plugins JavaScript écrits pour OBIEE Mobile App Developer, ainsi que des bibliothèques personnalisées pour divers projets.

Issu d'un parcours OOP, je suis un peu confus quant à la structure de ces projets. Je vois des fichiers de milliers de lignes. Je suis habitué à diviser les choses en fichiers et en classes, mais je comprends que c'est un cadre différent - d'une part, la taille des fichiers est un problème - mais il doit y avoir une meilleure façon de tout faire?

La longueur des scripts affecte non seulement la lisibilité et la maintenabilité, mais aussi la compréhension générale d'une personne sur le fonctionnement du programme.

Comment les grandes applications sont-elles structurées? Y a-t-il des modèles de conception OOP généraux pour cela?

Si vous n'êtes pas familier avec les modèles JavaScript, je peux vous dire que de nombreuses applications et bibliothèques volumineuses utilisent le modèle de module révélateur , mais il existe de nombreux autres modèles que vous pouvez utiliser en fonction de vos besoins.

Le modèle de module révélateur devrait cependant vous donner un bon moyen de diviser des fichiers volumineux et de les organiser logiquement; Cependant, lorsque vous travaillez avec des modèles de conception en JavaScript, sachez que cela peut devenir très déroutant. Essayez d'utiliser ce , nouveau , prototype , .call()et à .apply()bon escient.

Tout en travaillant sur de grands projets, ceux-ci peuvent également être utiles:

• Si possible, passez à TypeScript ou ES6.
• Écrire du code modulaire . Il existe différentes manières et des bibliothèques tierces, mais chacune d'entre elles vaut mieux que rien.
• Utilisez un Task Runner / Build System pour automatiser les tâches.
• En savoir plus sur les modèles de conception . Cela pourrait être un bon début. Comme je l'ai dit ci-dessus, le modèle de module révélateur est très utile, surtout si vous pensez que vous avez besoin de temps pour maîtriser tous les modèles populaires.
• Écrire des tests unitaires . Travailler avec un langage dynamique peut être plus difficile. Tester les parties cruciales de votre application peut vous faire gagner beaucoup de temps.
• Utilisez un IDE ou un éditeur de texte qui peut réellement vous aider à écrire du code et à détecter des bogues. WebStorm est un bon choix. Sublime Text aussi.
• Si votre IDE n'offre pas de débogueur, essayez de maîtriser le débogueur de votre navigateur Web préféré.
• Utilisez des bibliothèques. Selon la nature du projet, essayez d'utiliser le meilleur code tiers que vous pouvez trouver. Si vous écrivez une application Web, jetez un œil à Angular , React et le bon vieux backbone.js . Si vous écrivez une application Node.js, prenez votre temps pour rechercher dans le référentiel NPM . Vous serez surpris du nombre de packs qui font déjà ce que vous étiez sur le point de faire.
• Même si vous êtes la seule personne qui travaille sur le projet, utilisez toujours un système de contrôle de version comme Git et suivez une norme de codage qui n'est pas trop stricte et qui ne donne pas d'opinion mais qui fournit toujours une bonne ligne directrice que vos coéquipiers seraient également heureux de suivre.
• Même si vous optez pour TypeScript ou ES6, tout en comprenant la POO sans classe de JavaScript, la POO prototypique peut être utile, en particulier lors du débogage.

Je suis développeur C ++ et j'ai commencé récemment à faire du développement web. Je porte une grande application de bureau sur l'environnement Web. Je structure mon code JavaScript exactement comme j'ai structuré du code C ++, en utilisant les mêmes modèles. J'ai environ 25 à 30 fichiers en tout, mais je vais éventuellement les réduire à 3 à 5 en les matraquant comme il convient et les réduire tous.

Pour moi, c'est juste la langue qui a changé, pour le meilleur ou pour le pire, mais pas le paradigme. JavaScript, malgré tous ses défauts et frustrations, est un joli mélange de style fonctionnel et OOP. Jusqu'à présent, les choses ont bien fonctionné.

Enfin, une chose que j'ai réalisé très tôt était que JavaScript permet d'écrire un code beaucoup plus concis que C ++, donc parfois avoir un grand nombre de LOC provenant d'un langage non JS pourrait être dû au fait de s'en tenir à l'ancienne façon de faire. Une fois cette question résolue, je ne vois rien qui devrait vraiment être différent. La conception et les algorithmes sont après tout indépendants du langage.

Cela varie largement d'un projet à l'autre, bien sûr, mais la pratique généralement acceptée est que, pour les choses qui sont destinées à fonctionner comme des bibliothèques ou des modules, à les placer dans un seul grand fichier et à utiliser l'encapsulation pour empêcher son interne ("privé"). ) interface de fuite vers l'extérieur. Il est également utile pour les développeurs souhaitant utiliser la bibliothèque / le module - un fichier à ajouter à la configuration de l'application ou un extrait d'en-tête au lieu de toute une hiérarchie de dossiers et de fichiers à copier et coller. Cela reflète également le fait que, avec la minimisation et le regroupement, dans un site de production, ils seraient très probablement tous combinés en un seul fichier pour réduire le nombre de requêtes HTTP.

Votre propre code d'application n'a pas besoin de suivre cette pratique, et il ne devrait probablement pas l'être. Étant donné que votre application est la seule à l'utiliser, vous n'avez qu'à ajouter les fichiers une seule fois et vous pouvez probablement compter sur la plate-forme pour gérer la minimisation et le regroupement pour vous.

Lorsque vous travaillez sur le code, les différents composants sont généralement divisés en modules, chacun implémentant généralement une seule classe et chacun vivant dans un fichier distinct. Pendant la production, ces fichiers sont ensuite regroupés dans un seul fichier (d'où les milliers de lignes de code que vous voyez) en utilisant quelque chose comme Browserify ( http://browserify.org/ ) ou RequireJS pour réduire le nombre de requêtes HTTP, mais aussi pour s'assurer que les dépendances sont chargées dans le bon ordre

En ce qui concerne la façon dont les classes de ces modules sont implémentées, c'est un peu différent de la POO dans la mécanique sous-jacente, mais pas si différent en surface. ES6 a même introduit le classmot - clé, il devrait donc sembler assez familier. Cet article sur MDN est utile pour commencer: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

J'utilise (Petri's Net Elements and Annotations) pour organiser ou «structurer» un logiciel pour mes applications de formulaire PDF - des programmes JavaScript qui utilisent l'API Acrobat / JavaScript. Peut-être que cela peut être utile dans votre situation.

Un diagramme est utilisé pour établir les relations d'entrée-sortie des éléments nets et deux vues de forme des annotations. Sur la base du diagramme et des vues de formulaire, il est possible de créer systématiquement des programmes JavaScript pour les applications de formulaire PDF. Ainsi, la «lecture» du code source se réduit à vérifier qu'il correspond aux spécifications: le diagramme et deux vues de formulaire.

L'implémentation de mon logiciel utilise des constructeurs et des prototypes. Si les performances deviennent un problème, le remplacement des prototypes par des membres d'instance peut améliorer les performances au détriment d'une utilisation accrue de la mémoire. Des tableaux sont également utilisés. Si les performances deviennent un problème, des références directes sont utilisées.

Certaines propriétés sont créées à l'aide d'eval; pour les objets avec de très nombreuses propriétés, cela réduirait la quantité de code dans le fichier source - et réduirait la quantité de saisie par le programmeur.

Il est toujours possible et recommandé d'écrire JavaScript de la manière OOP à laquelle vous êtes habitué. Voici un bon livre qui passe en revue les modèles de conception les plus importants de JavaScript.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

Il existe également de nombreux frameworks JavaScript où l'objectif principal est de pouvoir diviser le code en différents fichiers et modules. Si le cadre particulier dans lequel vous travaillez vous oblige à avoir tout votre code dans un seul fichier, vous devriez certainement chercher à changer.