그들은 모순됩니까?디커플링 대 YAGNI
디커플링은 달성하기가 매우 어렵습니다. 그러나 대부분의 응용 프로그램에서는 필요하지 않으므로 고도로 결합 된 응용 프로그램을 설계 할 수 있습니다. "구성 요소를 분리 할 수 없습니다."와 같은 명백한 부작용 이외의 변경 사항은 거의 없습니다. 단위 테스트는 엉덩이 "등
당신은 어떻게 생각하십니까? 당신은 항상 오버 헤드를 분리하고 다루려고합니까?
디커플링과 YAGNI가 매우 보완적인 덕목 인 것 같습니다. (나는 Rob의 대답에 주목했고, 우리는 여기 같은 페이지에있는 것처럼 보였습니다.) 질문은 당신이해야 할 감 결합이 얼마나되는지, YAGNI는 대답을 결정하는 데 도움이되는 좋은 원칙입니다. (단위 테스트에 대해 말하는 사람들을 위해 - 단원 검정을하기 위해 분리해야한다면 YAGNI는 분명히 적용되지 않습니다.)
"항상"분리라고 말하는 사람들은 진심으로 의심합니다. 어쩌면 그들은 항상 생각할 때마다 그럴 수 있습니다. 그러나 나는 추상화의 추가 레이어가 어딘가에 추가 될 수없는 프로그램을 보지 못했으며, 거기에 그런 프로그램의 예가 있다는 것을 진심으로 의심한다. 모든 사람들이 어딘가에 선을 긋습니다.
필자의 경험에 비추어 볼 때 필자는 코드를 연결 해제 한 다음 코드를 결합한 상태에서 추가 유연성을 얻은 적이 전혀 없었으며 나중에 다시 돌아와서 변경해야했습니다. 나는 그것이 균형이 잘되어 있거나 양방향으로 똑같이 부서 졌음을 의미하는지 확실하지 않습니다.
I (거의) 항상 분리됩니다. 내가이 일을 할 때마다 나는 유용하다는 것을 알았고, (거의) 내가 할 수 없을 때마다 나중에해야만했다. 또한 버그 수를 줄이는 좋은 방법이라고 생각했습니다.
글쎄, YAGNI는 사람들이 던지는 가짜 단순한 문구에 지나지 않습니다. 그러나 디커플링은 상당히 잘 이해 된 개념이다. YAGNI는 어떤 것은 일종의 심령이라는 것을 암시하는 것처럼 보입니다. 진부한 방식으로 프로그래밍하는 것입니다. 결코 좋은 생각이 아닙니다. 솔직히, YAGNI가 아마도 디커플링과 관련이없는 경우가 있습니다. 커플 링은 일반적으로 "더 빠릅니다"및 "분리 된 솔루션이 필요한지 누가 알 수 있습니까? 어쨌든 X 구성 요소를 변경하지 않을 것입니다!"
디커플링을위한 디커플링은 좋지 않을 수 있습니다. 그래도 테스트 할 수있는 구성 요소를 작성하는 것은 매우 중요합니다.
이야기의 어려운 부분은 언제 어떻게 필요한 디커플링을 하는지를 아는 것입니다.
태그가 말했듯이 매우 주관적입니다. 그것은 당신이 "필요하지 않을 것"을 결정하는 자신의 엔지니어링 지혜에 전적으로 달려 있습니다. 한 경우에 커플 링이 필요할 수 있지만 다른 경우에는 커플 링하지 않습니다. 누구에게 말할 것인가? 물론입니다.
이렇게 주관적인 결정을 내리려면 처방 할 지침이 있어서는 안됩니다.
답변을 주셔서 감사합니다. 나는 다른 사람들이하는 일에 대해 궁금해하고 있다고 말했기 때문에 가이드 라인을 찾고 있지 않습니다. 주제에 대한 귀하의 생각은 언제이며, 어떤 경우에 당신은 그와 같이 떨어지고 느끼지 않습니다. 죄송합니다 질문에 명확하지 않은 경우. –
나는 그렇지 않다고 말하고 싶다. 디커플링은 코드 내에서 불필요한 의존성을 줄이고 깨끗하고 잘 정의 된 인터페이스를 통해 액세스를 강화하는 것에 관한 것입니다. "당신이 필요하지는 않을 것"은 명백하고 현재의 사용 사례가없는 솔루션의 과도한 확장 성 및 지나치게 광범위한 아키텍처에 대해 일반적으로 권고하는 유용한 원칙입니다.
실용적인 결과는 실수로 전체 응용 프로그램에서 파급 효과가 발생하지 않고 개별 구성 요소를 리팩터링하고 유지 관리하는 것이 쉽고 디자인에 불필요하게 복잡한 측면이없는 시스템을 갖추고 있다는 것입니다. 현재 요구 사항을 충족시키는 데 필요한만큼 간단합니다.
YAGNI 엉망진창 : ... 정말, 우리는 모든 코드를 혼합하여 "더 빠르게"할 필요가 없습니다.
단위 테스트는 실제로 결합되었을 때의 느낌을 돕습니다. 단위 테스트는 다른 유형의 테스트보다 잘 이해됩니다. "구성 요소를 분리 할 수 없습니다"사고 방식을 대신 사용하면 필요할 필요가없는 물건을 쉽게 추가 할 수 있습니다.
나는 YAGNI가 비틀어지기 시작하면 로직이 변경 될 것입니다. 현재 구현에서 요구하는 실제 사용 시나리오를 넘어서. 두 사이트 모두 외부 사이트로 리디렉션되는 외부 결제 제공 업체를 사용하는 코드가 있다고 가정 해 보겠습니다. 모든 것을 깨끗하게 유지하는 디자인은 괜찮습니다.하지만 통합 및 관련 문제를 처리 할 수있는 다양한 방법이있는 경우 지원되지 않을지 모르는 공급자에 대해 생각해 보는 것은 좋지 않다고 생각합니다. 워크 플로우
"단위 테스트는 엉덩이의 통증"이라면 나는 당신이 일을해야한다고 말하고 싶습니다. 대부분의 시간 디커플링은 사실상 제로 비용으로도 달성 할 수 있습니다. 그렇다면 왜 그럴 필요가 없습니까?
또한, 내 가장 큰 버그 베어의 하나 어딘가 인터페이스의 도입 또는 의존성 주입의 사용 시간을 많이 절약 할 수있을 때 내가 단위 테스트를 쓰기 시작하기 전에 코드를 분리하는 데 새로운 코드베이스 작업
사실상 제로 비용으로 어떻게 디커플링을 달성 할 수 있습니까? 그것은 내 마음 속에서 거의 불가능합니다. 나는 사람들의 대부분이 디커플링이 달성하기가 어렵다고 생각하기 때문에 이것에 대해 궁금합니다. 특히 구성을 읽는 것과 같이 간단한 것조차도 dep가 필요합니다. injection –
의존성 주입은 물론 이루어져야합니다. (그리고 제대로 테스트를한다면). 이를 달성하기 위해 DI 컨테이너가 필요 없지만이를 달성하기 위해 상용구 코드를 작성하는 것을 볼 수 있습니다. Guice는 설치가 거의 필요없는 DI를 제공하며 아주 쉽게 개조 할 수 있습니다. – tddmonkey
YAGNI는 엄지 손가락의 규칙입니다 (종교가 아님). 디커플링은 다소 기술 (종교가 아님)입니다. 따라서 그들은 서로 관련이 없으며 서로 모순되지 않습니다.
YAGNI는 실용주의입니다. 당신이 할 때까지 당신이 무언가를 필요로하지 않는다고 가정하십시오.
일반적으로 YAGNI가 디커플링을한다고 가정합니다. 그 칼을 전혀 사용하지 않으면, 당신은 그것이 사실임을 증명하기 전에 서로의 행동에 대해 모두 알고있는 수업을 가질 필요가 있다고 가정합니다.
"Decouple"(또는 "loosely couple")은 동사이므로 작업이 필요합니다. YAGNI는 더 이상 사실이 아님을 발견 할 때 조정할 수있는 가정입니다.
YAGNI는 어떤 종류의 초능력이 아니라는 것을 의미합니다. http://c2.com/cgi/wiki?YouArentGonnaNeedIt –
정확히 무엇인지 알고 있지만 게임을하고 있습니다. 그러나 당신이 근본적으로 어리석은 구절 인 이유를 보여줍니다. YAGNI가 심령 횡설수설인지 아니면 근시안인지에 대해 토론하고 싶다면 지루하고 열매없는 토론이기 때문에하지 않을 것입니다. – BobbyShaftoe