나는 의존성 주입 (DI) 및 자동화 된 테스트 의 큰 팬이라는 것을 알게되었습니다 . 나는 하루 종일 그것에 대해 이야기 할 수 있습니다.

배경

최근에 우리 팀은이 큰 프로젝트를 처음부터 새로 만들었습니다. 복잡한 비즈니스 요구 사항이있는 전략적 응용 프로그램입니다. 물론, 나는 그것이 깨끗하고 깨끗하기를 원했습니다. DI를 사용하고 싶었습니다.

저항

문제는 우리 팀에 있었고 DI는 금기입니다. 그것은 몇 번 제기되었지만 신들은 승인하지 않았습니다. 그러나 그것은 나를 낙담시키지 않았습니다.

나의 움직임

이상하게 들릴 수 있지만 타사 라이브러리는 일반적으로 건축가 팀에서 승인하지 않습니다 ( " 단 , 손가락을 자르지 않도록 Unity , Ninject , NHibernate , Moq 또는 NUnit에 대해 이야기해서는 안됩니다 "). 그래서 기존의 DI 컨테이너를 사용하는 대신 매우 간단한 컨테이너를 작성했습니다. 기본적으로 시작에 대한 모든 종속성을 연결하고 종속성 (생성자 / 속성)을 주입하고 웹 요청 끝에 일회용 객체를 배치합니다. 그것은 매우 가볍고 우리가 필요로하는 것을했습니다. 그런 다음 검토를 요청했습니다.

응답

글쎄요. 나는 강한 저항에 부딪쳤다. 주요 논쟁은 "이 복잡한 계층을 이미 복잡한 프로젝트에 추가 할 필요는 없다"는 것이었다. 또한 "다른 컴포넌트 구현을 연결하는 것과는 다릅니다". 그리고 "가능한 한 모든 것을 하나의 어셈블리에 넣는 것만으로 간단하게 유지하고 싶습니다. DI는 이점이없는 불필요한 복잡성입니다."

마지막으로, 내 질문

내 상황을 어떻게 처리하겠습니까? 저는 아이디어를 잘 표현하지 못하며 사람들이 자신의 주장을 어떻게 표현할 것인지 알고 싶습니다.

물론, 나는 나처럼 DI를 선호한다고 가정합니다. 동의하지 않으면 동전의 다른 쪽을 볼 수 있도록 이유를 말하십시오. 동의하지 않는 사람의 관점을 보는 것이 정말 흥미로울 것입니다.

최신 정보

모든 사람의 답변에 감사드립니다. 그것은 실제로 사물을 원근법에 넣습니다. 당신에게 피드백을 줄 다른 눈을 가지고 있으면 충분합니다 .15는 정말 굉장합니다! 이것은 정말 훌륭한 답변이며 다른 측면에서 문제를 볼 수 있도록 도와 주지만 한 가지 답변 만 선택할 수 있으므로 가장 인기있는 답변을 선택합니다. 시간을내어 답변 해 주셔서 감사합니다.

DI를 구현하기에 가장 좋은시기는 아니라고 판단했으며 아직 준비가되지 않았습니다. 대신, 나는 디자인을 테스트 할 수있게 만들고 자동 단위 테스트를 제시하기 위해 노력할 것이다. 필자는 테스트 작성이 추가 오버 헤드이며 추가 오버 헤드가 가치가 없다고 결정되면 개인적으로 디자인을 테스트 할 수 있기 때문에 여전히 승리 상황으로 간주합니다. 그리고 만약 테스트 나 DI가 미래에 선택된다면, 디자인은 쉽게 처리 할 수 ​​있습니다.

반론의 몇 가지를 취하는 것 :

"우리는 가능한 한 모든 것을 하나의 어셈블리에 넣는 것만으로 간단하게 유지하려고합니다. DI는 이점이없는 불필요한 복잡성입니다."

"우리는 다른 컴포넌트 구현을 연결하는 것을 좋아하지 않습니다".

원하는 것은 시스템을 테스트 할 수있는 것입니다. 쉽게 테스트 가능하려면 프로젝트 (데이터베이스, 통신 등)의 다양한 계층을 조롱보고 할이 경우 당신이 필요 합니다 구성 요소의 다른 구현에 연결된다.

제공하는 테스트 혜택에 대해 DI를 판매하십시오. 프로젝트가 복잡한 경우에는 우수하고 견고한 단위 테스트가 필요합니다.

또 다른 이점은 인터페이스로 코딩 할 때 구성 요소 중 하나의 더 나은 구현 (빠르고 적은 메모리 부족 등)을 구현할 경우 DI를 사용하면 이전 구현을 교체하기가 훨씬 쉽다는 것입니다. 새로운.

여기서 말하는 것은 DI를 위해 DI를 주장하는 대신 DI가 가져 오는 이점을 해결해야한다는 것입니다. 사람들이 진술에 동의하도록함으로써 :

"X, Y 및 Z가 필요합니다"

그런 다음 문제를 이동하십시오. DI가이 진술에 대한 답변인지 확인해야합니다. 그렇게함으로써 동료들은 자신에게 부과 된 느낌보다 솔루션을 소유하게됩니다.

당신이 쓰고있는 것에서 DI 자체는 금기가 아니지만 DI 컨테이너의 사용은 다릅니다. 예를 들어 생성자에 의해 전달되어야하는 다른 구성 요소를 얻는 독립적 인 구성 요소를 작성하면 팀에 아무런 문제가 없을 것입니다. "DI"라고 부르지 마십시오.

이러한 구성 요소는 DI 컨테이너를 사용하지 않는 것이 지루하다고 생각할 수 있지만 옳습니다. 그러나 팀이 스스로 알아낼 수있는 시간을주십시오.

당신이 요청한 이후로, 나는 당신 팀의 DI를 반대 할 것입니다.

의존성 주입에 대한 사례

내가 "에너지 절약"이라는 물리학의 규칙과 유사한 규칙 인 "복잡성 보존"이라고합니다. 그것은 엔지니어링의 양이 문제에 대한 최적의 솔루션의 총 복잡성을 줄일 수 없다고 말하며, 그 복잡성을 주변으로 옮기기 만하면됩니다. 애플의 제품은 마이크로 소프트보다 덜 복잡하지 않고 단순히 사용자 공간에서 엔지니어링 공간으로 복잡성을 이동시킨다. (하지만 결함이있는 유추입니다. 에너지를 만들 수는 없지만 엔지니어는 매번 복잡성을 만드는 습관이 있습니다. 실제로 많은 프로그래머가 복잡성을 더하고 마술을 사용하는 것을 좋아 합니다이는 프로그래머가 완전히 이해하지 못하는 정의상의 복잡성입니다. 일반적으로 복잡성을 줄이는 것처럼 보이는 것은 복잡성을 다른 곳, 일반적으로 라이브러리로 옮기는 것입니다.

마찬가지로 DI는 클라이언트 개체를 서버 개체와 연결하는 복잡성을 줄이지 않습니다. 그것이하는 일은 Java에서 가져 와서 XML로 옮기는 것입니다. 그것은 모든 것을 하나의 XML 파일로 중앙 집중화하여 진행중인 모든 것을 쉽게 볼 수 있고 코드를 다시 컴파일하지 않고 변경 할 수있는 곳에서 좋습니다. 반면에 XML 파일은 Java가 아니므로 Java 툴링에 사용할 수 없기 때문에 좋지 않습니다. 디버거에서 디버깅 할 수 없으며 정적 분석을 사용하여 호출 계층을 추적 할 수 없습니다. 특히, DI 프레임 워크의 버그는 감지, 식별 및 수정이 매우 어렵습니다.

따라서 DI를 사용할 때 프로그램이 올바른지 증명하기가 훨씬 어렵습니다. 많은 사람들이 DI를 사용하는 프로그램은 테스트 하기가 더 쉽다고 주장 하지만 프로그램 테스트는 버그가 없다는 것을 증명할 수 없습니다 . (연계 된 논문은 약 40 년이되었으며, 일부 참고 문헌이 있고 일부 오래된 관행을 인용하지만, 많은 기본 진술은 여전히 ​​유효합니다. 특히 P <= p ^ n, 여기서 P 시스템에 버그가 없을 확률, p는 시스템 구성 요소에 버그가 없을 확률, n은 구성 요소의 수입니다. 물론이 방정식은 지나치게 단순화되었지만 중요한 사실을 가리 킵니다.) Facebook IPO 중 NASDAQ 충돌이 최근의 예입니다.그들은 코드를 테스트하는 데 1,000 시간을 소비 했지만 여전히 충돌을 일으킨 버그를 발견하지 않았다고 주장했다 . 1,000 시간은 1 년 반이므로 테스트를 밟는 것과 같지 않습니다.

사실, 코드를 공식적으로 증명하는 작업을 수행하는 사람은 거의 없습니다 (완전히 완료하지는 못함). 그러나 증거에 대한 약한 시도조차도 버그를 찾기위한 대부분의 테스트 체제를 능가합니다. L4.verified 와 같은 강력한 증거 시도 는 테스터가 이미 버그의 정확한 특성을 이미 알고 있지 않은 한 테스트하지 않았거나 발견하지 못한 많은 양의 버그를 발견합니다. 검사로 코드를 확인하기 어렵게 만드는 것은 테스트 능력이 향상 되더라도 버그가 발견 될 가능성을 줄이는 것으로 볼 수 있습니다 .

또한 테스트에는 DI가 필요하지 않습니다 . 대체 테스트 버전이 아닌 시스템의 실제 소프트웨어에 대해 시스템을 테스트하는 것을 선호하기 때문에 그 용도로는 거의 사용하지 않습니다. 테스트에서 변경 한 모든 내용은 프로그램을 프로덕션 환경이 아닌 테스트 환경의 리소스로 보내는 속성 파일에 저장됩니다. 프로덕션 데이터베이스 문제를 추적 할 수 있기 때문에 모의 데이터베이스를 코딩하는 데 시간을 소비하는 것보다 프로덕션 데이터베이스의 사본으로 테스트 데이터베이스 서버를 설정하는 데 시간이 많이 걸립니다. 문자 인코딩 문제는 하나의 예일뿐입니다. ) 및 시스템 통합 버그 및 나머지 코드의 버그.

의존성 주입은 의존성 반전에도 필요하지 않습니다 . 정적 팩토리 메소드를 쉽게 사용하여 종속성 반전을 구현할 수 있습니다. 그것은 실제로 1990 년대에 어떻게 이루어 졌는가입니다.

사실, 10 년 동안 DI를 사용해 왔지만 다른 타사 라이브러리를 사용하도록 타사 라이브러리를 구성 할 수 있다는 것이 설득력있는 유일한 장점입니다 (예 : Spring에서 최대 절전 모드를 사용하도록 설정하고 Log4J를 사용하도록 설정) ) 및 프록시를 통한 IoC 활성화 타사 라이브러리를 사용하지 않고 IoC를 사용하지 않는 경우에는 그다지 중요하지 않으며 실제로 부당한 복잡성을 가중시킵니다.

동료 직원이 귀하의 질문에서 말한 것을 고려할 때 귀하가 가진 문제는 기술적이 아니라 정치적인 것입니다. 명심해야 할 두 가지 진언이 있습니다.

• "항상 사람들 문제입니다"
• " 변화 가 무섭다"

확실히, 당신은 확실한 기술적 이유와 이점으로 많은 반론을 제기 할 수 있지만, 그것은 회사의 다른 사람들과 나쁜 상황에 처하게 할 것입니다. 그들은 이미 원하지 않는 입장을 가지고 있습니다 (지금 상황이 편안해지기 때문에). 따라서 동료 직원과 지속적으로 관계를 유지하면 동료 동료와의 관계가 손상 될 수도 있습니다. 그것이 나에게 일어 났고 결국 몇 년 전에 해고 당했기 때문에 이것을 믿어 라. 이것은 당신이 들어가고 싶지 않은 상황입니다.

문제는 사람들이 현재의 업무 방식 을 변경 하기 전에 어느 정도 신뢰를 얻어야한다는 것입니다 . 건축 가나 기술 책임자의 역할을 맡는 등 신뢰를 많이 받거나 이런 종류의 일을 결정할 수 없다면, 동료를 돌이킬 수있는 일은 거의 없습니다. 회사 문화를 바꾸려면 신뢰를 얻기 위해 설득력과 노력을 기울이는 데 많은 시간이 걸릴 것입니다. 우리는 몇 달 또는 몇 년의 기간에 대해 이야기하고 있습니다.

현재 회사 문화가 당신과 함께 일하고 있지 않다는 것을 알게되면 적어도 다음 직장 인터뷰에서 물어볼 다른 것을 알고 있습니다. ;-)

DI를 사용하지 마십시오. 잊어 버려.

특정 종속성을 "만들거나"찾아서 객체에 전달 하는 GoF 팩토리 패턴 의 구현을 작성하십시오. 그러나 DI라고 부르지 말고 복잡한 일반 프레임 워크를 작성하지 마십시오. 간단하고 관련성을 유지하십시오. DI 로의 전환이 가능하도록 종속성과 클래스가 올바른지 확인하십시오. 그러나 공장을 마스터로 유지하고 범위를 극도로 제한하십시오.

시간이 지나면 언젠가 DI로 전환되기를 바랍니다. 리드는 제 시간에 결론에 도달하도록하고 푸시하지 마십시오. 그것에 도달하지 않더라도 최소한 코드는 DI의 장점 중 일부 (예 : 단위 테스트 가능 코드)를 갖습니다.

개체를 단위 테스트하고 조롱하기 위해 DI를 극도로 끌어 올린 프로젝트를 보았습니다. DI 구성 자체가 프로그래밍 코드가되어 실제 코드처럼 시스템을 실행하는 데 필요한 구성이 많았습니다.

테스트 할 수없는 적절한 내부 API가 없기 때문에 시스템이 현재 어려움을 겪고 있습니까? 시스템을 DI 모델로 전환하면 유닛 테스트를 더 잘할 수 있기를 바라고 있습니까? 코드를 단위 테스트하기 위해 컨테이너가 필요하지 않습니다. DI 모델을 사용하면 Mock 객체로 단위 테스트를보다 쉽게 ​​수행 할 수 있지만 필수는 아닙니다.

전체 시스템을 한 번에 DI와 호환되도록 전환 할 필요는 없습니다. 단위 테스트를 임의로 작성해서는 안됩니다. 기능 및 버그 작업 티켓에서 코드를 발견 할 때 코드를 리팩터링하십시오. 그런 다음 터치 한 코드를 쉽게 테스트 할 수 있는지 확인하십시오.

CodeRot을 질병으로 생각하십시오. 임의로 해킹을 시작하고 싶지 않습니다. 환자가 있고 아픈 부위가 보이면 그 부위와 그 주위의 물건을 고치기 시작합니다. 해당 영역이 깨끗해지면 다음 영역으로 넘어갑니다. 조만간 코드의 대부분을 다루게 될 것이며이 "대규모"아키텍처 변경이 필요하지 않았습니다.

나는 DI와 Mock 테스트가 상호 배타적이라는 것을 좋아하지 않습니다. 그리고 DI를 사용하여 더 나은 단어가 부족하여 진행된 프로젝트를 본 후, 나는 혜택을 보지 않고 지칠 것입니다.

DI를 사용하는 것이 적합한 곳이 있습니다.

• 스토리 데이터에 대한 전략을 교환하기위한 데이터 액세스 계층
• 인증 및 권한 부여 계층.
• 사용자 인터페이스 테마
• 서비스
• 자신의 시스템 또는 타사에서 사용할 수있는 플러그인 확장 점.

각 개발자가 DI 구성 파일의 위치를 ​​알도록 요구합니다 (컨테이너를 코드를 통해 인스턴스화 할 수는 있지만 실현하려는 이유는 무엇입니까?). RegEx를 수행하려고 할 때 실망 스럽습니다. 아 IRegExCompiler, DefaultRegExCompiler 및 SuperAwesomeRegExCompiler가 있습니다. 그러나 코드의 어디에서 Default를 사용하고 SuperAwesome을 사용하는지 분석 할 수는 없습니다.

누군가 가 나에게 더 나은 것을 보여 주면 내 말이 저를 설득하려고 하면 내 성격이 더 잘 반응 할 것입니다. 시스템을 개선하기 위해 시간과 노력을 기울일 누군가에 대해 할 말이 있습니다. 많은 개발자들이 제품을 진정으로 개선하기에 충분한 관심을 갖고있는 것은 아닙니다. 시스템을 실제로 변경하여 그들에게 갈 수 있고 그것이 더 쉽고 쉬운 방법을 보여줄 수 있다면, 그것은 온라인 조사보다 더 가치가 있습니다.

요약하면, 시스템 변경에 영향을 미치는 가장 좋은 방법은 각 패스에 대해 현재 만지고있는 코드를 천천히 개선하는 것입니다. 조만간 시스템을 더 나은 것으로 바꿀 수있게 될 것입니다.

DI는 침입 컨트롤 컨테이너 또는 모의 프레임 워크를 필요로하지 않습니다. 간단한 설계를 통해 코드를 분리하고 DI를 허용 할 수 있습니다. 기본 제공 Visual Studio 기능을 통해 단위 테스트를 수행 할 수 있습니다.

공정하게 말하면, 동료들은 한 가지 지적 할 점이 있습니다. 이러한 라이브러리를 잘못 사용하면 (그리고 익숙하지 않기 때문에 학습에 어려움이있을 수 있음) 문제가 발생할 수 있습니다. 결국 코드가 중요합니다. 테스트를 위해 제품을 망치지 마십시오.

이러한 시나리오에서는 타협이 필요하다는 것을 기억하십시오.

나는 이것이이기 때문에, 당신은 더 이상 DI를 판매 할 수 있다고 생각하지 않습니다 독단적 결정 (@Spoike이 더 정중라고 불렀다으로, 또는 정치적 ).

이 상황에서 SOLID 설계 원칙 과 같이 널리 인정되는 모범 사례를 주장하는 것은 더 이상 불가능합니다.

귀하보다 정치 권력이 더 높은 사람이 DI를 사용하지 않기로 한 (잘못 된) 결정을 내 렸습니다.

반대편에 당신은 확립 된 컨테이너를 사용하는 것이 금지 되었기 때문에 당신 자신의 컨테이너를 구현함으로써이 결정에 반대했습니다. 이 faits accomplis의 정책 이 시도보다 더 나쁜 상황을 만들었습니다 수 있습니다.

분석

제 생각에 TDD (testdriven development)가없는 DI와 단위 테스트는 초기 추가 비용보다 큰 이점이 없습니다.

이 문제는 실제로

• 우리는 DI를 원하지 않습니까?

아니면 이것에 대한 자세한

• tdd / unittesting은 자원 낭비 입니까?

[최신 정보]

프로젝트 관리보기 의 일반적인 실수에서 프로젝트 를 볼 경우

#12: Politics placed over substance.
#21: Inadequate design. 
#22: Shortchanged quality assurance.
#27: Code-like-hell programming.

다른 사람들이 보는 동안

#3: Uncontrolled problem employees. 
#30: Developer gold-plating. 
#32: Research-oriented development. 
#34: Overestimated savings from new tools or methods. 

팀원에게 원칙을 "판매"해야하는 경우, 이미 잘못된 길로 몇 마일 떨어진 것 같습니다.

아무도 여분의 일을하기를 원하지 않기 때문에, 팔려고하는 것이 여분의 일처럼 보이는 경우, 반복되는 우수한 인수의 호출로 그들을 설득하지 않을 것입니다. 워크로드를 늘리는 것이 아니라 줄일 수있는 방법을 보여주고 있음을 알아야합니다.

DI는 나중에 복잡성을 줄일 수 있다는 가능성으로 인해 지금 은 추가적인 복잡성으로 여겨지 는데, 이는 초기 워크로드를 줄이려는 사람에게는 그다지 가치가 없지만 가치가 있습니다. 그리고 많은 경우에 DI는 YAGNI의 또 다른 계층 일뿐 입니다. 이 복잡성의 비용은 0이 아닙니다. 실제로 이러한 유형의 패턴에 익숙하지 않은 팀에게는 비용이 많이 듭니다. 그리고 그것은 결코 이익을 얻지 못할 수도있는 양동이에 삽니다.

그 자리에 놓으
십시오. 가장 좋은 방법은 DI가 일반적인 곳이 아니라 눈에 띄게 유용한 곳에 사용하는 것입니다. 예를 들어, 많은 앱이 DI를 사용하여 데이터베이스를 선택하고 구성합니다. 그리고 앱에 데이터베이스 레이어가 포함되어 있다면 그것을 유혹하는 곳입니다. 그러나 앱에 코드에 밀접하게 통합 된 내장 된 사용자가 볼 수없는 데이터베이스가 제공되는 경우 런타임에 DB를 교체해야 할 가능성은 거의 없습니다. "이봐, 우리는 절대로, 절대 원치 않는 일을 쉽게 할 수있다"고 말함으로써 DI를 파는 것은 상사와 함께 "이 사람은 나쁜 생각을 가지고있다"목록에 올라갈 가능성이 높다.

그러나 대신 릴리스에서 일반적으로 IFDEF를 얻는 디버깅 출력이 있다고 가정하십시오. 또한 사용자에게 문제가있을 때마다 지원 팀은 로그 출력을 얻을 수 있도록 디버그 빌드를 보내야합니다. 여기에서 DI를 사용하여 고객이 LogConsole개발자, LogNull고객 및 LogNetwork문제가있는 고객을 위해 로그 드라이버 간을 전환 할 수 있습니다. 하나의 통합 빌드, 런타임 구성 가능

그런 다음 DI라고 부르지 않아도됩니다. 대신 "Mel 's really good idea"라고 불리며 이제 나쁜 아이디어 대신 좋은 아이디어 목록에 있습니다. 사람들은 패턴이 얼마나 잘 작동하는지 알고 코드에서 의미가있는 곳에서 패턴을 사용하기 시작합니다.

아이디어를 제대로 판매하면 사람들은 자신이 어떤 것을 확신했는지 알 수 없습니다.

물론 IoC ( Inversion of control )는 많은 이점을 제공합니다. 코드를 단순화 하고 일반적인 작업을 수행하는 마법 을 추가하는 등의 이점 이 있습니다.

하나:

1. 많은 의존성을 추가합니다. Spring으로 작성된 간단한 hello world 응용 프로그램 은 12MB의 가중치를 가질 수 있으며 Spring 은 몇 줄의 생성자와 setter를 피하기 위해 추가 된 것을 보았습니다.

2. 위에서 언급 한 magic을 추가하여 외부인 에게는 이해하기 어렵습니다 (예 : 비즈니스 계층에서 일부를 변경해야하는 GUI 개발자). 전문가 들이이 효과를 어떻게 과소 평가하는지에 대한 훌륭한 기사 인 혁신적인 마음은 생각하지 않습니다 – 뉴욕 타임즈를보십시오 .

3. 클래스 사용을 추적하기가 어렵습니다. Eclipse 와 같은 IDE 는 주어진 클래스 또는 메소드 호출의 사용법을 추적하는 훌륭한 기능을 가지고 있습니다. 그러나 의존성 주입 및 반영이 호출되면이 추적이 손실됩니다.

4. IoC 사용은 일반적으로 의존성 주입으로 끝나지 않으며 수많은 프록시로 끝나며 수백 줄을 계산하는 스택 추적을 얻습니다.이 중 90 %는 프록시이며 리플렉션을 통해 호출됩니다. 스택 추적 분석이 매우 복잡합니다.

그래서 나는 Spring과 IoC의 열렬한 팬이 되려고 최근에 위의 질문을 다시 생각해야했습니다. 내 동료들 중 일부는 Python과 PHP와 지배 웹 세계에서 자바 세계 안에 촬영 웹 개발자입니다 분명 그들에게 분명한 것보다 아무것도 javaist의 것들에 대한 있습니다. 내 다른 동료 중 일부는 (물론 문서화되지 않은) 트릭 을 수행 하여 오류를 찾기가 매우 어렵습니다. 물론 IoC 오용은 일을 더 가볍게 만듭니다.)

내 조언, 당신이 당신의 일에서 IoC를 강제로 사용한다면, 당신은 다른 사람이 저지른 모든 잘못에 대해 책임을 질 것입니다;)

ChrisF가 옳은 일이라고 생각합니다. DI 자체를 판매하지 마십시오. 그러나 코드 단위 테스트에 대한 아이디어를 판매하십시오.

DI 컨테이너를 아키텍처로 가져 오는 한 가지 방법은 테스트가 구현을 해당 아키텍처에 적합한 것으로 천천히 구현하도록하는 것입니다. 예를 들어 ASP.NET MVC 응용 프로그램의 컨트롤러에서 작업하고 있다고 말할 수 있습니다. 다음과 같이 수업을 작성한다고 가정 해보십시오.

public class UserController {
    public UserController() : this (new UserRepository()) {}

    public UserController(IUserRepository userRepository) {
        ...
    }

    ...
}

이를 통해 사용자 저장소의 실제 구현에서 분리 된 단위 테스트를 작성할 수 있습니다. 그러나 클래스는 여전히 DI 컨테이너없이 작동하여 클래스를 만듭니다. 매개 변수가없는 생성자는 기본 리포지토리를 사용하여 생성합니다.

동료가 이것이 훨씬 더 깨끗한 테스트로 이어지는 것을 볼 수 있다면 더 나은 방법임을 알 수 있습니다. 어쩌면 그런 식으로 코딩을 시작할 수 있습니다.

이들이 특정 UserRepository 구현에 대해 알고있는 UserController보다 더 나은 디자인이라는 것을 알게되면 다음 단계로 이동하여 필요한 인스턴스를 자동으로 제공 할 수있는 DI 컨테이너 구성 요소를 가질 수 있음을 보여줄 수 있습니다.

가장 좋은 방법은 물러서서 DI 컨테이너를 왜 소개하고 싶은지 스스로에게 물어 보는 것입니다. 테스트 가능성을 높이려면 먼저 팀이 단위 테스트를 구매하도록해야합니다. 개인적으로 저는 DI 컨테이너 부족보다 단위 테스트 부족에 대해 훨씬 더 걱정하고 있습니다.

포괄적 인 단위 테스트 스위트로 무장 한 경우, 시간이 지남에 따라 설계를 발전시키는 데 자신감을 가질 수 있습니다. 그것들이 없으면, 많은 팀들이 잃는 투쟁, 진화하는 요구 사항에 따라 디자인을 단계적으로 유지하기 위해 점점 더 어려워지고 있습니다.

제 조언은 먼저 유닛 테스트와 리팩토링을 먼저 수행하고 DI 컨테이너와 DI 컨테이너를 소개하는 것입니다.

나는 당신의 팀으로부터 큰 아니오를 듣고 있습니다 :

