Czy istnieją dowody na to, że zastosowanie wstrzykiwania zależności poprawia wyniki w inżynierii oprogramowania?

18

Niezależnie od popularności, czy istnieją jakieś dowody empiryczne, które pokazują, że wstrzykiwanie zależności (i / lub użycie kontenera DI) pomaga, powiedzmy, w zmniejszeniu liczby błędów, poprawie łatwości konserwacji lub zwiększeniu prędkości opracowywania rzeczywistych projektów oprogramowania?

NMrt
źródło
3
Możliwy duplikat zastrzyku zależności: jak go sprzedać I zanim spojrzysz tylko na nagłówek i pomyślisz „hej, to nie jest dosłownie dupe” - przeczytaj to drugie pytanie i odpowiedzi, myślę, że pasują bardzo do tego pytania tutaj.
Doc Brown
5
Zaakceptuj fakt, że wiele praktyk profesjonalnego tworzenia oprogramowania nie ma „dowodów naukowych”, są one oparte na doświadczeniu praktycznym. Nawet jeśli teraz pogorszyłeś swoje pytanie tylko dlatego, że próbujesz sztucznie uczynić je „mniej zduplikowanym” niż to, z którym się łączyłem, prawdziwym pytaniem, które powinieneś zadać, aby uzyskać odpowiedzi, które naprawdę chcesz wiedzieć, jest inne pytanie, z którym się łączyłem . Nawiasem mówiąc, teraz wydaje się, że prosisz o zasoby innych firm, co jest nie na temat na tej stronie.
Doc Brown
6
Bardzo niewielu technikom tworzenia oprogramowania towarzyszy dowód naukowy, w rodzaju, w którym można wskazać artykuł badawczy i ostatecznie zadeklarować, że technika jest cenna. W związku z tym większość z nas polega na analizie doświadczenia i kosztów / korzyści w celu uzasadnienia naszych decyzji. Wybierasz technikę, taką jak wstrzykiwanie zależności, ponieważ potrzebujesz korzyści, które ona zapewnia, i ponieważ korzyści te przewyższają koszty. Trzeba przyznać, że rachunek różniczkowy jest zawsze nieco subiektywny.
Robert Harvey
1
@DocBrown Szczerze mówiąc, nie uważam tego ani za duplikat, ani za osobny temat. Uzasadnienie i skuteczność praktyki rozwojowej wydają się bardzo istotne dla SE.SE. I zamierzam udzielić odpowiedzi. PO prawdopodobnie nie będzie tak jak moją odpowiedź ... ale myślę, że warto mającą obiektywną odpowiedź (prawie-odpowiedź) to, czy TPO i premierzy mogą spodziewać się ich produktywność zespołów magicznie idą w górę (lub ich stopy błędów upuść) jako gdy tylko ktoś krzyknie „zastrzyk zależności”.
svidgen
3
@gnat prawdopodobnie warto zacząć od odrębnego meta pytania dla pytań „dowodowych”, które zostały dodane do zakresu tej odpowiedzi „poza zasobem witryny” długo po tym, jak ją głosowałem. Oczywiście poproszenie nas o znalezienie statystyk prawdopodobnie nie jest pomocne. Ale istota tego pytania jest całkowicie rozsądna. I dla mnie brzmi to jak lenistwo, aby tak szybko odrzucić to z tematu. Komentarze tutaj w szczególności sprawiają wrażenie, że jesteśmy grupą dogmatyków DI, którzy po prostu nie są w stanie obronić naszych praktyk. Cóż, możemy. I powinniśmy.
svidgen

Odpowiedzi:

14

TLDR

Dane empiryczne są nieistotne. Narzędzia i praktyki (takie jak DI) rozwiązują określone problemy. Zrozum swoje problemy, naucz się korzystać z narzędzi, a stanie się oczywiste, kiedy narzędzie jest cenne - a będziesz w stanie wyjaśnić wyniki o wiele bardziej proroczo niż jakiekolwiek uogólnione, zagregowane dane empiryczne.


A teraz z dużo większą gadatliwością ...

Czy istnieją dowody empiryczne?

Pewnie, pewnie. A przynajmniej może. Ale kogo to obchodzi? To nie ma znaczenia.

