Utilisation de packages (gemmes, œufs, etc.) pour créer des architectures découplées


10

Le principal problème

En voyant les plates - formes bon support de programmation les plus modernes ont pour la gestion des paquets (pensez gem, npm, pip, etc.), est - il logique de concevoir une application ou d'un système composé de paquets développés en interne, de manière à promouvoir et à créer une architecture à couplage lâche?

Exemple

Un exemple de ceci serait de créer des packages pour l'accès à la base de données, ainsi que pour l'authentification et d'autres composants du système. Ceux-ci, bien sûr, utilisent également des packages externes. Ensuite, votre système importe et utilise ces packages - au lieu d'inclure leur code dans sa propre base de code.

Considérations

Pour moi, il semble que cela favoriserait le découplage du code et aiderait à la maintenabilité, presque d'une manière basée sur le Web contre une application de bureau (les mises à jour sont appliquées presque automatiquement, une base de code unique pour une fonctionnalité unique, etc.).

Cela ressemble-t-il à un concept de conception rationnel et sain? Est-ce actuellement utilisé comme un moyen standard de structurer les applications?

Réponses:


12

J'ai été impliqué dans des projets comme celui-ci deux fois maintenant (tous deux utilisant nuget avec .NET), et je dirais que, dans l'ensemble, c'est une bonne idée. Mais votre kilométrage peut varier.

Ne pensez pas une minute que c'est une panacée, que cela va résoudre tous vos problèmes sans en provoquer de nouveaux. La gestion des versions gagnera une toute nouvelle couche de complexité, vous devrez faire face à des problèmes de dépendance de version dont vous ignoriez l'existence, et vous aurez parfois du mal à prendre la décision car vous devez mettre à niveau quatre packages différents en raison d'un petit bug que vous devez corriger et libérer rapidement.

D'un autre côté, vous avez raison de dire que cela dissocie bien les choses. Sauf si vous en faites trop, vous trouverez probablement plus d'occasions où vous pensez «oh, cela a bien fonctionné» que «cela a ajouté beaucoup d'efforts». Si vous avez du code partagé entre plusieurs applications, il est particulièrement efficace car vous pouvez facilement mettre à niveau vos applications indépendamment.

Et, si vous êtes comme moi, vous commencerez rapidement à écrire des applications de test qui utilisent vos packages, pour supprimer des couches d'application entières de votre processus de recherche de bogues. Et cela, en soi, peut valoir largement le coût.


Magnifique entrée. En général, tout doit être équilibré, et j'aime la façon dont votre commentaire reste sur ces lignes. C'est formidable d'entendre que vous pensez que cela a tendance à bien fonctionner dans la plupart des cas ... et l'apparition de problèmes est une constante de toute façon. J'adore votre conseil sur le test des applications :). +1.
Juan Carlos Coto

1
J'ajouterais qu'il y a aussi beaucoup de projets qui font cela dans le monde * nix. Vous avez souvent des bibliothèques séparées des front-end des gui des ressources de développement, etc.
David Cowden

Intéressant. Cela semble être une bonne façon d'organiser un système complexe, mais j'avais peur que ce soit un cas de suringénierie. Il semble que s'il est appliqué avec prudence, il ne devrait pas l'être. Merci!
Juan Carlos Coto

3

C'est une bonne idée, dans l'ensemble. Vous devrez penser à mettre en place un référentiel de packages interne (généralement appelé "référentiel d'artefacts" dans le monde Java, ou "serveur pypi" dans le monde Python), afin que vous y conserviez les packages que vous ne voulez pas ou ne pouvez pas " t libérer en open source.

Comme l'a noté @pdr, préparez-vous à avoir votre propre enfer de dépendance , où un changement dans un paquet nécessite d'abord un autre changement dans un autre paquet, et cela signifie non seulement de changer une ligne de code, mais de le tester, éventuellement de faire accepter les changements, création d'une version et téléchargement de la version dans le référentiel de packages susmentionné. Et puis changer ce que vous aviez l' intention de changer.

La seule recette que je peux vous donner de mon expérience pour essayer de minimiser cela: ne vous fiez pas uniquement à l'abstrait de concepts communs de vos packages dans un package «commun» ou «framework» . Cela peut sembler être une chose très objective à faire, mais cela conduira à un package monstre qui nécessite des modifications et des versions fréquentes, éventuellement contradictoires. Bien mieux, pensez aux fonctionnalités de votre système et créez un package d'assistance pour chacun d'eux, comme vous l'avez souligné dans votre question.

En plus de cela, le principal avantage que vous obtiendrez est que vos applications sont isolées de (nombreuses) dépendances, vous pouvez donc les échanger sans douleur.


Excellent conseil. Je n'ai pas considéré un commonpaquet comme une option, mais, comme vous le dites, je pouvais le voir devenir une décision "raisonnable" à l'avenir. Mon intention était plus le long des lignes de composants plutôt que de code - donc idéalement, vous ne devriez pas avoir trop de morceaux de code qui font la même chose dans différents packages car ils sont destinés à faire des choses différentes. Je suppose que s'il y a des points communs entre les packages, ce type de répétition ne violerait pas les bons principes de programmation, car les projets sont par définition séparés.
Juan Carlos Coto
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.