¿Existe evidencia de que el uso de la inyección de dependencia mejora los resultados en la ingeniería de software?

18

A pesar de su popularidad, ¿hay alguna evidencia empírica que muestre que la Inyección de dependencias (y / o el uso de un contenedor DI) ayuda, por ejemplo, a reducir el conteo de errores, mejorar el mantenimiento o aumentar la velocidad de desarrollo en proyectos de software de la vida real?

NMrt
fuente
3
Posible duplicado de la inyección de dependencia: cómo venderlo Y antes de mirar solo en el titular y pensar "hey, esto no es literalmente un engaño" - lea esa otra pregunta y las respuestas, creo que encajan muy bien con esta pregunta aquí.
Doc Brown
55
Acepte el hecho de que muchas prácticas de desarrollo de software profesional no tienen "evidencia científica", sino que se basan en la experiencia práctica. Entonces, incluso si ahora ha empeorado su pregunta solo por tratar de hacerla artísticamente "menos duplicada" que la que he vinculado, la pregunta real que debería haber hecho para obtener las respuestas que realmente desea saber es esa otra pregunta a la que he vinculado . Y, por cierto, ahora parece que está solicitando recursos de terceros, lo que está fuera de tema en este sitio.
Doc Brown
66
Muy pocas técnicas en el desarrollo de software van acompañadas de pruebas científicas, del tipo en el que puede señalar un trabajo de investigación y declarar definitivamente que una técnica es valiosa. En consecuencia, la mayoría de nosotros confiamos en la experiencia y los análisis de costo / beneficio para justificar nuestras decisiones. Usted elige una técnica como la inyección de dependencia porque necesita los beneficios que proporciona y porque esos beneficios superan los costos. Es cierto que ese cálculo siempre es algo subjetivo.
Robert Harvey
1
@DocBrown Honestamente, no veo esto como un duplicado, ni como fuera de tema, yo mismo. El fundamento y la eficacia de una práctica de desarrollo parece muy relevante para SE.SE. Y voy a dar una respuesta. El OP probablemente no le gustará mi respuesta ... pero, creo que vale la pena tener una respuesta objetiva (casi respuesta) a si las TPO y los PM pueden esperar ver que la productividad de sus equipos aumente mágicamente (o que disminuyan sus tasas de error) a medida que tan pronto como alguien grita "inyección de dependencia".
svidgen
3
@gnat Probablemente valga la pena comenzar una meta pregunta distinta para preguntas de "evidencia", que se agregaron al alcance de esa meta respuesta de "recurso fuera del sitio" mucho después de haberla votado. Claro, pedirnos que busquemos estadísticas probablemente no sea útil. Pero, la esencia de la pregunta es perfectamente razonable. Y, para mí, suena a pereza llamarlo rápidamente fuera de tema. Los comentarios aquí específicamente dan la impresión de que somos un grupo de dogmáticos DI que simplemente no pueden defender nuestras prácticas. Bueno podemos. Y deberíamos.
svidgen

Respuestas:

14

TLDR

Los datos empíricos son irrelevantes. Las herramientas y prácticas (como DI) resuelven problemas particulares . Comprenda sus problemas, aprenda a usar las herramientas y se volverá obvio cuando una herramienta sea valiosa, y podrá explicar los resultados de manera mucho más profética que cualquier información empírica generalizada, agregada.


Y ahora, con mucha más verbosidad ...

¿Hay evidencia empírica?

Claro, probablemente. O al menos tal vez. ¿Pero a quién le importa? No es relevante

Un análisis estadístico de costo-beneficio de DI puede ser interesante académicamente, pero no necesariamente predice el éxito individual. Los resultados agregados ocultan los éxitos y fracasos individuales . Y, podría argumentar que los datos con respecto a las prácticas "evangélicas" son particularmente venenosos. ¡Estas disciplinas tienden a atraer tanto fanáticos como tontos, los cuales oscurecen el impacto neto de una implementación "pura", y cualquiera de los dos podría ser!

Entonces, ¿cómo sabemos que la inyección de dependencia es valiosa ?

¡Buena pregunta! GRAN pregunta, de hecho. Y estoy contigo: odio perder el tiempo y el esfuerzo mental en las "mejores prácticas" dogmáticas que nadie puede justificar. Entonces, me alegra que lo hayas preguntado.

Uhh Pero, aquí está el problema embarazoso ... En generales términos, que no sabe. Y, lo que es aún más vergonzoso, es posible que su código no mejore de ninguna manera al introducir DI.


¡JADEAR!

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

...


Entonces, tal vez ahora te estés preguntando ...

¿Por qué debería molestarme en que las cosas no han sido probadas er nuthin '?

En primer lugar, establezcamos todos, en todos los lados del debate. Les puedo asegurar que entre el dogmatismo y el escepticismo se encuentra un hermoso paraíso de razón y sensatez. (Y la publicación excéntrica ocasional de SE.SE.) Y, el POAP puede guiarte allí.

