Gibt es Belege dafür, dass die Verwendung von Dependency Injection die Ergebnisse im Software-Engineering verbessert?

18

Gibt es trotz seiner Beliebtheit empirische Belege dafür, dass Dependency Injection (und / oder die Verwendung eines DI-Containers) beispielsweise bei der Reduzierung der Fehleranzahl, der Verbesserung der Wartbarkeit oder der Erhöhung der Entwicklungsgeschwindigkeit bei echten Softwareprojekten hilft?

NMrt
quelle
3
Mögliches Duplikat von Dependency Injection: Wie man es verkauft Und bevor man nur auf die Überschrift schaut und denkt "Hey, das ist nicht buchstäblich ein Betrug" - lies diese andere Frage und die Antworten, ich denke sie passen sehr gut zu dieser Frage hier.
Doc Brown
5
Akzeptieren Sie die Tatsache, dass viele Praktiken der professionellen Softwareentwicklung keine "wissenschaftlichen Beweise" haben, sondern auf praktischen Erfahrungen beruhen. Selbst wenn Sie Ihre Frage jetzt verschlimmert haben, nur weil Sie versucht haben, sie künstlich "weniger dupliziert" zu machen als die, mit der ich verknüpft war, ist die eigentliche Frage, die Sie hätten stellen sollen, um die Antworten zu erhalten, die Sie wirklich wissen möchten, die andere Frage, mit der ich verknüpft war . Übrigens, jetzt scheinen Sie nach Ressourcen von Drittanbietern zu fragen, die auf dieser Website nicht zum Thema gehören.
Doc Brown
6
Nur sehr wenige Techniken in der Softwareentwicklung werden von wissenschaftlichen Nachweisen begleitet, wie Sie sie auf eine Forschungsarbeit verweisen und definitiv für wertvoll erklären können. Folglich verlassen sich die meisten von uns auf Erfahrung und Kosten-Nutzen-Analysen, um ihre Entscheidungen zu rechtfertigen. Sie entscheiden sich für eine Technik wie die Abhängigkeitsinjektion, weil Sie die Vorteile benötigen, die sie bietet, und weil diese Vorteile die Kosten überwiegen. Zugegeben, dieser Kalkül ist immer etwas subjektiv.
Robert Harvey
1
@DocBrown Ehrlich gesagt sehe ich das weder als Duplikat noch als Off-Topic an. Die Begründung und Wirksamkeit einer Entwicklungspraxis scheint für SE.SE sehr relevant zu sein. Und ich werde eine Antwort geben. Die OP wird meine Antwort wahrscheinlich nicht mögen ... aber ich denke, es lohnt sich, eine objektive Antwort (fast Antwort) zu haben, ob TPOs und PMs damit rechnen können, dass die Produktivität ihrer Teams auf magische Weise steigt (oder die Fehlerraten sinken) sobald jemand "Abhängigkeitsinjektion" ruft.
Svidgen
3
@gnat Es lohnt sich wahrscheinlich, eine separate Meta-Frage für "Evidence" -Fragen zu starten, die dem Umfang der Meta-Antwort "Off Site Resource" hinzugefügt wurden, lange nachdem ich sie hochgeladen habe. Sicher, es ist wahrscheinlich nicht hilfreich, uns zu bitten, nach Statistiken zu suchen. Aber das Wesen der Frage ist durchaus vernünftig. Und für mich klingt es nach Faulheit, es so schnell vom Thema abzubringen. Die Kommentare hier erwecken speziell den Eindruck, dass wir eine Gruppe von DI-Dogmatikern sind, die unsere Praktiken einfach nicht verteidigen können. Nun, wir können. Und wir sollten es tun.
Svidgen

Antworten:

14

TLDR

Die empirischen Daten sind irrelevant. Tools und Methoden (wie DI) lösen bestimmte Probleme. Verstehen Sie Ihre Probleme, lernen Sie den Umgang mit den Werkzeugen und es wird deutlich, wann ein Werkzeug wertvoll ist - und Sie können die Ergebnisse prophetischer erklären als alle verallgemeinerten, aggregierten, empirischen Daten.


Und jetzt mit viel mehr Ausführlichkeit ...

Gibt es empirische Beweise?

Sicher wahrscheinlich. Oder zumindest vielleicht. Aber wen interessiert es? Es ist nicht relevant.

