SOLID 원칙과 YAGNI

SOLID 원칙은 언제 YAGNI가됩니까?

프로그래머로서 우리는 복잡성, 유지 보수성, 구축 시간 등과의 상충 관계를 항상 유지합니다. 무엇보다도 선택을위한 가장 현명한 두 가지 지침은 SOLID 원칙과 YAGNI입니다. 필요하지 않으면; 빌드하지 말고 깨끗하게 유지하십시오.

예를 들어, SOLID 에서 dimecast 시리즈를 볼 때 상당히 간단한 프로그램으로 시작하고 꽤 복잡한 프로그램으로 끝납니다 (결국 예 복잡성은 보는 사람의 눈에도 있습니다). 궁금해 : 언제 SOLID 원칙이 필요없는 것으로 바뀔까요? 모든 견고한 원칙은 나중에 단계에서 변경을 수행하는 데 사용할 수있는 작업 방법입니다. 그러나 해결해야 할 문제가 아주 간단한 문제이고 끔찍한 응용 프로그램이라면 어떻게해야합니까? 아니면 SOLID 원칙이 항상 적용되는 것입니까?

의견에 따르면 :

• SOLID 원리
• 야 그니

데모에서 선택한 문제는 일반적으로 너무 작아서 SOLID와 같은 원칙을 적용하면 솔루션이 완전히 과도하게 설계된 것처럼 보이기 때문에 스크린 캐스트를 기반으로 접근 방식을 판단하는 것은 항상 어렵습니다.

SOLID 원칙은 거의 항상 유용하다고 말하고 싶습니다. 일단 당신이 그들에 능숙 해지면, 그것들을 사용하는 것이 고의로 생각해야 할 것 같지 않습니다. 그것은 자연스럽게됩니다. 많은 일회용 일회용 앱이 그 이상이되는 것을 보았으므로 이제는 무언가를 버릴 것이라고 두려워합니다.

내가 일반적으로 취하는 접근법은 특정 작업을 위해 간단한 응용 프로그램을 작성하는 경우 때로는 작동하는 몇 줄의 코드를 선호하는 큰 이름 원칙을 잊어 버리는 것입니다. 추가 변경을 위해 해당 앱으로 돌아온다는 것을 알게되면, 시간을내어 SOLID로 만들 것입니다 (적어도 원칙의 100 % 적용은 거의 불가능하기 때문에).

더 큰 앱에서는 작게 시작하고 프로그램이 발전함에 따라 가능한 경우 SOLID 원칙을 적용합니다. 이 방법으로 나는 마지막 열거 형에 이르기까지 모든 것을 거꾸로 디자인하려고하지 않습니다. 그것은 YAGNI와 SOLID가 공존하는 곳입니다.

가장 먼저 직면 한 문제에 대해 생각하십시오. YAGNI 또는 SOLID의 원칙을 맹목적으로 적용하면 나중에 부상을 입을 수 있습니다. 우리 모두가 이해할 수 있기를 바라는 것은 모든 문제에 맞는 "하나의"설계 접근법이 없다는 것입니다. 상점에서 "모두에 맞는"크기로 광고 된 모자를 판매 할 때 머리에 맞지 않는다는 증거를 볼 수 있습니다. 너무 크거나 작습니다.

대신 SOLID가 해결하려는 원리와 문제를 이해하는 것이 좋습니다. YAGNI가 해결하고자하는 원칙과 문제점뿐만 아니라 하나는 응용 프로그램의 아키텍처와 관련이 있고 다른 하나는 전체 개발 프로세스와 관련이 있습니다. 경우에 따라 겹치는 부분이있을 수 있지만 분명히 다른 문제가 있습니다.