... Con lo que quiero decir, el Principio de Aplicación de Principios :

Los principios, patrones y prácticas no son propósitos finales. Por lo tanto, la buena y adecuada aplicación de cada uno está inspirada y limitada por un propósito superior y más final.

¡Necesitas entender por qué estás haciendo lo que estás haciendo!

(El POAP no está exento del POAP).

(Yo diría, "énfasis mío", pero de todos modos es de mi propio "blog". ¡Así que todo es mío!)

Permítanme reiterar el punto principal: necesita comprender por qué está haciendo lo que está haciendo.

Y tal vez para aclarar, por lo general no tiene sentido tomar un "algo" dado (como la inyección de dependencia), y usarlo sin comprender qué problema resuelve, específicamente para usted.Si comprende sus problemas y cómo funciona el "algo" (como DI), será algo "obvio" cuán útil es el "algo", en gran medida, independientemente de lo que sugieran los datos empíricos, agregados y generalizados.

Si amabilidad del DI o la ONU -helpfulness a que no es obvia - o al menos más allá de sus poderes de razonamiento - que o bien no entiende DI, o no entiende sus propios problemas.


Consideremos una "parábola" del mundo real.

Necesitamos construir una caja. Tenemos madera. Tenemos uñas Y tenemos dos herramientas: un martillo estándar y un destornillador .

Ahora, podemos tener algunos datos empíricos amplios para mostrar que las cajas construidas con destornilladores son cajas significativamente más robustas en general, en comparación con las construidas con martillos. Pero, si intentas atornillar esas uñas, no terminarás con una caja en absoluto. Y, si intentas golpearlos con el destornillador, eventualmente puedes meterlos; pero requerirá mucho más tiempo y esfuerzo, y el resultado final será menos preciso (y robusto) que si hubiera utilizado el martillo.

Y, si alguna vez has visto a alguien usar cualquiera de las herramientas antes, y si entiendes cómo se ve una caja, la decisión es obvia.

¡Telequinesia!

Err ... hmm ...


Sí, entonces, ¿qué problema resuelve la inyección de dependencia?

Funciona para evitar el código rígido, no configurable, que a menudo, por lo tanto, no se puede comprobar .

Para ello, permite invocar código para decidir con qué objetos opera un módulo. Y sé que lo estás pensando, y tienes razón: este ni siquiera es un concepto remotamente nuevo. Los parámetros de método / función han existido desde que sucedió el álgebra.

Comenzamos a evangelizar el paso de parámetros básicos, llamándolo "Inyección de dependencia", una vez que acumulamos y heredamos suficiente código para ver nuestros desequilibrios. Las montañas de código sobre las que estábamos sentados no podían cambiarse, probarse ni reutilizarse fácilmente , simplemente porque las dependencias estaban ocultas.

Por lo tanto, la celosa cruzada por la inyección de dependencia ...

K. Pero, puedo pasar argumentos muy bien. ¿Por qué los marcos ?

Según tengo entendido, los marcos DI resuelven principalmente el problema de la acumulación de repeticiones (debido a DI excesivo, IMO), particularmente cuando hay dependencias "predeterminadas" estándar para todos los módulos que los requieren. Los marcos DI hacen cosas mágicas (¡potencialmente incluso traviesas!) Para deslizar esas dependencias predeterminadas cuando no se pasan explícitamente en el punto de invocación. (¡El mismo efecto que un Localizador de servicios cuando se usa de esta manera, ten en cuenta!)

La inyección de dependencia, como una "disciplina", es realmente difícil de hacer bien. No se trata de usar DI o no; es una cuestión de saber qué dependencias son propensos al cambio o necesidad burla y la inyección de los . Y luego, es cuestión de decidir si la DI encaja mejor que alguna alternativa, como la ubicación del servicio ...

Pero, me animo a Google que , tal vez ver esta respuesta SO , posiblemente hablar con un desarrollador súper experimentado y exitoso en su industria, y después de los ejemplos específicos a CR.SE .

svidgen
fuente
44
¿Has estado oliendo algo del pegamento de @ CandiedOrange? +1 para el Principio de Fines Aplicados.
Robert Harvey
1
@RobertHarvey ¡Ojalá pudiera decir que sabía de qué pegamento estábamos hablando! He tenido una larga venganza contra la ingeniería basada en la fe ... ¿A menos que te refieras a la naturaleza narrativa, posiblemente incluso estrafalaria, de la publicación?
svidgen
2
Nota al margen para los votantes negativos, ¡nada me llena más de confianza en mi decisión de responder una pregunta que los votos bien equilibrados! ... Sin embargo, sería agradable ver tus críticas en los comentarios ...
svidgen
3
@RobertHarvey no estoy seguro de a cuál de mis muchos pegamentos te refieres, pero estoy de acuerdo con cada palabra de esto. Es fácil pensar que un martillo apesta cuando lo usas con tornillos.
candied_orange
Comenzó la edición para incluir más detalles sobre DI específicamente y hacer que el TLDR llegue a la parte superior. Y luego los niños comenzaron a preocuparse, así que presioné Guardar. ... Si perdí inadvertidamente la esencia de lo que votó (para aquellos de ustedes que lo hicieron), ¡háganmelo saber!
svidgen
12