Eine statistische Kosten-Nutzen-Analyse von DI mag wissenschaftlich interessant sein, sagt jedoch nicht unbedingt den individuellen Erfolg voraus. Aggregierte Ergebnisse verbergen individuelle Erfolge und Misserfolge. Und ich könnte argumentieren, dass Daten über "evangelische" Praktiken besonders giftig sind. Diese Disziplinen ziehen sowohl Eiferer als auch Narren an, die beide die Nettoauswirkung einer "reinen" Implementierung verschleiern und von denen Sie beide sein könnten !

Woher wissen wir also, dass Abhängigkeitsinjektion überhaupt wertvoll ist ?

Gute Frage! Tatsächlich eine GROSSE Frage. Und ich bin bei Ihnen - ich hasse es, Zeit und Mühe mit dogmatischen "Best Practices" zu verschwenden, die niemand rechtfertigen kann. Ich bin froh, dass Sie gefragt haben.

Uhh. Aber hier ist das peinliche Problem ... Im allgemeinen Begriffen, Sie nicht wissen. Und noch peinlicher ist es, dass Ihr Code durch die Einführung von DI in keiner Weise besser wird.


KEUCHEN!

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

...


Vielleicht fragst du dich jetzt ...

Warum sollte ich mir die Mühe machen, dass Dinge nicht ähm bewiesen sind?

Lassen Sie uns zuallererst einfach - auf jeder Seite der Debatte - zur Ruhe kommen. Ich kann Ihnen versichern, dass zwischen Dogmatismus und Skepsis ein wunderschönes Paradies der Vernunft und Besonnenheit liegt. (Und der gelegentliche exzentrische SE.SE-Beitrag.) Und der POAP kann Sie dorthin führen.

... Womit ich meine, das Prinzip der Anwendung von Prinzipien :

Prinzipien, Muster und Praktiken sind keine endgültigen Zwecke. Die gute und ordnungsgemäße Anwendung eines jeden wird daher von einem überlegenen, endgültigeren Zweck inspiriert und eingeschränkt .

Sie müssen verstehen, warum Sie das tun, was Sie tun!

(Der POAP ist nicht vom POAP ausgenommen.)

(Ich würde sagen, "Hervorhebung meiner", aber es ist auf jeden Fall aus meinem eigenen "Blog". Also, es ist alles meins!)

Lassen Sie mich den Hauptpunkt wiederholen: Sie müssen verstehen, warum Sie das tun, was Sie tun.

Und vielleicht ist es zur Verdeutlichung in der Regel nicht sinnvoll, ein bestimmtes "Etwas" (wie "Abhängigkeitsinjektion") zu nehmen und es zu verwenden, ohne bereits zu verstehen, welches Problem es löst - speziell für Sie. Wenn Sie Ihre Probleme verstehen und wissen, wie das "Etwas" (wie DI) funktioniert, wird es einigermaßen "offensichtlich" sein, wie hilfreich das "Etwas" ist, unabhängig davon, was die verallgemeinerten, aggregierten, empirischen Daten nahelegen.

Wenn DI des Hilfs oder un -helpfulness Ihnen nicht klar ist - oder zumindest über Ihre Denkfähigkeit - Sie entweder nicht verstehen , DI, oder Sie nicht über Ihre eigenen Probleme verstehen.


Betrachten wir eine reale "Parabel".

Wir müssen eine Kiste bauen. Wir haben Holz. Wir haben Nägel. Und wir haben zwei Werkzeuge: Einen normalen Klauenhammer und einen Schraubendreher .

Nun können wir einige breite empirische Daten haben, um zu zeigen, dass mit Schraubenziehern hergestellte Kästen insgesamt wesentlich robuster sind als mit Hämmern hergestellte. Aber wenn Sie versuchen, diese Nägel einzuschrauben, werden Sie überhaupt keine Schachtel haben. Und wenn Sie versuchen, sie mit dem Schraubenzieher einzuschlagen, können Sie sie möglicherweise einführen. Dies erfordert jedoch erheblich mehr Zeit und Mühe, und das Endergebnis ist weniger präzise (und robuster) als wenn Sie einfach den Hammer verwendet hätten.

Und wenn Sie schon einmal jemanden gesehen haben, der eines der beiden Tools verwendet, und wenn Sie verstehen, wie eine Box aussieht, liegt die Entscheidung auf der Hand.

Telekinese!

Äh ... hmm ...


Ja, welches Problem löst Dependency Injection?

Es verhindert starren, nicht konfigurierbaren Code, der daher oft nicht testbar ist .