Statystyczna analiza kosztów i korzyści DI może być interesująca z naukowego punktu widzenia, ale niekoniecznie przewiduje indywidualny sukces. Zagregowane wyniki ukrywają indywidualne sukcesy i porażki. I mogę argumentować, że dane dotyczące praktyk „ewangelicznych” są szczególnie trujące. Dyscypliny te mają tendencję do przyciągania zarówno fanatyków, jak i głupców, z których oba przesłaniają wpływ netto „czystej” implementacji, i którymkolwiek z nich możesz być!

Skąd więc wiemy, że Dependency Injection jest w ogóle cenny ?

Dobre pytanie! WIELKIE pytanie. I jestem z tobą - nie znoszę marnować czasu i wysiłku umysłowego na dogmatyczne „najlepsze praktyki”, których nikt nie może uzasadnić. Cieszę się, że o to pytałeś.

Uhh Ale tu jest kłopotliwy problem ... W ogólnym ujęciu, ty nie wiesz. A nawet bardziej zawstydzające, twój kod może nie poprawić się w żaden sposób poprzez wprowadzenie DI.


ŁAPANIE TCHU!

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

...


Może zastanawiasz się ...

Dlaczego miałbym zawracać sobie głowę sprawami, których nie udowodniono, prawda ?!

Po pierwsze, uspokójmy się - po każdej stronie debaty. Mogę was zapewnić, że między dogmatyzmem a sceptycyzmem leży piękny raj rozsądku i opanowania. (I od czasu do czasu ekscentryczny post SE.SE.) I, POAP może cię tam poprowadzić.

... Rozumiem przez to zasadę stosowania zasad :

Zasady, wzorce i praktyki nie są ostatecznymi celami. Dobre i właściwe zastosowanie każdego z nich jest zatem inspirowane i ograniczane przez nadrzędny, bardziej ostateczny cel.

Musisz zrozumieć, dlaczego robisz to, co robisz!

(POAP nie jest zwolniony z POAP.)

(Powiedziałbym: „moje podkreślenie”, ale i tak pochodzi z mojego „bloga”. A więc to wszystko moje!)

Chciałbym powtórzyć główny punkt: musisz zrozumieć, dlaczego robisz to, co robisz.

Być może, aby to wyjaśnić, zazwyczaj nie ma sensu brać żadnego „czegoś” (takiego jak Dependency Injection) i używać go, nie wiedząc już, jaki problem rozwiązuje - dla ciebie. Jeśli zrozumiesz swoje problemy i sposób, w jaki działa „coś” (jak DI), będzie nieco „oczywiste”, jak pomocne jest „coś”, bardzo niezależnie od tego, co sugerują uogólnione, zagregowane dane empiryczne.

Jeśli uczynność DI lub un -helpfulness do ciebie nie jest oczywiste - przynajmniej poza swoje uprawnienia rozumowania - to albo nie rozumieją, DI, czy ty nie rozumiesz swoje własne problemy.


Rozważmy prawdziwą „przypowieść”.

Musimy zbudować pudełko. Mamy drewno. Mamy gwoździe. I mamy dwa narzędzia: standardowy młot pazurowy i śrubokręt .

Teraz możemy mieć pewne szerokie dane empiryczne, aby pokazać, że skrzynki zbudowane za pomocą śrubokrętów są ogólnie znacznie bardziej solidnymi skrzynkami niż te zbudowane z młotami. Ale jeśli spróbujesz wkręcić te gwoździe, w ogóle nie otrzymasz pudełka. A jeśli spróbujesz wbić je śrubokrętem, w końcu możesz je wsadzić; ale będzie to wymagało znacznie więcej czasu i wysiłku, a końcowy wynik będzie mniej precyzyjny (i solidny) niż po prostu przy użyciu młotka.

A jeśli kiedykolwiek widziałeś, jak ktoś używa któregoś z narzędzi, i jeśli rozumiesz, jak wygląda pudełko, decyzja jest oczywista.

Telekinezja!

Err ... hmm ...


Tak, więc jaki problem rozwiązuje Dependency Injection?

Działa w celu zapobiegania sztywnemu, nieskonfigurowanemu kodowi, który często dlatego nie jest testowalny .

Robi to, pozwalając na wywołanie kodu, aby zdecydować, z którymi obiektami działa moduł. Wiem, że o tym myślisz i masz rację: nie jest to nawet nowa koncepcja. Parametry metody / funkcji istniały od czasu algebry.

Zaczęliśmy ewangelizować przekazywanie podstawowych parametrów, nazywając je „wstrzykiwaniem zależności”, gdy tylko zgromadziliśmy i odziedziczyliśmy wystarczającą ilość kodu, aby zobaczyć nasze nierównowagi. Gór kodu, nad którymi siedzieliśmy, nie można łatwo zmienić, przetestować, a nawet ponownie wykorzystać , po prostu dlatego, że zależności są ukryte.

Stąd gorliwa krucjata dla Wstrzykiwania Zależności ...

K. Ale mogę przekazać argumenty w porządku. Dlaczego ramy ?

Jak rozumiem, frameworki DI przede wszystkim rozwiązują problem gromadzenia się płyt kotłowych (z powodu nadgorliwego DI, IMO) - szczególnie gdy istnieją standardowe „domyślne” zależności dla wszystkich modułów, które ich wymagają. Frameworki DI robią magiczne (potencjalnie nawet niegrzeczne!) Rzeczy, aby ukryć te domyślne zależności, gdy nie są one jawnie przekazywane w momencie wywołania. ( Pamiętaj, że taki sam efekt, jak Lokalizator usług, jeśli jest używany w ten sposób!)

Wstrzykiwanie zależności, jako „dyscyplina”, jest naprawdę bardzo trudne do osiągnięcia. To nie jest kwestia używania DI, czy nie; chodzi o to, aby wiedzieć, które zależności mogą się zmienić lub wymagać kpienia z nich . A potem decyduje, czy DI pasuje lepiej niż jakaś alternatywa, na przykład lokalizacja usługi ...

Ale, ja zachęcam do google , może zobaczyć to, więc odpowiedź , ewentualnie skonsultować się z super-doświadczonych i udane deweloper w swojej branży, a konkretne przykłady dodaj do CR.SE .

svidgen
źródło
4
Wąchałeś trochę kleju @ CandiedOrange? +1 za zasadę stosowanych celów.
Robert Harvey
1
@RobertHarvey Chciałbym powiedzieć, że jestem nowy, o którym kleju mówiliśmy! Od dawna mam wendetę przeciwko inżynierii opartej na wierze ... Chyba że odwołujesz się do narracji - być może nawet dziwnej - natury postu?
svidgen
2
Uwaga dla downvoters, nic nie napełnia mnie większą pewnością siebie w mojej decyzji odpowiedzi na pytanie niż dobrze wyważone głosy w górę i w dół! ... Byłoby miło widzieć waszą krytykę w komentarzach ...
svidgen
3
@RobertHarvey nie jestem pewien, do którego z wielu moich klejów się odwołujesz, ale zgadzam się na każde słowo tego. Łatwo jest myśleć, że młot jest do bani, gdy używasz go do śrub.
candied_orange
Rozpoczęto edycję, aby uwzględnić więcej szczegółów na temat DI i przenieść na wierzch TLDR. A potem dzieci zaczęły się denerwować, więc nacisnąłem Save. ... Jeśli przypadkowo straciłem istotę tego, co głosowałeś (dla tych, którzy to zrobili), daj mi znać!
svidgen
12

