의존성 주입을 사용하면 소프트웨어 엔지니어링의 결과가 향상된다는 증거가 있습니까?

인기에도 불구하고 Dependency Injection (및 / 또는 DI 컨테이너 사용)이 실제 소프트웨어 프로젝트에서 버그 수 감소, 유지 관리 성 향상 또는 개발 속도 향상에 도움이된다는 것을 보여주는 경험적 증거가 있습니까?

TLDR

경험적 데이터는 관련이 없습니다. DI와 같은 도구 및 사례는 특정 문제를 해결합니다. 문제를 이해하고 도구를 사용하는 방법을 배우면 도구가 가치가있을 때 분명해 지며 결과를 일반화되고 집계 된 경험적 데이터보다 훨씬 더 예언 적으로 설명 할 수 있습니다.

그리고 지금, 훨씬 더 장황한 ...

경험적 증거가 있습니까?

아마 요 아니면 적어도 어쩌면 그러나 누가 신경 쓰나요? 관련이 없습니다.

DI의 통계적 비용-이익 분석은 학문적으로 흥미로울 수 있지만 반드시 개별적인 성공을 예측하는 것은 아닙니다. 집계 된 결과는 개별 성공 및 실패를 숨 깁니다 . 그리고 나는 "복음 주의적"관행에 관한 데이터가 특히 유독하다고 주장 할 수 있습니다. 이러한 원칙은 열심과 바보 모두를 끌어들이는 경향이 있으며, 둘 다 "순수한"구현의 순 영향을 모호하게하며, 둘 중 하나 일 수 있습니다!

그렇다면 Dependency Injection이 가치가 있다는 것을 어떻게 알 수 있습니까?

좋은 질문! 사실 큰 질문입니다. 그리고 나는 당신과 함께 있습니다-나는 아무도 정당화 할 수없는 교의 "모범 사례"에 시간과 정신적 노력을 낭비하는 것을 싫어합니다. 그래서 물어봐서 기뻐요.

어. 그러나 여기 당황스러운 문제가 있습니다 ... 일반적 으로 , 당신 은 몰라요. 더욱 부끄럽게도 DI를 도입해도 코드가 실제로 나아지지 않을 수 있습니다.

GASP!

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

...

아마도 지금 궁금해 할 것입니다 ...

왜 내가 '너덜 너덜 한 것으로 증명되지 않았다'고 귀찮게해야합니까!?

우선, 토론의 모든 측면에서, 그냥 해결하자. 독단주의와 회의론 사이에는 이성과 수준의 향연의 아름다운 천국이 있습니다. (그리고 가끔 편심 SE.SE 게시물.) 그리고 POAP가 당신을 이끌 수 있습니다.

... 즉, 원칙을 적용하는 원리 :

원칙, 패턴 및 관행은 최종 목적이 아닙니다. 그러므로 각각의 훌륭하고 적절한 적용은 우수하고보다 최종적인 목적에 의해 영감을 받고 제한 됩니다.

왜하고있는 일을하고 있는지 이해해야합니다!

(POAP는 POAP에서 면제되지 않습니다.)

^{(나는 "강조 광산"이라고 말하지만 어쨌든 내 자신의 "블로그"에서 온 것입니다. 그래서 그것은 모두 내 것입니다!)}

여기서 요점을 되풀이하겠습니다. 왜하고있는 일을하는 이유를 이해해야합니다.

그리고 분명히 말하면, 일반적으로 주어진 "무언가"(예 : 의존성 주입)를 가져 와서 어떤 문제가 해결되는지 이해하지 않고 사용하는 것이 합리적이지 않습니다 . 문제와 "무언가"(DI와 같은)가 어떻게 작동하는지 이해한다면, 일반화되고 집계 된 경험적 데이터가 제안하는 것과 무관하게 "무언가"가 얼마나 도움이되는지에 대해서는 다소 "분명한"것입니다.

DI의 도움이되는 것 또는 경우 취소 당신의 추론 능력 이상 또는 적어도 - - 당신에게 -helpfulness이 명확하지 않다 당신도 DI를 이해하지 못하는, 또는 당신은 당신의 자신의 문제를 이해하지 않습니다.

실제 "비유"를 생각해 봅시다.

상자를 만들어야합니다. 우리는 나무가 있습니다. 손톱이 있습니다. 그리고 표준 클로 망치 와 드라이버 두 가지 도구가 있습니다 .

이제 우리는 스크류 드라이버로 구성된 박스가 망치로 구성된 박스에 비해 전체적으로 상당히 견고한 박스임을 보여주기 위해 광범위한 경험적 데이터를 가질 수 있습니다. 그러나 그 손톱을 조이려고하면 상자가 전혀 없습니다. 그리고 스크루 드라이버로 두들겨 넣으려고하면 결국 들어올 수 있습니다. 그러나 훨씬 더 많은 시간과 노력이 필요하며 최종 결과는 단순히 망치를 사용한 것보다 덜 정확하고 강력합니다.

그리고 누군가가 이전에 어느 툴을 사용하는지 보았고 상자 모양을 이해한다면 결정이 분명합니다.

격동!

어 ... 흠 ...

그래, 의존성 주입은 어떤 문제를 해결합니까?

이 코드는 구성 할 수없는 엄격하고 구성 할 수없는 코드를 방지하기 위해 작동하므로 종종 테스트 할 수 없습니다 .

