Existe-t-il des preuves que l'utilisation de l'injection de dépendance améliore les résultats en génie logiciel?


18

Malgré sa popularité, existe-t-il des preuves empiriques montrant que l'injection de dépendance (et / ou l'utilisation d'un conteneur DI) aide, par exemple, à réduire le nombre de bogues, à améliorer la maintenabilité ou à augmenter la vitesse de développement sur des projets logiciels réels?


3
Duplication possible de l' injection de dépendance: comment la vendre Et avant de ne regarder que le titre et de penser "hé, ce n'est pas littéralement dupe" - lisez cette autre question et les réponses, je pense qu'elles correspondent très bien à cette question ici.
Doc Brown du

5
Acceptez le fait que de nombreuses pratiques de développement de logiciels professionnels n'ont pas de "preuves scientifiques", elles sont basées sur une expérience pratique. Donc, même si vous avez maintenant aggravé votre question juste pour essayer de la rendre artificiellement "moins dupliquée" que celle à laquelle j'ai lié, la vraie question que vous auriez dû poser pour obtenir les réponses que vous voulez vraiment savoir est cette autre question à laquelle j'ai lié . Et en passant, il semble maintenant que vous demandez des ressources tierces, ce qui est hors sujet sur ce site.
Doc Brown du

6
Très peu de techniques de développement de logiciels sont accompagnées de preuves scientifiques, du genre où vous pouvez pointer vers un document de recherche et déclarer définitivement qu'une technique est valable. Par conséquent, la plupart d'entre nous s'appuient sur des analyses d'expérience et de rentabilité pour justifier nos décisions. Vous choisissez une technique comme l'injection de dépendance parce que vous avez besoin des avantages qu'elle offre et parce que ces avantages l'emportent sur les coûts. Certes, ce calcul est toujours quelque peu subjectif.
Robert Harvey

1
@DocBrown Honnêtement, je ne vois cela ni comme un doublon, ni comme hors sujet, moi-même. La justification et l'efficacité d'une pratique de développement semblent très pertinentes pour SE.SE. Et, je vais fournir une réponse. L'OP ne sera probablement pas comme ma réponse ... mais, je pense qu'il est utile d' avoir un objectif réponse (presque réponse) si et OPCs peuvent PMs attendre à voir leur productivité des équipes vont comme par magie (ou leurs taux de bugs baisse) comme dès que quelqu'un crie «injection de dépendance».
svidgen

3
@gnat, il vaut probablement la peine de commencer une méta-question distincte pour les questions "preuves", qui ont été ajoutées à la portée de cette méta-réponse "ressource hors site" longtemps après l'avoir votée. Bien sûr, nous demander d'aller chercher des statistiques n'est probablement pas utile. Mais, l'essence de la question est parfaitement raisonnable. Et, pour moi, cela ressemble à de la paresse de l'appeler si rapidement hors sujet. Les commentaires ici donnent spécifiquement l'impression que nous sommes un groupe de dogmatistes DI qui ne peuvent tout simplement pas défendre nos pratiques. Eh bien, nous le pouvons. Et nous devrions.
svidgen

Réponses:


14

TLDR

Les données empiriques ne sont pas pertinentes. Les outils et les pratiques (comme DI) résolvent des problèmes particuliers . Comprenez vos problèmes, apprenez à utiliser les outils, et cela deviendra évident lorsqu'un outil est utile - et vous serez en mesure d'expliquer les résultats de manière beaucoup plus prophétique que toutes les données empiriques généralisées et agrégées.


Et maintenant, avec beaucoup plus de verbosité ...

Existe-t-il des preuves empiriques?

Bien sûr, probablement. Ou du moins peut-être. Mais qui s'en soucie? Ce n'est pas pertinent.

Une analyse statistique coûts-avantages de l'ID peut être intéressante d'un point de vue académique, mais elle ne prédit pas nécessairement le succès individuel. Les résultats agrégés masquent les succès et les échecs individuels . Et, je pourrais faire valoir que les données concernant les pratiques "évangéliques" sont particulièrement toxiques. Ces disciplines ont tendance à attirer les fanatiques et les fous, les deux qui obscurcissent l'impact net d'une mise en œuvre « pure », et non dont vous pourriez être!

Alors, comment savons-nous que l'injection de dépendance est valable du tout?

Bonne question! GRANDE question, en fait. Et je suis avec vous - je déteste perdre du temps et des efforts mentaux sur les "meilleures pratiques" dogmatiques que personne ne peut justifier. Donc, je suis content que vous ayez demandé.

Euh. Mais, voici le problème embarrassant ... En général , vous ne savez pas . Et, encore plus embarrassant, votre code peut ne pas s'améliorer en aucune façon en introduisant DI.


HALETER!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...


Alors, peut-être que maintenant vous vous demandez ...

Pourquoi devrais-je me soucier des choses qui n'ont pas été prouvées euh nuthin '!?

Tout d'abord, contentons-nous - de chaque côté du débat - de nous calmer. Je peux vous assurer qu'entre le dogmatisme et le scepticisme se trouve un beau paradis de raison et de pondération. (Et le poste excentrique SE.SE occasionnel.) Et, le POAP peut vous y conduire.