Busqué en Google, Google Scholar, ACM e IEEE. Aquí están los documentos que he podido encontrar:

  • Marcos de inyección de dependencias: ¿una mejora en la capacidad de prueba? . Sostiene que la "capacidad de prueba" se puede definir como "baja cohesión". Establece que DI conduce a una cohesión más baja, la cohesión más baja se correlaciona con una mayor cobertura de prueba, y que una mayor cobertura de prueba se correlaciona con más fallas encontradas. Dice que, en base a esto, DI mejora la capacidad de prueba.

    No me gusta esto por un par de razones. En primer lugar, dice: "A está correlacionado con B, B está correlacionado con C, por lo que A causa C", que es un par de pasos en la lógica que no veo como bien respaldados por el documento. En segundo lugar, admite que solo mide "subpartes de comprobabilidad", y que la "comprobabilidad" en general no es algo fácil de definir. Finalmente, su medida de comprobabilidad se define en términos del número de dependencias inyectadas.

  • Efectos de la inyección de dependencia en la mantenibilidad . Comparan proyectos que usan DI con proyectos que no usan DI que encontraron en SourceForge y ven si hay alguna diferencia en las métricas de cohesión. Para reducir el sesgo, combinaron los proyectos para que fueran lo más similares posible. Finalmente, vieron señales de que los proyectos con mucha DI estaban algo menos acoplados que los proyectos con solo una pequeña DI. Sin embargo, parece que no hubo una diferencia significativa en la cohesión entre los proyectos DI y su par no DI, por lo que podría ser una consecuencia de los dominios específicos. Enumeran "sin correlación" como su resultado principal y el "¿quizás ayuda un poco?" como tema para estudio adicional.

  • Evaluación empírica del impacto de la inyección de dependencia en el desarrollo de aplicaciones de servicios web . El resumen realmente no explica lo que están buscando. Desenterré y leí una preimpresión y, por lo que puedo decir, en realidad se trata de qué tan bien las herramientas automatizadas pueden descubrir los servicios. Los servicios escritos en un estilo DI se descubrieron más fácilmente. Además, cita el estudio anterior que enumeré como que proporciona evidencia empírica de que la DI reduce el acoplamiento, que es lo contrario de lo que afirmaba ese documento.

Para estos tres artículos (y para Un estudio empírico sobre el uso de la inyección de dependencia en Java , que se trata solo de detección), realicé un seguimiento de todos los documentos que los citaron, ninguno de los cuales trataba de determinar la efectividad de la DI. Dado todo esto, confío en decir que no , todavía no tenemos evidencia empírica sobre si DI mejora o no la calidad del software.

Hovercouch
fuente
2
Esto responde la pregunta directamente. +1
Matthew James Briggs
3
@MatthewJamesBriggs No soy el votante negativo, pero, ¿la respuesta a la pregunta directamente importa si la respuesta es engañosa o está incompleta?
svidgen
@svidgen No veo cómo la respuesta es incompleta. La pregunta era "¿tenemos evidencia empírica de que DI funciona?" y la respuesta es no." Eso no dice nada acerca de si funciona o no, solo que no hay investigación al respecto.
Hovercouch
1
Incompleto y engañoso en que su respuesta limita el alcance de la "evidencia" a los "documentos que usted (sic) ha podido encontrar" y ha cubierto sobre "efectividad" sin respetar los propósitos reales de DI, y que usted tiene por lo tanto, concluí que la respuesta es "no" sin calificación ... Yo diría que, si vas a responder "directamente" la pregunta, como @MatthewJamesBriggs sugiere que hiciste, hay una gran responsabilidad sobre ti para profundizar y ser capaz de demostrar con gran certeza que ha explorado todas las avenidas ...
svidgen
1
Y supongo que, cuando se combina eso con su evaluación apresurada de un recurso que hizo citar, podría incluso llamar a esta respuesta muy engañosa. Porque, aparte de toda la evidencia potencial que está ignorando, está tomando evidencia documentada e inmediatamente la descuenta por razones que no se explican completamente. ... Si tuviera que afirmar, por ejemplo, que "no hay evidencia de que aterricemos en la luna" porque el "único" artículo que he leído sobre el asunto fue de una revisión de libro de texto "obsoleto" que no conozco confía, espero que seas escéptico de mis métodos ...
svidgen