Best practice dans le développement JS

a marqué ce sujet comme résolu.

Bonjour à tous,

Depuis quelques temps, je m’écarte un peu du développement Android pour du développement Javascript. Je crée ce sujet pour connaitre un peu les bonnes pratiques dans ce monde que je connais assez mal.

D’après ce que j’observe sur le net, mon projet semble un peu particulier, j’ai 2 dossiers : l’un nommé packages qui contient une liste de modules qui vont avoir des dépendances entre eux et qui vont exposés du code commun ; l’autre est nommé apis, il contient plusieurs dossiers qui contiennent le code source de mes APIs HTTP que je veux exposer via mon serveur.

Maintenant que le contexte est expliqué, voici mes questions…

  1. Pour mon code commun dans mes packages, je crée des classes qui dépendent d’autres classes via leurs constructeurs. Cela me permet donc de mocker des dépendances dans mes tests. Est-ce que cette pratique vous choque dans l’esprit JS ?

  2. Dans certains modules, je me retrouve avec de plus en plus de classe et ça devient difficile à maintenir et à contenir dans un seul fichier. J’ai donc créé plusieurs fichiers qui exposent les classes et un fichier index.js qui exposent les classes exposées dans les fichiers du module. Est-ce que cette pratique vous choque ?

    Voici un exemple d’un de mes fichiers index.js :

    let ex = {};
    ex = Object.assign(require('./repositories'), ex);
    ex = Object.assign(require('./networkDataSource'), ex);
    ex = Object.assign(require('./daoDataSource'), ex);
    module.exports = ex;
    
  3. Pour mes tests, est-ce que vous préconisez un seul fichier index.test.js qui va tout tester ou je suis mon découpage en fichier de mon module ?

  4. Quelque chose qui me m’embête beaucoup parce que je viens d’un langage fortement typé, c’est la possibilité de mettre tout et n’importe quoi comme dépendance dans mes constructeurs de mes classes. Est-ce que ça vous choque si test le type de mes paramètres pour renvoyer une exception si c’est pas du bon type ?

Voilà, merci beaucoup à tous pour vos réponses à mes questions… :)

Navré, ça a l’air d’être une question orientée back-end, du coup je ne peux pas trop répondre sur les autres points.

Quelque chose qui me m’embête beaucoup parce que je viens d’un langage fortement typé, c’est la possibilité de mettre tout et n’importe quoi comme dépendance dans mes constructeurs de mes classes. Est-ce que ça vous choque si test le type de mes paramètres pour renvoyer une exception si c’est pas du bon type ?

Bah ça me choque un peu ouais :\

Si vraiment t’as besoin de fonctionnalités de ce genre (checker des types) alors ne vaudrait-il pas mieux se tourner vers un autre langage qui propose ce genre de fonctionnalités (limite si tu es complètement forcé d’utiliser du JS, une alternative genre TS ?).

Déjà, le coup des classes et des constructeurs, je suis pas un immense fan en Javascript, je préfère largement l’approche "tout est fonction", j’ai l’impression que ça produit du code plus compréhensible en JS, même si ça a l’air plus "first-class citizen" avec les dernières versions d’ECMAScript, ça reste toujours de l’héritage par prototype, et autant quand c’était explicitement le cas, on s’en sortait, avec le sucre des class ça peut parfois sembler être ce que ça n’est pas.

C’est pas du troll contre JS hein, pas du tout. Mais là j’ai l’impression que tu fais rentrer des ronds dans des carrés. daoDataSource ça sent le Java + Dependency Injection à plein nez, c’est pas un truc que je tenterais en JS.

Soit je changerais complètement de paradigme, soit de langage / framework. Tu peux ? Mais là en voyant les questions / exemples, j’agiterais le drapeau du "code smell".

Je laisse ici la réflexion (histoire de pas complètement faire dérailler ton thread), ma boîte à MP est dispo si besoin. Et du coup je laisse des experts du JS-backend répondre à tes questions proprement dit.

+1 -0

Tu as assez bien compris ce qui me gêne dans mes développements.

Quand j’ai commencé à développer le projet, j’étais parti sur du développement sans aucune classe, que des fonctions. Puis quand j’ai vu qu’il existait des classes en JS, je dois dire que je ne me suis pas privé. Je trouvais ça très rapidement brouillon avec que des fonctions.

class n’est que du sucre syntaxique comme tu le dis, mais mon projet va être développé et maintenu par une équipe de développeur assez conséquente avec un background JVM only. J’ai pris un peu peur sur ce qu’aurait pu devenir le projet…

J’ai donc effectivement une approche Java + Dependency Injection mais est-il possible de tester facilement des portions de mon code sans cette approche ? Par exemple, les classes dans mes dao ont une dépendance forte avec une bibliothèque qui ne peut pas s’exécuter en local (ou plutôt difficilement). Ca me permet donc de mocker cette partie mais s’il existe une solution plus dans l’esprit JS, je suis carrément preneur.

Pour la vérification de mes types, je comprends que ça choque. Moi-même ça me dérange de le faire avec un langage faiblement typé. J’ai finalement retiré ces vérifications qui n’apportaient pas grand-chose.

Pour le TypeScript, j’avoue que ça me plairait bien d’étudier la faisabilité. Je vais me pencher dessus pour voir ce que ça pourrait donner.

Merci de ta réponse et peace, je suis vraiment pas ici pour troller.

/me agite le drapeau blanc si des gens ont peur de s’exprimer à cause de ça

Edit : Pour info, j’ai aussi modifié mes fichiers index.js

module.exports = Object.assign({},
  require('./usecases'),
  require('./repositories'),
  require('./networkDataSource'),
  require('./daoDataSource')
)

Déjà je switch sur qu’une seule ligne, puis j’ai cru comprendre que c’était une bonne pratique d’avoir un fichier index.js le plus simple, petit et clair possible, juste là pour exposer les membres, fonctions, classes du module.

+0 -0

développé et maintenu par une équipe de développeur assez conséquente avec un background JVM only

Et du coup t’as pas de possibilité d’utiliser une stack plus JVM-friendly ? A la rigueur on peut en discuter en MP, et laisser cette discussion ouverte pour tes (vrais) problèmes de JS :)

EDIT : au pire ça peut te donner plusieurs cordes à ton arc

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte