Há evidências de que o uso de injeção de dependência melhora os resultados na engenharia de software?


18

Não obstante sua popularidade, há alguma evidência empírica que mostre que a Injeção de Dependência (e / ou o uso de um contêiner de DI) ajuda a, por exemplo, reduzir a contagem de bugs, melhorar a manutenção ou aumentar a velocidade de desenvolvimento em projetos de software da vida real?


3
Possível duplicata da injeção de dependência: como vendê-la E antes de olhar apenas para a manchete e pensar "ei, isso não é literalmente um idiota" - leia essa outra pergunta e as respostas, acho que elas se encaixam muito bem nessa pergunta aqui.
Doc Brown

5
Aceite o fato de que muitas práticas de desenvolvimento profissional de software não têm "evidência científica", elas são baseadas na experiência prática. Portanto, mesmo que você agora tenha piorado sua pergunta apenas por tentar torná-la artificialmente "menos duplicada" do que a que eu vinculei, a verdadeira pergunta que você deveria ter solicitado para obter as respostas que realmente deseja saber é a outra pergunta à qual vinculei . E, a propósito, agora parece que você está solicitando recursos de terceiros, o que está fora de tópico neste site.
Doc Brown

6
Muito poucas técnicas de desenvolvimento de software são acompanhadas de provas científicas, do tipo em que você pode apontar para um trabalho de pesquisa e declarar definitivamente que uma técnica é valiosa. Consequentemente, a maioria de nós confia na experiência e nas análises de custo / benefício para justificar nossas decisões. Você escolhe uma técnica como a injeção de dependência porque precisa dos benefícios que ela oferece e porque esses benefícios superam os custos. É certo que esse cálculo é sempre um pouco subjetivo.
Robert Harvey

1
@DocBrown Honestamente, eu não vejo isso como duplicado, nem como algo fora de tópico. A lógica e a eficácia de uma prática de desenvolvimento parecem muito relevantes para a SE.SE. E eu vou dar uma resposta. O OP provavelmente não vai gostar da minha resposta ... mas acho que vale a pena ter uma resposta objetiva (quase resposta) para saber se os TPOs e PMs podem esperar ver a produtividade de suas equipes subir magicamente (ou as taxas de erros caírem) conforme assim que alguém grita "injeção de dependência".
Svidgen

3
@gnat, provavelmente vale a pena iniciar uma meta questão distinta para perguntas de "evidência", que foram adicionadas ao escopo dessa meta resposta "recurso fora do site" muito tempo depois de a ter votado positivamente. Certamente, pedir para procurar estatísticas provavelmente não é útil. Mas, a essência da questão é perfeitamente razoável. E, para mim, parece preguiça encerrar tão rapidamente o assunto. Os comentários aqui dão especificamente a impressão de que somos um monte de dogmáticos de DI que simplesmente não podem defender nossas práticas. Bem, nós podemos. E nós deveríamos.
Svidgen

Respostas:


14

TLDR

Os dados empíricos são irrelevantes. Ferramentas e práticas (como DI) resolvem problemas particulares . Entenda seus problemas, aprenda a usar as ferramentas e ficará óbvio quando uma ferramenta é valiosa - e você poderá explicar os resultados de maneira muito mais profética do que qualquer dado empírico generalizado, agregado.


E agora, com muito mais verbosidade ...

Existe evidência empírica?

Claro, provavelmente. Ou pelo menos talvez. Mas quem se importa? Não é relevante.

Uma análise estatística de custo-benefício da DI pode ser interessante academicamente, mas não necessariamente prevê o sucesso individual. Os resultados agregados ocultam sucessos e falhas individuais . E, eu poderia argumentar que dados sobre práticas "evangélicas" são particularmente venenosas. Essas disciplinas tendem a atrair fanáticos e tolos, os quais obscurecem o impacto líquido de uma implementação "pura" e qualquer um dos quais você poderia ser!

Então, como sabemos que a injeção de dependência é valiosa ?

Boa pergunta! Ótima pergunta, de fato. E estou com você - odeio perder tempo e esforço mental com as "melhores práticas" dogmáticas que ninguém pode justificar. Então, estou feliz que você perguntou.

Uhh Mas, aqui está o problema embaraçoso ... Em termos gerais , você não sabe. E, ainda mais embaraçoso, seu código pode não melhorar de forma alguma ao introduzir o DI.


SUSPIRO!

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

...


Então, talvez agora você esteja se perguntando ...

Por que eu deveria me preocupar com coisas que não foram provadas?

Primeiro de tudo, vamos todos - em todos os lados do debate - nos acalmar. Posso assegurar-lhe que entre o dogmatismo e o ceticismo existe um belo paraíso da razão e da empatia. (E o ocasional excêntrico SE.SE post.) E o POAP pode levá-lo até lá.

... Com o que quero dizer, o Princípio de Aplicação de Princípios :

Princípios, padrões e práticas não são propósitos finais. A boa e adequada aplicação de cada um é, portanto, inspirada e restringida por um propósito superior e mais final.

Você precisa entender por que está fazendo o que está fazendo!

(O POAP não está isento do POAP.)

(Eu diria "ênfase minha", mas é do meu próprio "blog" de qualquer maneira. Portanto, é todo meu!)

Deixe-me reiterar o ponto principal: você precisa entender por que está fazendo o que está fazendo.

E, talvez, para esclarecer, geralmente não faz sentido usar "algo" (como injeção de dependência) e usá-lo sem entender o problema que ele resolve - especificamente para você. Se você entender seus problemas e como o "algo" (como DI) funciona, será um pouco "óbvio" o quão útil é o "algo", muito independentemente do que os dados empíricos generalizados, agregados e sugeridos.

Se a ajuda ou a falta de ajuda de DI para você não é óbvia - ou pelo menos além de seus poderes de raciocínio - você não entende DI, ou não entende seus próprios problemas.


Vamos considerar uma "parábola" do mundo real.

Precisamos construir uma caixa. Nós temos madeira. Temos unhas. E temos duas ferramentas: um martelo de garra padrão e uma chave de fenda .

Agora, podemos ter alguns dados empíricos amplos para mostrar que as caixas construídas com chaves de fenda são caixas significativamente mais robustas em geral, em comparação com aquelas construídas com martelos. Mas, se você tentar aparafusar essas unhas, não terá uma caixa. E, se você tentar encaixá-los com a chave de fenda, poderá obtê-los; mas, exigirá muito mais tempo e esforço, e o resultado final será menos preciso (e robusto) do que você simplesmente usou o martelo.

E, se você já viu alguém usar uma dessas ferramentas antes e se entende como é uma caixa, a decisão é óbvia.

Telecinese!

Err ... hmm ...


Sim, então, que problema a Dependency Injection resolve?

Ele trabalha para evitar códigos rígidos e não configuráveis, que geralmente são, portanto, não testáveis .

Ele faz isso permitindo que o código de chamada decida com quais objetos um módulo opera. E sei que você está pensando e está certo: esse nem é um conceito remotamente novo. Os parâmetros de método / função existem desde que a álgebra aconteceu.

Começamos a evangelizar a passagem básica de parâmetros, chamando-a de "Injeção de Dependência", uma vez que acumulamos e herdamos código suficiente para ver nossos desequilíbrios. As montanhas de código em que estávamos sentados não podiam ser facilmente alteradas, testadas ou até reutilizadas , simplesmente porque as dependências estavam ocultas.

Portanto, a cruzada zelosa pela injeção de dependência ...

K. Mas posso passar argumentos muito bem. Por que os frameworks ?

Pelo que entendi, as estruturas de DI resolvem principalmente o problema de acúmulo de clichê (devido a DI, IMO excessivamente zeloso) - principalmente quando existem dependências "padrão" padrão para todos os módulos que precisam deles. As estruturas de DI fazem coisas mágicas (potencialmente até impertinentes!) Para inserir essas dependências padrão quando não são explicitamente transmitidas no ponto de invocação. (Mesmo efeito que um localizador de serviço quando usado dessa maneira, lembre-se!)

A injeção de dependência, como uma "disciplina", é realmente muito difícil de acertar. Não é uma questão de usar DI ou não; é uma questão de saber quais dependências provavelmente mudarão ou precisarão zombar e injetar essas dependências . E então, é questão de decidir se o DI se encaixa melhor do que alguma alternativa, como Localização do Serviço ...

Mas, eu encorajá-lo a Google-lo , talvez ver esta resposta SO , possivelmente falar com um desenvolvedor super-experiente e bem sucedido em sua indústria, e os exemplos posto específico para CR.SE .


4
Você já cheirou a cola de @ CandiedOrange? +1 para o Princípio das finalidades aplicadas.
Robert Harvey

1
@RobertHarvey Gostaria de poder dizer que cola nova de que estávamos falando! Eu tive uma vingança de longa data contra a engenharia baseada na fé ... A menos que você esteja se referindo à narrativa - possivelmente até à doideira - natureza do post?
Svidgen

2
Nota lateral para os que recusam, nada me enche mais de confiança na minha decisão de responder a uma pergunta do que votos equilibrados para cima e para baixo! ... Seria bom ver suas críticas nos comentários ...
svidgen