코드를 호출 하여 모듈이 작동하는 오브젝트를 결정하도록 허용 함으로써이를 수행 합니다. 그리고 나는 당신이 그것을 생각하고 있고 당신이 옳다는 것을 알고 있습니다. 이것은 원격으로 새로운 개념조차 아닙니다. 대수 발생 이후 방법 / 기능 매개 변수가 존재합니다.

우리는 불균형을보기에 충분한 코드를 모아서 상속하면 기본 매개 변수 전달을 시작하여 "종속성 주입"이라고 부릅니다. 의존성이 숨겨져 있기 때문에 우리가 앉아있는 코드의 산은 쉽게 변경, 테스트 또는 재사용 할 수 없었 습니다.

따라서 의존성 주입을위한 열성적인 성전은 ...

K. 그러나 나는 논쟁을 잘 전달할 수 있습니다. 왜 프레임 워크 입니까?

내가 이해하는 바와 같이, DI 프레임 워크는 주로 보일러 플레이트 빌드 업 (과도한 DI, IMO로 인한) 문제를 해결합니다. 특히 필요한 모든 모듈에 표준 "기본"종속성이있는 경우에 특히 그렇습니다. DI 프레임 워크는 호출 시점에서 명시 적으로 전달되지 않을 때 이러한 기본 종속성을 제거하기 위해 마법적인 (잠재적으로는 못된!) 작업을 수행합니다. ( 이러한 방식으로 사용될 때 서비스 로케이터 와 같은 효과가 있습니다.)

"수양"으로서의 의존성 주입은 실제로 제대로 이해하기가 어렵습니다. DI 사용 여부는 중요하지 않습니다. 어떤 종속성이 변경 될 가능성이 있는지 또는 조롱하고 주입해야 하는지를 알아야 합니다 . 그런 다음 DI가 서비스 위치와 같은 다른 대안보다 더 적합한 지 결정하는 것이 중요합니다 ...

그러나 Google에 권유 하고이 SO 답변을 보고 업계에서 경험이 풍부하고 성공적인 개발자와 이야기하고 CR.SE에 구체적인 예를 게시하십시오 .

Google, Google Scholar, ACM 및 IEEE를 검색했습니다. 내가 찾은 논문은 다음과 같습니다.

• 의존성 주입 프레임 워크 : 테스트 성 향상? . 그것은 "시험 성"이 "낮은 응집력"으로 정의 될 수 있다고 주장한다. DI는 응집력을 낮추고 응집력이 낮 으면 더 높은 시험 범위와 상관 관계가 있으며 시험 범위가 높을수록 더 많은 결함이 발견된다고 말합니다. 이를 바탕으로 DI는 테스트 성을 향상시킵니다.

  나는 두 가지 이유로 이것을 좋아하지 않습니다. 우선, "A는 B와 상관 관계가 있고, B는 C와 상관 관계가 있으므로 A는 C를 유발합니다"라는 말이 있습니다. 이것은 논문에서 잘 뒷받침되지 않는 논리의 두 단계입니다. 둘째, 그것은 단지 "테스트 가능성의 서브 파트"만을 측정하고 있으며 일반적으로 '테스트 가능성'은 쉽게 정의 할 수있는 것이 아니라는 것을 인정합니다. 마지막으로, 테스트 가능성의 측정 값은 주입 된 종속성의 수로 정의됩니다!

• 의존성 주입이 유지 보수성에 미치는 영향 . DI를 사용하는 프로젝트를 SourceForge에서 찾은 DI를 사용하지 않는 프로젝트와 비교하고 응집성 메트릭에 차이가 있는지 확인합니다. 편견을 줄이기 위해 프로젝트를 가능한 한 유사하게 만들었습니다. 궁극적으로, 그들은 DI가 많은 프로젝트가 DI가 적은 프로젝트보다 다소 덜 연관되어 있다는 신호를 보았습니다. 그러나 DI 프로젝트와 비 DI 쌍 사이의 응집력에는 큰 차이가 없었으므로 특정 도메인의 결과 일 수 있습니다. 그들은 "상관 관계 없음"을 주요 결과로 나열하고 "약간 도움이 될까요?" 추가 연구를위한 주제로

• 웹 서비스 응용 프로그램 개발에 대한 종속성 주입의 영향을 경험적으로 평가합니다 . 초록은 그들이 무엇을 찾고 있는지 실제로 설명하지 않습니다. 나는 사전 인쇄를 발굴하고 읽었으며 실제로 자동화 된 툴링이 서비스를 얼마나 잘 발견 할 수 있는지에 대해 알 수 있습니다. DI 스타일로 작성된 서비스가 더 쉽게 발견되었습니다. 또한, DI가 커플 링을 감소 시킨다는 경험적 증거를 제공하는 것으로 열거 된 이전 연구를 인용했는데, 이는 논문이 주장한 것과 반대입니다.

이 세 가지 논문 (그리고 Java에 대한 의존성 주입 사용에 대한 실증적 연구 , 탐지에 관한 것임)에 대해, 나는 그것을 인용 한 모든 논문에 대해 후속 조치를 취했으며, 그 중 어느 것도 DI의 효과를 결정하는 것이 아닙니다. 이 모든 것을 감안할 때 , DI가 소프트웨어 품질을 향상시키는 지 여부에 대한 경험적 증거는 아직 없다고 확신 합니다.