... J'entends par là le principe d'application des principes :

Les principes, les modèles et les pratiques ne sont pas des finalités. La bonne et correcte application de chacun est donc inspirée et contrainte par un objectif supérieur, plus final.

Vous devez comprendre pourquoi vous faites ce que vous faites!

(Le POAP n'est pas exempté du POAP.)

(Je dirais, "c'est moi qui souligne", mais ça vient de mon "blog" de toute façon. Donc, tout est à moi!)

Permettez-moi de réitérer le point principal ici: vous devez comprendre pourquoi vous faites ce que vous faites.

Et peut-être pour clarifier, il n'est généralement pas logique de prendre un "quelque chose" donné (comme l'injection de dépendance), et de l'utiliser sans déjà comprendre quel problème il résout - pour vous en particulier. Si vous comprenez vos problèmes et comment fonctionne le «quelque chose» (comme l'ID), il sera quelque peu «évident» à quel point le «quelque chose» est utile, peu importe ce que suggèrent les données empiriques généralisées et agrégées.

Si l'utilité ou la non- utilité de DI pour vous n'est pas évidente - ou du moins au-delà de vos pouvoirs de raisonnement - vous ne comprenez pas DI, ou vous ne comprenez pas vos propres problèmes.


Prenons une "parabole" du monde réel.

Nous devons construire une boîte. Nous avons du bois. Nous avons des clous. Et, nous avons deux outils: un marteau à griffes standard et un tournevis .

Maintenant, nous pouvons avoir des données empiriques générales pour montrer que les boîtes construites avec des tournevis sont globalement des boîtes beaucoup plus robustes que celles construites avec des marteaux. Mais, si vous essayez de visser ces clous, vous ne vous retrouverez pas du tout avec une boîte. Et, si vous essayez de les frapper avec le tournevis, vous pourriez éventuellement les faire entrer; mais cela nécessitera beaucoup plus de temps et d'efforts, et le résultat final sera moins précis (et robuste) que si vous aviez simplement utilisé le marteau.

Et, si vous avez déjà vu quelqu'un utiliser l'un ou l'autre de ces outils auparavant, et si vous comprenez à quoi ressemble une boîte, la décision est évidente.

Télékinésie!

Euh ... hmm ...


Oui, alors, quel problème l'injection de dépendance résout-elle?

Il empêche le code rigide et non configurable, qui est donc souvent non testable .

Il le fait en permettant d' invoquer du code pour décider avec quels objets un module fonctionne. Et je sais que vous y pensez, et vous avez raison: ce n'est même pas un nouveau concept à distance. Les paramètres de méthode / fonction existent depuis l'algèbre.

Nous avons commencé à évangéliser le passage des paramètres de base, en l'appelant "injection de dépendance", une fois que nous avons accumulé et hérité suffisamment de code pour voir nos déséquilibres. Les montagnes de code sur lesquelles nous étions assis ne pouvaient pas être facilement modifiées, testées ou même réutilisées , simplement parce que les dépendances étaient cachées.

Par conséquent, la croisade zélée pour l'injection de dépendance ...

K. Mais, je peux passer des arguments très bien. Pourquoi les cadres ?

Si je comprends bien, les cadres DI résolvent principalement le problème de l'accumulation de plaques passe-partout (en raison d'un DI trop zélé, IMO) - en particulier lorsqu'il existe des dépendances "par défaut" standard pour tous les modules qui en ont besoin. Les frameworks DI font des choses magiques (potentiellement même coquines!) Pour glisser ces dépendances par défaut lorsqu'elles ne sont pas explicitement transmises au moment de l'invocation. (Même effet qu'un localisateur de service lorsqu'il est utilisé de cette manière, attention!)

L'injection de dépendance, en tant que «discipline», est en réalité très difficile à réaliser. Il ne s'agit pas d'utiliser DI ou non; il est une question de savoir quelles dépendances sont susceptibles de changer ou besoin moqueur et injecter ceux . Et puis, il s'agit de décider si DI convient mieux que certaines alternatives, comme l'emplacement du service ...

Mais, je vous encourage à Google il , peut - être voir cette réponse SO , peut - être parler à un super-développeur expérimenté et réussi dans votre secteur d' activité, ainsi que des exemples de spécifiques à poste CR.SE .


4
Avez-vous reniflé une partie de la colle de @ CandiedOrange? +1 pour le principe des fins appliquées.
Robert Harvey

1
@RobertHarvey J'aimerais pouvoir dire que je nouvelle de quelle colle nous parlions! J'ai eu une vendetta de longue date contre l'ingénierie confessionnelle ... À moins que vous ne parliez de la nature narrative - peut-être même loufoque - du message?
svidgen

2
Note aux électeurs, rien ne me remplit plus de confiance dans ma décision de répondre à une question que des votes équilibrés de haut en bas! ... Ce serait bien de voir vos critiques dans les commentaires ...
svidgen