Dies geschieht, indem der Aufruf von Code ermöglicht wird, um zu entscheiden, mit welchen Objekten ein Modul arbeitet. Und ich weiß, dass Sie darüber nachdenken, und Sie haben Recht: Dies ist nicht einmal ein entferntes neues Konzept. Methoden- / Funktionsparameter existieren seit dem Auftreten der Algebra.

Wir haben damit begonnen, die grundlegende Parameterübergabe zu evangelisieren und sie "Abhängigkeitsinjektion" zu nennen, sobald wir genug Code gesammelt und geerbt haben, um unsere Ungleichgewichte zu erkennen. Die Berge von Code, auf denen wir saßen, konnten nicht einfach geändert, getestet oder sogar wiederverwendet werden , nur weil die Abhängigkeiten verborgen waren.

Daher der eifrige Kreuzzug für Abhängigkeitsinjektion ...

K. Aber ich kann gut argumentieren. Warum die Frameworks ?

So wie ich es verstehe, lösen DI- Frameworks in erster Linie das Problem des Boilerplate-Aufbaus (aufgrund von übereifrigen DI, IMO) - insbesondere, wenn für alle Module, die diese benötigen, Standardabhängigkeiten vorhanden sind. DI-Frameworks tun magische (möglicherweise sogar böse!) Dinge, um diese Standardabhängigkeiten einzuschleusen, wenn sie beim Aufruf nicht explizit übergeben werden. (Gleicher Effekt wie ein Service Locator, wenn er auf diese Weise verwendet wird!)

Abhängigkeitsinjektion als "Disziplin" ist eigentlich sehr schwer zu erreichen. Es geht nicht darum, DI zu verwenden oder nicht. es ist eine Sache zu wissen , welche Abhängigkeiten wahrscheinlich ändern oder Notwendigkeit spöttischen sind und Injizieren diejenigen . Und dann ist es eine Frage der Entscheidung, ob DI besser als irgendeine Alternative wie Service Location passt ...

Aber ich möchte Sie dazu ermutigen, es zu googeln , diese SO-Antwort zu lesen , möglicherweise mit einem äußerst erfahrenen und erfolgreichen Entwickler in Ihrer Branche zu sprechen und spezifische Beispiele an CR.SE zu senden .

Svidgen
quelle
4
Haben Sie an @ CandiedOranges Kleber gerochen? +1 für das Prinzip der angewandten Zwecke.
Robert Harvey
1
@RobertHarvey Wünschte, ich könnte sagen, ich neu, über welchen Kleber wir gesprochen haben! Ich habe seit langem eine Rache gegen glaubensbasiertes Engineering ... Wenn Sie sich nicht auf die narrative - möglicherweise sogar verrückte - Natur des Postens beziehen?
Svidgen
2
Die Randbemerkung zu den Abwählern, nichts erfüllt mich mehr mit Vertrauen in meine Entscheidung, eine Frage zu beantworten, als ausgewogene Auf- und Abstimmungen! ... Es wäre schön, Ihre Kritik in den Kommentaren zu sehen ...
Svidgen
3
@RobertHarvey ist sich nicht sicher, auf welchen meiner vielen Klebstoffe Sie sich beziehen, aber ich bin mit jedem Wort einverstanden. Es ist leicht zu glauben, dass ein Hammer scheiße ist, wenn man ihn an Schrauben benutzt.
candied_orange
Die Bearbeitung wurde gestartet, um mehr Details zu DI zu erhalten und das TLDR nach oben zu blasen. Und dann fingen die Kinder an sich aufzuregen, also drückte ich Speichern. ... Wenn ich versehentlich das Wesentliche von dem verloren habe, was Sie (für diejenigen von Ihnen, die es getan haben), lassen Sie es mich bitte wissen!
Svidgen
12