• "타사 라이브러리 없음"-AKA "여기에 발명되지 않음"또는 "NIH" 제 3 자 라이브러리를 구현하고 이에 따라 코드베이스를 종속적으로 만들면 라이브러리에 버그 나 보안 허점이 있거나 극복해야 할 제한 사항 만 있으면이 세 번째 라이브러리에 의존하게됩니다. 코드가 작동하도록 라이브러리를 수정하십시오. 그 동안 "실제로"실패했거나 해킹 당했거나 요청한대로하지 않는 "귀하의"프로그램으로 인해 귀하는 여전히 책임을 져야합니다 (제 3 자 개발자는 해당 도구가 "있는 그대로" ", 귀하의 책임하에 사용하십시오).

  반론은 문제를 해결하는 코드가 이미 타사 라이브러리에 존재한다는 것입니다. 컴퓨터를 처음부터 구축하고 있습니까? Visual Studio를 작성 했습니까? .NET에서 내장 라이브러리를 피하고 있습니까? 아니요. 인텔 / AMD 및 Microsoft에 대한 신뢰 수준이 높으며 항상 버그를 발견합니다 (항상 빨리 수정하지는 않습니다). 타사 라이브러리를 추가하면 휠을 다시 만들지 않고도 유지 관리 가능한 코드베이스를 신속하게 사용할 수 있습니다. 그리고 .NET 암호화 라이브러리의 버그로 인해 .NET 프로그램을 사용할 때 고객이 겪은 해킹 사건에 대해 책임을 진다고 말하면 Microsoft 변호사가 당신의 얼굴에 웃을 것입니다. 마이크로 소프트는 확실히 자사 제품의 "제로 시간"보안 허점을 해결하기 위해 뛰어 들지만,

• "우리는 모든 것을 하나의 어셈블리에 넣고 싶다"-실제로는 그렇지 않습니다. .NET에서 최소한 한 줄의 코드를 변경하면 해당 코드 줄을 포함하는 전체 어셈블리를 다시 작성해야합니다. 올바른 코드 디자인은 가능한 한 독립적으로 재 구축 할 수있는 (또는 최소한 종속 항목이 아닌 종속성 만 다시 빌드해야하는) 여러 어셈블리를 기반으로합니다. 그들이 EXE 일 뿐인 EXE (일부 상황에서는 가치가있는)를 릴리즈하려고한다면, 해당 앱이 있습니다. ILMerge.

• "DI is taboo"-WTF? DI는 "인터페이스"코드 구성을 가진 모든 O / O 언어에서 허용되는 모범 사례입니다. 팀이 GRASP 또는 SOLID 설계 방법론이 객체 간의 종속성을 느슨하게 결합하지 않는 경우 어떻게 준수합니까? 그들이 귀찮게하지 않으면, 제품을 복잡한 사기로 만드는 스파게티 공장을 영속시키고 있습니다. 이제 DI는 개체 수를 늘려 복잡성을 증가시키고 다른 구현을 쉽게 대체 할 수 있지만 변경해야하는 코드 개체의 추가 계층을 추가하여 인터페이스 자체를 더 어렵게 변경합니다.

• "우리는 이미 복잡한 프로젝트에이 복잡한 계층을 추가 할 필요가 없습니다." 모든 코드 개발에서 고려해야 할 중요한 사항은 YAGNI입니다. "당신은 그것을 필요로하지 않을 것이다". 처음부터 SOLIDly 엔지니어링 된 디자인은 SOLID를 "믿음"으로 만든 디자인입니다. SOLID 설계가 제공하는 쉬운 변경이 필요한지 알지 못하지만 직감이 있습니다. 당신이 옳을 수도 있지만, 매우 잘못되었을 수도 있습니다. 매우 SOLID 디자인은 결국 "라 자나 코드"또는 "라비올리 코드"로 간주 될 수 있습니다. 이러한 복잡한 호출 스택.

  세 가지 타격 규칙을 지원합니다. 이 SOLID하게, 청결하게, 작동 확인. 코드 줄을 처음 작성할 때는 작동하기 만하면되고 상아탑 디자인에 대한 점수를 얻지 못합니다. 그것이 일회성이라고 가정하고 당신이해야 할 일을하십시오. 두 번째로이 코드를 살펴보면 아마도 코드를 확장하거나 재사용하려고 할 것입니다. 이는 생각했던 일회성이 아닙니다. 이 시점에서 리팩토링하여 더 우아하고 이해하기 쉽게 만드십시오. 복잡한 논리를 단순화하고, 반복되는 코드를 루프 및 / 또는 메소드 호출로 추출하고, 여기 저기 몇 가지 주석을 추가해야합니다. 이제 SOLID 규칙을 준수해야합니다. 의존성을 구성하는 대신 의존성을 주입하고, 코드의 "고기"와 덜 응집적인 메소드를 보유하는 클래스를 추출하고,

• "우리는 다른 구현에 연결하는 것과 같지 않습니다."-여러분은 단위 테스트를 믿지 않는 팀을 보유하고 있습니다. 나는 부작용이있는 개체를 "모의"할 수없이 단독으로 실행되고 부작용이없는 단위 테스트를 작성하는 것이 불가능하다고 주장했다. 사소한 프로그램은 부작용이 있습니다. 프로그램이 DB를 읽거나 쓰거나, 파일을 열거 나 저장하거나, 네트워크 또는 주변 장치 소켓을 통해 통신하거나, 다른 프로그램을 시작하거나, 창을 그리거나, 콘솔에 출력하거나, 프로세스의 "샌드 박스"외부의 메모리 나 리소스를 사용하는 경우 부작용. 만약 이것들 중 어느 것도하지 않는다면, 무엇을하고 왜 그것을 사야합니까?

  공정하게 말하면, 단위 테스트 만이 프로그램의 작동을 증명하는 유일한 방법은 아닙니다. 통합 테스트, 수학적으로 입증 된 알고리즘에 대한 코드 등을 작성할 수 있습니다. 그러나 단위 테스트는 입력 A, B 및 C에 대해이 코드가 예상 X를 출력하는지 여부를 매우 빠르게 보여줍니다. 주어진 경우 코드가 제대로 작동하거나 작동하지 않습니다. 일련의 단위 테스트는 코드가 모든 경우에 예상대로 작동한다는 것을 확실하게 보여줄 수 있으며 수학적 증거로는 불가능한 것을 제공합니다. 프로그램이 의도 한대로 작동한다는 데모. 알고리즘의 수학적 증거는 알고리즘이 올바르게 구현되었다는 것을 나타내지 않으며, 변경 사항이 올바르게 구현되어 깨지지 않았 음을 증명하지도 않습니다.

한마디로,이 팀이 DI가 무엇을하는지에 대한 가치를 보지 못하면 지원하지 않을 것이며, 모든 사람 (적어도 모든 선임 직원)은 실질적인 변화를 위해 무언가를 사야한다는 것입니다 일어날. 그들은 YAGNI에 많은 중점을두고 있습니다. SOLID 및 자동화 된 테스트에 중점을두고 있습니다. 가운데 어딘가에 진실이 있습니다.

승인되지 않은 프로젝트에 DI와 같은 추가 기능을 추가하도록주의하십시오. 시간 제한이있는 프로젝트 계획이있는 경우 승인 된 기능을 완료하기에 시간이 충분하지 않은 함정에 빠질 수 있습니다.

지금 DI를 사용하지 않더라도 테스트에 참여하여 회사의 테스트에 대한 기대치가 정확히 무엇인지 알 수 있습니다. 다른 프로젝트가 있으며 현재 프로젝트와 DI의 테스트와 관련된 문제를 대조 할 수 있습니다.

DI를 사용하지 않으면 창의력을 발휘하고 코드를 DI- "준비"할 수 있습니다. 다른 생성자를 호출하려면 매개 변수가없는 생성자를 사용하십시오.

MyClassConstructor()
{
    MyClassConstructor(new Dependency)
    Property = New Dependent Property
}

MyClassConstructor(Dependency)
{
    _Dependency = Dependency
}

그들의 가장 큰 관심사 중 하나는 실제로 정반대라고 생각합니다. DI는 프로젝트를 복잡하게 만들지 않습니다. 대부분의 경우 많은 복잡성을 줄입니다.

DI없이 생각하면 필요한 종속 객체 / 구성 요소를 무엇으로 얻을 수 있습니까? 일반적으로 저장소에서 조회하거나 싱글 톤을 가져 오거나 인스턴스화하는 것입니다.

전자 2는 종속 구성 요소를 찾는 데 필요한 추가 코드를 포함합니다. DI 세계에서는 조회를 수행하기 위해 아무 것도하지 않았습니다. 실제로 구성 요소의 복잡성이 줄어 듭니다.

적절하지 않은 경우에 인스턴스화하는 경우 더 복잡해집니다. 객체를 올바르게 작성하는 방법을 알아야하고, 객체를 실행 가능한 상태로 초기화 할 값을 알아야합니다.이 모든 것들은 코드를 더욱 복잡하게 만듭니다.

따라서 DI는 프로젝트를 복잡하게 만들지 않고 구성 요소를 단순화하여 더 단순하게 만듭니다.

또 다른 큰 주장은 다른 구현을 연결하지 않을 것입니다. 그렇습니다. 프로덕션 코드에서 실제 프로덕션 코드에 여러 가지 다른 구현을하는 것은 일반적이지 않습니다. 그러나 다른 구현이 필요한 하나의 주요 장소가 있습니다 : 단위 테스트에서 모의 ​​/ 스텁 / 테스트 복식. DI가 작동하도록하기 위해 대부분의 경우 인터페이스 중심 개발 모델에 의존하기 때문에 단위 테스트에서 조롱 / 스터 빙이 가능합니다. 구현을 대체하는 것 외에도 "인터페이스 지향 디자인"은 더 깨끗하고 더 나은 디자인을 만듭니다. 물론 DI없이 인터페이스로 디자인 할 수 있습니다. 그러나 단위 테스트와 DI는 그러한 관행을 채택하도록 추진하고 있습니다.

회사의 "신들"이 "간단한 코드", "단위 테스트", "모듈화", "단일 책임"등을 모두 고려하지 않는 한 DI 사용을 거부 할 이유가 없습니다.

"우리는 가능한 한 모든 것을 하나의 어셈블리에 넣는 것만으로 간단하게 유지하려고합니다. DI는 이점이없는 불필요한 복잡성입니다."

이점은 인터페이스 설계를 촉진하고 손쉬운 조롱을 허용한다는 것입니다. 결과적으로 단위 테스트를 용이하게합니다. 단위 테스트는 신뢰할 수 있고 모듈 식이며 유지 관리하기 쉬운 코드를 보장합니다. 만약 당신의 상사가 여전히 나쁜 생각을 유지한다면, 당신이 할 수있는 일은 없습니다 – 그들이 주장하는 업계의 모범 사례입니다.

DI 프레임 워크 및 모의 라이브러리를 사용하여 단위 테스트를 작성해 보자. 곧 그것을 사랑하는 법을 배우게 될 것입니다.

더 작은 프로젝트 나 하나의 큰 프로젝트에서이 사람들과 함께 일하십니까? 팀 / 회사의 빵과 버터보다 2 차 / 3 차 프로젝트에서 사람들이 새로운 것을 시도하도록 설득하는 것이 더 쉽습니다. 주된 이유는 제거 / 교체 비용이 실패하면 훨씬 작고 작은 프로젝트의 모든 곳에서 가져 오는 작업이 훨씬 적기 때문입니다. 기존의 대규모의 경우 한 번에 모든 곳에서 변경을 수행하는 데 초기 비용이 많이 들거나, 각 클래스의 설계 방식을 기억해야하기 때문에 코드에 마찰을 추가하는 기존 / 새로운 접근 방식이 혼합 된 연장 된 기간이 있습니다. 일하다.

DI를 장려하는 것 중 하나는 단위 테스트이지만, 일부 경우에는 복잡성이 추가된다고 생각합니다.

• 테스트에 어려움이 있지만 수리가 어려운 자동차보다 테스트에 어려움이 있지만 수리가 쉬운 자동차를 만드는 것이 좋습니다.

• 또한 DI를 추진하는 그룹은 기존 디자인 접근 방식이 나쁘다는 영향을 통해 아이디어를 제시하는 것 같습니다.

• 5 가지 기능을 수행하는 방법이 있다면

  DI- 사람들은 말한다 :

  • 우려의 분리가 없습니다. [그 문제는 무엇입니까? 그들은 논리와 프로그래밍에서 서로 충돌하고 잘못된 기대를 피하고 코드 변경의 영향을 쉽게 파악하기 위해 서로가 무엇을하고 있는지 아는 것이 훨씬 낫습니다. 서로 관련이없는 개체를 100 % 이상으로 유지하거나 {회귀 테스트가 중요한 이유가 아니면?
  • 복잡한 [그들은 "기본을 갖기 위해 철학 (default) / "아니면"토론 ...] 그런 다음 복잡성을 컨테이너와 구조로 옮겼습니다. [이를 처리하기 위해 복잡한 언어 특성을 가진 복잡한 장소를 한 곳에서 두 곳으로 옮기는 것처럼 보입니다. ]

DI의 영향을받는 것이 아니라 비즈니스 요구에 맞는 자체 디자인 패턴을 만드는 것이 좋습니다.

DI에 찬성하여 일부 상황에서 도움이 될 수 있습니다. 예를 들어, 동일한 인터페이스에 대한 수백 개의 구현이 선택기에 의존하고 이러한 구현이 논리적으로 크게 다른 경우이 경우 DI 또는 DI 유사한 기술을 사용합니다. 그러나 동일한 인터페이스에 대한 구현이 거의 없으면 DI가 필요하지 않습니다.