YAGNI (Youn Aon't Gonna Need It [정맥 한 미국 약어])는 더 단순한 목조 다리가 단지 3 피트 너비의 크릭에 걸쳐있는 다리에 철근 콘크리트 기초를 추가하여 개발자 시간을 절약하는 데 관심이 있습니다. 좋아. 우리가 1 마일 폭의 강을 가로 질러 여러 개의 트랙터 트레일러를지지해야하는 경우, 추가 기초 공사가 필요합니다. 본질적으로 YAGNI는 현재의 요구에 맞는 더 큰 그림과 디자인을 보라고 말합니다 . 고객이 아직 파악하지 못한 수많은 잠재적 요구를 예상하고 있기 때문에 무언가를 너무 복잡하게 만드는 문제를 해결하고 있습니다.

SOLID는 다리 조각들이 서로 잘 맞고 시간이 지남에 따라 유지 될 수있는 방법에 관심이 있습니다. 철근 콘크리트 교량뿐만 아니라 목조 교량에도 SOLID 원리를 적용 할 수 있습니다.

간단히 말해서이 두 개념이 반드시 서로 상충되는 것은 아닙니다. 그들이 있다고 믿는 상황을 접했을 때, 큰 그림을 볼 때입니다. 결론에 따라 SOLID 원칙의 일부를 제거하거나 실제로 필요하다고 결정할 수 있습니다.

SOLID 원칙은 폐기 응용 프로그램 일 때는 필요하지 않습니다. 그렇지 않으면 항상 필요합니다.

SOLID와 YAGNI는 그다지 좋지 않습니다. 우수한 클래스 디자인으로 응용 프로그램을보다 쉽게 ​​유지할 수 있습니다. YAGNI는 애플리케이션이 실제로 필요하지 않는 한 태양 아래서 모든 것을 할 수있는이 구성 가능한 괴물이 될 수있는 기능을 추가해서는 안된다고 말합니다.

경계가 잘 정의 된 자동차 클래스 (SOLID)와 고객이 요청하기 전에자가 치유 (YAGNI) 기능이있는 자동차 클래스의 차이점입니다.

항상 적용되는 것은 없습니다! 건축 우주 비행사가 당신을 놀라게 하지 마십시오 ! 중요한 것은이 원칙들이 어떤 문제를 해결하려고하는지 이해하고 적용하여 정보를 적용하는 데 대한 결정을 내릴 수 있도록하는 것입니다.

최근에 나는 단일 책임 원칙을 언제 사용해야하는지 이해하려고 노력하고있었습니다 ( 여기서 생각해 보았습니다 ).

도움이 되었기를 바랍니다!

아인슈타인 (아마에 기인 견적가 진정한 하나의 변형 ) :

"모든 것이 가능한 한 단순해야하지만 더 단순해서는 안됩니다."

그리고 그것은 SOLID vs YAGNI 트레이드 오프에 직면했을 때 내가 취하는 접근법입니다. 프로그램이 '투척'코드인지 아닌지 알 수 없기 때문에 대안으로 적용하십시오. 따라서 작동하는 먼지 층을 추가 한 다음 더 깨끗한 인터페이스로 연마하고 올바른 수준의 엔트로피로 수렴 될 때까지 반복하십시오. 잘만되면

주어진 문제에 대한 프로그램을 설계하는 방법은 여러 가지가 있습니다. SOLID는 우수한 디자인의 속성을 식별하려는 시도입니다. SOLID를 올바르게 사용하면 추론하고 수정하기 쉬운 프로그램이 만들어집니다.

YAGNI와 KISS는 기능 범위와 관련이 있습니다. 더 많은 종류의 문제를 해결하는 프로그램은 더 복잡하고 추상적입니다. 그 일반성이 필요하지 않으면 이해하고 유지하기는 어렵지만 부가 가치는 제공하지 않는 코드를 만드는 데 시간과 노력을 투자했습니다.

잘 설계된 프로그램은 반드시 필요한 기능에만 초점을 맞추지는 않습니다. 필요한 기능에만 초점을 맞춘 프로그램은 반드시 잘 설계된 것은 아닙니다. 의사 결정 공간에는 두 개의 직교 축만 있으면됩니다. 이상적인 프로그램은 모듈 식이며 필수 기능 만 있습니다.

YAGNI를 시작하고 필요할 때마다 SOLIDify해야한다고 생각합니다.

내 말은 SOLID는 새로운 클래스를 추가 할 때 리팩토링 할 필요가 없으며 구현 (예 :)을 전환 할 필요가 없으며 내 의견으로는 코드를 작성하고 변경 사항을 볼 때 물건-SOLID로 변경하십시오 (즉, SOLID 리팩토링이 당신을 구해야한다고 두려워합니다-시작했을 때 그렇게 나쁘지 않습니다).

어쨌든 (처음에) 작업을 수행해야하기 때문에 시간을 낭비하지 않으며 필요한 곳마다 코드가 훌륭하고 깔끔합니다.

나는 당신이 그것을 SOLID의 게으른 평가라고 부를 수 있다고 생각합니다.