Ich habe nach Google, Google Scholar, ACM und IEEE gesucht.

  • Abhängigkeitsinjektions-Frameworks: eine Verbesserung der Testbarkeit? . Es wird argumentiert, dass "Testbarkeit" als "geringe Kohäsion" definiert werden kann. Darin heißt es, dass DI zu einer geringeren Kohäsion führt, dass eine geringere Kohäsion mit einer höheren Testabdeckung korreliert und dass eine höhere Testabdeckung mit mehr gefundenen Fehlern korreliert. Daraus geht hervor, dass DI die Testbarkeit verbessert.

    Ich mag das aus ein paar Gründen nicht. Zuallererst heißt es: "A ist mit B korreliert, B ist mit C korreliert, also verursacht A C", ein paar Schritte in der Logik, die ich nicht als gut durch das Papier unterstützt sehe. Zweitens gibt es zu, dass es nur "Teilbereiche der Testbarkeit" misst und dass "Testbarkeit" im Allgemeinen nicht leicht zu definieren ist. Schließlich wird ihr Testbarkeitsmaß anhand der Anzahl der injizierten Abhängigkeiten definiert!

  • Auswirkungen der Abhängigkeitsinjektion auf die Wartbarkeit . Sie vergleichen Projekte, die DI verwenden, mit Projekten, die DI nicht verwenden, die sie in SourceForge gefunden haben, und prüfen, ob es Unterschiede bei den Kohäsionsmetriken gibt. Um die Verzerrung zu verringern, haben sie die Projekte so ähnlich wie möglich gepaart. Letztendlich sahen sie Signale, dass Projekte mit viel DI etwas weniger gekoppelt waren als Projekte mit nur wenig DI. Es scheint jedoch keinen signifikanten Unterschied in der Kohäsion zwischen den DI-Projekten und ihrem Nicht-DI-Paar zu geben, sodass dies eine Konsequenz der spezifischen Domänen sein könnte. Sie führen "keine Korrelation" als primäres Ergebnis an und das "Vielleicht hilft es ein wenig?" als Thema für das weitere Studium.

  • Empirische Bewertung der Auswirkungen der Abhängigkeitsinjektion auf die Entwicklung von Webdienstanwendungen . Die Zusammenfassung erklärt nicht wirklich, wonach sie suchen. Ich habe einen Preprint ausgegraben und gelesen und soweit ich das beurteilen kann, geht es darum, wie gut automatisierte Tools Services erkennen können. In einem DI-Stil geschriebene Dienste wurden leichter erkannt. Sie zitiert auch die frühere Studie, die ich als empirischen Beweis dafür angeführt habe, dass DI die Kopplung reduziert, was das Gegenteil von dem ist, was in dieser Veröffentlichung behauptet wurde.

Für diese drei Veröffentlichungen (und für eine empirische Studie zur Verwendung von Dependency Injection in Java , in der es nur um Entdeckung geht) habe ich alle Veröffentlichungen weiterverfolgt, in denen es nicht um die Bestimmung der Wirksamkeit von DI ging. All dies gegeben, ich sagte zuversichtlich , dass keine , nicht noch empirische Evidenz auf uns nicht, ob oder nicht DI Softwarequalität verbessert.

Hovercouch
quelle
2
Dies beantwortet die Frage direkt. +1
Matthew James Briggs
3
@MatthewJamesBriggs Ich bin nicht der Abwähler, aber ist die Beantwortung der Frage direkt von Bedeutung, wenn die Antwort irreführend oder unvollständig ist?
Svidgen
@svidgen Ich sehe nicht, wie die Antwort unvollständig ist. Die Frage war: "Haben wir empirische Beweise, dass DI funktioniert?" und die antwort ist "nein". Das sagt nichts darüber aus, ob es funktioniert oder nicht, nur dass es keine Forschung darüber gibt.
Hovercouch
1
Unvollständig und irreführend, da Ihre Antwort den Umfang der "Beweise" auf "Papiere, die Sie (sic) finden konnten" und die sich über "Wirksamkeit" hinwegsetzen, ohne die tatsächlichen Zwecke von DI zu respektieren, und die Sie haben Daraus folgerte ich , dass die Antwort "Nein" ohne Qualifikation ist ... Ich würde argumentieren, dass, wenn Sie die Frage "direkt" beantworten, wie @MatthewJamesBriggs vorschlägt, dass Sie dies getan haben, es eine schwere Aufgabe für Sie ist, tief zu graben und zu sein in der
lage
1
Und ich denke, wenn kombinieren , dass mit Ihrer eilten Bewertung der eine Ressource , die Sie haben nennen, könnte ich auch diese Antwort nennen sehr irreführend. Denn abgesehen von allen potenziellen Beweisen, die Sie ignorieren, nehmen Sie dokumentierte Beweise und diskontieren sie sofort aus Gründen, die nicht vollständig erklärt wurden. ... Wenn ich zum Beispiel behaupten würde, dass "es keine Beweise dafür gibt, dass wir auf dem Mond gelandet sind", weil die "einzige" Zeitung, die ich jemals zu diesem Thema gelesen habe, aus einer "veralteten" Lehrbuchrevision stammt, die ich nicht habe Vertrauen, ich hoffe, Sie wären skeptisch gegenüber meinen Methoden ...
Svidgen