Qu'y a-t-il de mal à utiliser un framework qui a beaucoup de dépendances ?

Question

J'ai récemment dit à un ami que je commençais à apprendre Catalyst (Perl) et il a insisté sur le fait que Catalyst avait tellement de dépendances que je devrais plutôt utiliser quelque chose comme Rails.

N'est-ce pas une bonne chose qu'il y ait beaucoup de dépendances ? Cela n'indique-t-il pas une forte réutilisation du code ? Je comprends qu'il y ait plus d'efforts à fournir pour installer le framework, mais y a-t-il d'autres inconvénients ?

Je vais reprendre mon Tutoriel sur le catalyseur jusqu'à ce que je reçoive des réponses juteuses. :-)

Answer 1

Il n'y a rien de particulièrement mauvais à cela. L'avantage de Catalyst est que ses parties peuvent être utilisées par des personnes qui n'utilisent pas tout Catalyst. Cela signifie qu'il y a plus d'yeux qui regardent et corrigent les bogues dans les parties critiques.

La plus grande plainte que j'entends est qu'il est ennuyeux de regarder tous ces messages passer dans le shell CPAN pendant l'installation de Catalyst. La solution est de tirer parti du gestionnaire de paquets de votre système d'exploitation au moment où vous commencez. Sur Debian, apt-get install libcatalyst-perl prend 15 secondes pour s'installer sur une machine sans autres modules Perl installés. 15 secondes. (Une installation CPAN simple n'est pas difficile non plus, mais je suppose que l'interpréteur de commandes CPAN standard vous pose beaucoup de questions stupides, ce qui rebute les débutants).

Ne vous inquiétez pas des dépendances, il existe de bons outils pour les gérer, et elles rendent le cadre plus fort et plus flexible.

Answer 2

C'est un sujet sur lequel j'ai déjà vu des messages. J'avais l'intention d'écrire un article sur le sujet et je l'ai finalement fait.

C'est ici : Le mensonge de l'indépendance

Je vous encourage à le lire. L'essentiel est simple, cependant. La question est fausse. Il ne s'agit pas de savoir si vous utilisez une application ou un framework avec beaucoup de dépendances ou une application ou un framework qui n'en a pas.

Il s'agit de : "Utilisez-vous une application ou un cadre qui a beaucoup de dépendances externes, ou un cadre qui essaie de tout faire en interne ?".

La question qui s'ensuit est la suivante : "Avez-vous vraiment confiance dans le fait que la ou les personnes qui écrivent ce cadre comprennent chaque nuance de chaque petit détail de chaque tâche à accomplir pour traiter une requête web ?".

Answer 3

Lorsqu'il existe des dépendances de version entre les composants, vous pouvez vous retrouver dans une situation de non-fonctionnement si vous êtes obligé de mettre à niveau un composant (par exemple, pour des raisons de sécurité) avant qu'une version compatible d'un composant dépendant soit disponible.

Cela suppose que vous puissiez vous mettre dans un état de fonctionnement en premier lieu. Il se peut que si vous essayez d'utiliser les versions actuelles de toutes les dépendances, vous découvriez qu'elles ne jouent pas le jeu.

Plus le nombre de dépendances est élevé, plus le risque est grand.

Rails n'est pas exempt de ce problème non plus. À chaque nouvelle version de Ruby, il y a une ruée pour mettre à jour les instructions sur la façon d'obtenir, par exemple, des pilotes de base de données.

Pour être honnête, ce problème s'est amélioré au fil du temps, même si cela n'a pas été sans heurts.

Answer 4

Mon expérience personnelle est que plus vous avez de dépendances, plus vous devez suivre les versions, ce qui peut conduire à des situations cauchemardesques. En particulier, la mise à jour d'une dépendance (en raison d'un bogue que vous voulez corriger, par exemple) peut entraîner des problèmes de compatibilité avec les autres dépendances. Par exemple, j'ai personnellement eu une situation où gcc 4.0.3 fonctionnait avec foo mais pas avec bar (dépendance de foo), et gcc 4.0.5 fonctionnait avec bar mais pas avec foo. Heureusement, la version 4.0.2 fonctionnait.

En outre, un plus grand nombre de dépendances tend à faire apparaître des produits "monstres de Frankenstein", composés de pièces qui n'ont pas été conçues au départ pour fonctionner ensemble. Un cadre bien intégré est conçu pour être agréable et cohérent. Cela peut bien sûr être corrigé en enveloppant correctement les différences.