3
@RobertHarvey não tenho certeza a qual das minhas muitas colas você está se referindo, mas eu acho que estou concordando com cada palavra disso. É fácil pensar que um martelo é péssimo quando você o usa com parafusos.
Candied_orange

Iniciou a edição para incluir mais detalhes sobre o DI especificamente e colocar o TLDR no topo da bolha. E então as crianças começaram a se agitar, então eu apertei Save. ... Se eu inadvertidamente perdi a essência do que você votou (para aqueles que fizeram), por favor me avise!
svidgen

12

Pesquisei no Google, Google Scholar, ACM e IEEE. Aqui estão os artigos que consegui encontrar:

  • Estruturas de injeção de dependência: uma melhoria na testabilidade? . Argumenta que "testabilidade" pode ser definida como "baixa coesão". Ele afirma que o DI leva a menor coesão, menor coesão está correlacionada com maior cobertura de teste e maior cobertura de teste está correlacionada com mais falhas encontradas. Diz que, com base nisso, o DI melhora a testabilidade.

    Eu não gosto disso por alguns motivos. Antes de tudo, está dizendo "A está correlacionado com B, B está correlacionado com C, então A causa C", que é um par de etapas da lógica que não considero bem suportadas pelo artigo. Segundo, admite que está apenas medindo "subpartes de testabilidade", e que 'testabilidade' em geral não é algo facilmente definido. Finalmente, sua medida de testabilidade é definida em termos do número de dependências injetadas!

  • Efeitos da injeção de dependência na capacidade de manutenção . Eles comparam projetos usando DI a projetos que não usam DI encontrados no SourceForge e ver se há alguma diferença nas métricas de coesão. Para reduzir o viés, eles combinaram os projetos para serem o mais semelhante possível. Por fim, eles viram sinais de que projetos com muito DI estavam um pouco menos acoplados do que projetos com apenas um pouco de DI. No entanto, parece que não houve diferença significativa na coesão entre os projetos de DI e seu par não-DI, portanto, isso pode ser uma consequência de domínios específicos. Eles listam "nenhuma correlação" como resultado primário e o "talvez ajude um pouco?" como um tópico para um estudo mais aprofundado.

  • Avaliação empírica do impacto da injeção de dependência no desenvolvimento de aplicativos de serviço da web . O resumo não explica realmente o que eles estão procurando. Desenterrei e li uma pré-impressão e, até onde posso dizer, é realmente sobre o quão bem as ferramentas automatizadas podem descobrir serviços. Os serviços gravados no estilo DI foram descobertos com mais facilidade. Além disso, ele cita o estudo anterior que listei como fornecendo evidências empíricas de que o DI reduz o acoplamento, o que é o oposto do que esse artigo afirmava.

Para esses três artigos (e para Um estudo empírico sobre o uso de injeção de dependência em Java , que é apenas sobre detecção), acompanhei todos os artigos que os citaram, nenhum deles sobre a determinação da eficácia da DI. Diante de tudo isso, estou confiante em dizer que não , ainda não temos evidências empíricas sobre se a DI melhora ou não a qualidade do software.


2
Isso responde diretamente à pergunta. +1
Matthew James Briggs

3
@MatthewJamesBriggs Eu não sou o derrotador, mas responder diretamente à pergunta importa se a resposta é enganosa ou incompleta ???
Svidgen

@svidgen Não vejo como a resposta está incompleta. A questão era "temos evidências empíricas de que o DI funciona?" E a resposta é não." Isso não diz nada sobre se funciona ou não, apenas que não há pesquisas.
Hovercouch

1
Incompleto e enganoso, sua resposta limita o escopo da "evidência" a "documentos que você (sic) conseguiu encontrar" e cobriu a "eficácia" sem respeitar os propósitos reais da DI e que você tem portanto concluímos que a resposta é "não" sem qualificação ... Eu diria que, se você responder "diretamente" à pergunta, como @MatthewJamesBriggs sugere que você fez, há um ônus pesado em você se aprofundar e ser capaz de demonstrar com alta certeza que você explorou todas as avenidas ...
svidgen

1
E eu acho que, quando combina isso com a sua avaliação apressada de um recurso que você se citar, eu poderia até chamar esta resposta muito enganosa. Porque, além de todas as evidências em potencial que você está ignorando, você está pegando evidências documentadas e descartando-as imediatamente por motivos não totalmente explicados. ... Se eu afirmasse, por exemplo, que "não há evidências de que pousamos na lua" porque o "único" artigo que eu já li sobre o assunto foi de uma revisão "obsoleta" de um livro didático que não confiança, espero que você seja cético em relação aos meus métodos ...
svidgen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.