Przeszukałem Google, Google Scholar, ACM i IEEE Oto artykuły, które udało mi się znaleźć:

  • Ramy zależności wtrysku: poprawa testowalności? . Argumentuje, że „testowalność” można zdefiniować jako „niską spójność”. Stwierdza, że ​​DI prowadzi do niższej kohezji, niższa kohezja jest skorelowana z wyższym pokryciem testowym i że wyższy zasięg testowy jest skorelowany z większą liczbą znalezionych błędów. Mówi, że na tej podstawie DI poprawia testowalność.

    Nie podoba mi się to z kilku powodów. Przede wszystkim mówi, że „A jest skorelowane z B, B jest skorelowane z C, więc A powoduje C”, co jest kilkoma krokami w logice, której nie uważam za dobrze poparte przez artykuł. Po drugie, przyznaje, że mierzy tylko „części testowalności” i że „testowalność” ogólnie nie jest czymś łatwym do zdefiniowania. Wreszcie, ich miara testowalności jest zdefiniowana w kategoriach liczby wstrzykniętych zależności!

  • Wpływ wstrzykiwania zależności na łatwość konserwacji . Porównują projekty korzystające z DI z projektami nie wykorzystującymi DI, które znaleźli w SourceForge i sprawdzają, czy istnieją jakiekolwiek różnice w wskaźnikach spójności. Aby zmniejszyć stronniczość, połączyli projekty, aby były jak najbardziej podobne. W końcu zobaczyli sygnały, że projekty z dużą ilością DI były nieco mniej sprzężone niż projekty z niewielką ilością DI. Wydaje się jednak, że nie było znaczącej różnicy w spójności między projektami DI i ich parami innymi niż DI, więc może to być konsekwencja określonych domen. Podają „brak korelacji” jako główny wynik, a „może to trochę pomaga?” jako temat do dalszych badań.

  • Empiryczna ocena wpływu wstrzykiwania zależności na rozwój aplikacji usług sieciowych . Streszczenie tak naprawdę nie wyjaśnia, czego szukają. Odkopałem i przeczytałem przedruk i, o ile mogę stwierdzić, w rzeczywistości dotyczy to tego, jak dobrze zautomatyzowane narzędzia mogą wykrywać usługi. Usługi napisane w stylu DI można łatwiej znaleźć. Cytuje także poprzednie badanie, które wymieniłem jako zapewniające empiryczny dowód, że DI zmniejsza sprzężenie, co jest przeciwieństwem tego, co twierdził ten artykuł.

W przypadku tych trzech artykułów (i Analizy empirycznej nad wykorzystaniem wstrzykiwania zależności w Javie , która dotyczy wyłącznie wykrywania) śledziłem wszystkie cytowane artykuły, z których żaden nie dotyczył określenia skuteczności DI. Biorąc to wszystko pod uwagę, jestem pewien, że nie , nie mamy jeszcze empirycznych dowodów na to, czy DI poprawia jakość oprogramowania.

Hovercouch
źródło
2
To odpowiada bezpośrednio na pytanie. +1
Matthew James Briggs
3
@MatthewJamesBriggs Nie jestem zwycięzcą, ale czy bezpośrednie udzielenie odpowiedzi na pytanie ma znaczenie, jeśli odpowiedź jest myląca lub niepełna?
svidgen
@svidgen Nie widzę, jak odpowiedź jest niepełna. Pytanie brzmiało: „czy mamy empiryczne dowody na to, że DI działa?” a odpowiedź brzmi „nie”. To nie mówi nic o tym, czy to działa, tylko że nie ma na to badań.
Hovercouch
1
Niekompletne i mylące w tym, że twoja odpowiedź ogranicza zakres „dowodów” do „dokumentów, które (sic) byłeś w stanie znaleźć” i zakryło „efektywność” bez poszanowania faktycznych celów DI i które masz w związku z tym stwierdził, że odpowiedź brzmi „nie” bez kwalifikacji ... Argumentowałbym, że jeśli masz zamiar „bezpośrednio” odpowiedzieć na pytanie, jak sugeruje @MatthewJamesBriggs, ciężko spoczywa na tobie, aby kopać głęboko i być w stanie wykazać z dużą pewnością, że odkryłeś wszystkie możliwości ...
svidgen
1
I myślę, że łącząc to z pochopną oceną jednego źródła, który zacytowałeś, mógłbym nawet nazwać tę odpowiedź bardzo mylącą. Ponieważ oprócz wszystkich potencjalnych dowodów, które ignorujesz, bierzesz udokumentowane dowody i natychmiast je dyskontujesz z powodów, które nie są w pełni wyjaśnione. ... Gdybym miał na przykład twierdzić, że „nie ma dowodów na to, że wylądowaliśmy na Księżycu”, ponieważ „jedyny” artykuł, jaki kiedykolwiek czytałem na ten temat, pochodzi z „przestarzałej” wersji podręcznika, której ja nie ufajcie, mam nadzieję, że będziecie sceptycznie nastawieni do moich metod ...
svidgen,