3
@RobertHarvey ne sais pas à laquelle de mes nombreuses colles vous faites référence, mais je me retrouve à accepter chaque mot de cela. Il est facile de penser qu'un marteau craint lorsque vous l'utilisez sur des vis.
candied_orange

A commencé à éditer pour inclure plus de détails sur DI spécifiquement et faire bouillonner le TLDR vers le haut. Et puis les enfants ont commencé à s'agiter, alors j'ai frappé Enregistrer. ... Si j'ai par inadvertance perdu l'essence de ce que vous avez voté (pour ceux d'entre vous qui l'ont fait), faites-le moi savoir!
svidgen

12

J'ai recherché Google, Google Scholar, ACM et IEEE Voici les documents que j'ai pu trouver:

  • Cadres d'injection de dépendance: une amélioration de la testabilité? . Il fait valoir que la "testabilité" peut être définie comme une "faible cohésion". Il indique que DI conduit à une cohésion plus faible, une cohésion plus faible est corrélée avec une couverture de test plus élevée, et qu'une couverture de test plus élevée est corrélée avec plus de défauts trouvés. Il dit que, sur cette base, DI améliore la testabilité.

    Je n'aime pas ça pour deux raisons. Tout d'abord, il dit "A est corrélé avec B, B est corrélé avec C, donc A cause C", ce qui est quelques étapes dans la logique que je ne vois pas comme étant bien supportée par le papier. Deuxièmement, il admet qu'il ne mesure que les «sous-parties de la testabilité» et que la «testabilité» en général n'est pas quelque chose de facile à définir. Enfin, leur mesure de testabilité est définie en termes de nombre de dépendances injectées!

  • Effets de l'injection de dépendance sur la maintenabilité . Ils comparent les projets utilisant DI aux projets n'utilisant pas DI qu'ils ont trouvés sur SourceForge et voient s'il y a des différences dans les mesures de cohésion. Pour réduire les biais, ils ont jumelé les projets pour qu'ils soient aussi similaires que possible. En fin de compte, ils ont vu des signaux que les projets avec beaucoup d'ID étaient un peu moins couplés que les projets avec seulement peu d'ID. Cependant, il semble qu'il n'y ait pas eu de différence significative de cohésion entre les projets DI et leur paire non DI, donc cela pourrait être une conséquence des domaines spécifiques. Ils listent "aucune corrélation" comme résultat principal et "peut-être que ça aide un peu?" comme sujet à approfondir.

  • Évaluation empirique de l'impact de l'injection de dépendance sur le développement d'applications de service Web . Le résumé n'explique pas vraiment ce qu'ils recherchent. J'ai déterré et lu une préimpression et pour autant que je sache, il s'agit en fait de la capacité des outils automatisés à découvrir les services. Les services écrits dans un style DI étaient plus faciles à découvrir. En outre, il cite l'étude précédente que j'ai répertoriée comme fournissant des preuves empiriques que DI réduit le couplage, ce qui est l'opposé de ce que prétendait ce document.

Pour ces trois articles (et pour An Empirical Study into Use of Dependency Injection in Java , qui ne porte que sur la détection), j'ai suivi tous les articles qui les ont cités, dont aucun ne visait à déterminer l'efficacité de l'ID. Compte tenu de tout cela, je suis sûr de dire que non , nous n'avons pas encore de preuves empiriques sur l'amélioration ou non de la qualité logicielle.


2
Cela répond directement à la question. +1
Matthew James Briggs

3
@MatthewJamesBriggs Je ne suis pas l'inverse, mais est-ce que répondre directement à la question est important si la réponse est trompeuse ou incomplète ???
svidgen

@svidgen Je ne vois pas comment la réponse est incomplète. La question était "avons-nous des preuves empiriques que DI fonctionne?" Et la réponse est non." Cela ne dit rien sur le fait que cela fonctionne ou non, juste qu'il n'y a aucune recherche à ce sujet.
Hovercouch

1
Incomplet et trompeur en ce que vous répondez limite la portée des "preuves" aux "documents que vous avez (sic) été en mesure de trouver" et omis sur "l'efficacité" sans respect pour les objectifs réels de DI, et que vous avez a donc conclu que la réponse est "non" sans qualification ... Je dirais que, si vous allez répondre "directement" à la question, comme @MatthewJamesBriggs le suggère, il vous incombe de creuser profondément et d'être capable de démontrer avec une grande certitude que vous avez exploré toutes les avenues ...
svidgen

1
Et je suppose que , quand moissonneuse - batteuse avec votre évaluation hâtive de la seule ressource que vous avez cites, je pourrais même dire que cette réponse très trompeuse. Parce que, en dehors de toutes les preuves potentielles que vous ignorez, vous prenez des preuves documentées et les actualisez immédiatement pour des raisons qui ne sont pas entièrement expliquées. ... Si je devais prétendre, par exemple, qu '"il n'y a aucune preuve que nous ayons atterri sur la lune" parce que le "seul" papier que j'ai jamais lu sur la question provenait d'une révision "obsolète" du manuel que je ne fais pas confiance, j'espère que vous seriez sceptique quant à mes méthodes ...
svidgen
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.