“당신은 그것을 필요로하지 않을 것입니다”와“지금은 결코 낫지 않는 것보다 낫습니다”는 어떻게 함께 플레이합니까?

나는 디자인의 드라이 니스를 발전시킬 때 종종 "지금은 결코 낫지 않다"는 것을 받아 들인다. 일반적으로, 나는 다른 지식 시스템의 맥락에서 하나의 지식 위치에 대한 하나의 권위있는 위치에 대한 이해를 배양해야한다는 것을 안다. 따라서 나는 '지금'시스템을 설계하는 경향이 있습니다.

반대로,이 연습은 내가 그것을 필요로하지 않을 합리적인 기회에도 불구하고 상당히 멀리 미리 건축하게합니다.

이 두 패턴은 어떻게 정사각형입니까?

그들이 잘 연주하기 위해 어떤 관행을 사용합니까?

혼란을 일으키지 않고 어떻게 함께 가르 칩니까?

나도 앞을 생각하지만 일반적으로 코드에서는 생각하지 않습니다. 브레인 스토밍하고 메모를 작성하여 잘 참조 할 수 있도록 잘 정리했습니다.

코드와 관련하여 "필요하지 않을 것"으로 더 많이 기대하지만 디자인에서 "지금은 결코 낫지 않습니다".

새로운 시스템 구축을 시작할 때 지금 모든 것을 구축하고 싶은 유혹이 있지만, 추진력과 사기를 떨어 뜨릴 수도 있습니다. 나는 전반적인 디자인에 대해 생각하고 그것을 통해 직접 선을 그리는 경향이 있습니다. 엔드-투-엔드 골격 구조를 생각해 내고, 먼저 그것을 설계하고, 나중에 그것을 발전시켜 리팩토링 할 수 있도록 사운드 디자인 원칙을 적용하십시오. 새로운 기능.

작동 할 수있는 시스템의 가장 간단한 엔드-투-엔드 표현을 구축하십시오. 먼저 그 작업을 수행 한 다음, 고려해야 할 사항이 있습니다. 그것은 모호한 "만약"질문을 수정하고 다음에해야 할 것을 정체하는 데 도움이됩니다.

YAGNI는 일이 완료되기 전이 아니라 완료 해야 할 때 완료되는 것을 의미 합니다. 그것은 그들이 의미하지 않는다 결코 그들이하지 않는 한하지, 해본 얻을 결코 필요하지 않습니다. 즉, 고객에게 즉각적인 비즈니스 가치를 제공하는 것만 수행한다는 의미 입니다. 즉각적인 비즈니스 가치의 의미는 모든 고객과 모든 프로젝트에 따라 다릅니다.

두 경우 모두 YAGNI로 아무것도 잃을 수 없습니다 .

다른 경우에는 사용하지 않는 코드를 작성하고, 사용하지 않는 코드에 대한 테스트를 작성하고, 사용하지 않은 코드에 대한 문서를 작성하고, 사용하지 않는 코드에 대한 유지 관리를 수행하는 데 시간이 낭비됩니다. 그리고 그것이 사용된다면, 광고 구역.

예

프로토 타입 / 개념 증명 또는 1.0 버전의 응용 프로그램을 작업하는 경우 Facebook 수준으로 확장 할 디자인이 필요하지 않습니다. 이런 종류의 트래픽 이 있음을 알기 전까지는 Facebook 수준으로 확장 할 디자인이 필요하지 않습니다 .

Zuckerberg가 5 억 명의 사용자로 확장 할 수있는 최초의 Facebook 버전을 설계했다고 생각하십니까? 그는 필요로하는 것을 원하고 더 이상하지 않기 위해 설계하고 제작했습니다. 그가 처음부터 5 억 명의 사용자를 위해 디자인을 폭포하려고 시도했다면 페이스 북은 출시 된 적이 없었을 것입니다.

일을하는 실질적인 방법은 그가 한 일입니다. 그는 PHP와 MySQL로 시작했으며 비즈니스 가치 에 따라 필요에 따라 재 설계 및 재 작성 하여 수백만 명의 사용자로 확장하는 것은 엄청난 비즈니스 가치를 지녔지 만 0 일에는 아니 었습니다. 0 일에 시작하는 것은 엄청난 비즈니스 가치였습니다.

그는 재 설계와 재 작성을 계획 했다. 부엌 싱크대를 계획하는 것과는 다른 사고 방식이며 실제로 유용한 것을 개발하거나 제공하지 않습니다.

코드베이스의 수명 종료 계획 및 재 작성은 민첩하고 미래를 보장합니다. 정의되지 않은 "유연성"이라는 목표를 세우려고하면 매번 실패로 끝납니다. 당신은 어떤 필요도없이 설계하고 시간을 낭비하며 결코 사용되지 않을 기능에 대한 꿈을 꾸지 않고 비즈니스 가치 를 개발할 수 있습니다 .

파이썬 의 선은 말한다 :

지금보다 결코 낫습니다. 결코 지금보다 더 나은 것은 없지만.

아이디어는 지금 무언가를 정의 할 수 있기 때문이 아니라는 것입니다. 지금 필요합니까?

• 예 : 지금하세요!
• 아니요 :하지 마십시오! 필요를 기다리십시오! 야 그니!

이것이 덜 명백한 경우는 리팩토링 사례입니다. 가능할 때마다 DRY를 적용해야합니까? DRY를 적용하는 데 복제보다 비용이 많이 드는 시간이 있기 때문에 답이 명확하지 않습니다. 그러나 장기적으로 기술 / 성능상의 이유가 없을 때까지 DRY를 적용하는 것이 항상 좋습니다.

따라서 YAGNI는 귀하가 할 때까지 지금 IT를 수행하십시오. 기다리지 마!

나는 그들이 전혀 놀지 않는다고 생각합니다. 나는 당신이 어느 쪽이든 다른 쪽을 기대고 있다고 생각합니다. 그리고 나는 야니에게 기대어.

그러나 가치가있는 것에 대해, 나는 "지금은 결코 낫지 않다"는 두 번째 제안에 동의하지 않습니다. 요구 사항이 중요한 경우 수행해야 할 것보다 큽니다. 따라서 "never"는 가능하지 않습니다. 중요하지 않은 경우 "지금"보다 낫지 않습니다. "never"가 더 좋습니다.

내 두 센트.

이 두 패턴은 어떻게 정사각형입니까?

그것들은 직교하며 서로 관련이 없습니다.

그들이 잘 연주하기 위해 어떤 관행을 사용합니까?

음 둘 다요? 더있을 수있는 것은 무엇입니까?

혼란을 일으키지 않고 어떻게 함께 가르 칩니까?

YAGNI는 사용자가 보는 기능을 설명합니다. 당신은 공상 필요가 없습니다.

이제 프로세스를 설명하는 것보다 낫습니다. 지금 테스트를 작성하십시오. 지금 코드를 작성하십시오. 설계 대안을 고민하는 시간을 멀리하지 마십시오. 무언가를 만드는 것에 대해 이야기하기보다는 무언가를 만드십시오.

"never"가 "not not now"의 의미라면 디자인에 결함이있는 것입니다.

로컬 결정은 나머지 시스템에 투명해야합니다.
당신이 구성 요소가있는 경우 예를 들어 CookieSource, 그건이 필요 CookieFactory턴에 CookieRecipes가로 알고 Cookies다음, 당신의 일부 입력 매개 변수를 기반으로, CookieSource하지 않아도하여 방법에 의존하지 않아야 CookieFactory구현되는 방법을 CookieRecipes표시됩니다.
(가) 경우 CookieFactory실제로 A의이다 Bakery, 그 중 하나를 사용할 수 있습니다 Recipe따르면에 Pastry문제가 안된다. 해당 기능이 필요하지 않으면 구현할 필요가 없습니다. 그리고 CookieSource사용하는 서비스와 서비스 간에 명확한 추상화 장벽이없는 경우를 제외하고는 나중에 추가 할 수없는 이유가 없습니다 .

소프트웨어를 구축 할 때는 필요에 따라 기능을 추가하고 의사 결정에 자신을 고정시키지 마십시오. 대신 결정을 적절한 추상화로 고정하십시오 .

내가 찾은 가장 간단한 해결책은 코드를 미리 작성할 때 변경 사항을 예상하는 것입니다. 부울을 함수에 전달하면 일반적으로 가능한 빨리 플래그 / 열거 형으로 변경하여 a) 더 읽기 쉽고 b) 쉽게 확장 할 수 있습니다. 마찬가지로, 하나 더 필요할 것 같은 냄새가 나는 곳 주위에 많은 매개 변수를 전달한다는 것을 알면 일반적으로 특수 구조를 만듭니다. YAGNI가 희망하지만, 어느 시점에서라도 모든 사용자를 끔찍하게 중단하지는 않으며 "불쾌한 작업"이 이미 완료되었습니다. 종종, 당신은 또한 / * future 추가가 여기 * /에 들어가는 것과 같은 주석을 추가 할 수도 있습니다. 그래서 아직 구현되지 않았지만 여기에 추가 할 곳이 있습니다. 나중에 인터페이스 리팩토링이 가장 많은 시간을 소비한다는 것을 알았으므로 일반적으로 가장 도움이됩니다.

향후 확장을 염두에두고 디자인하지만 필요할 때까지 확장을 구현하지 마십시오.

염두에 두는 예는 Netflix가 처음 시작되었을 때 각 계정과 연결된 대기열을 하나만 가질 수 있다는 것입니다. 그들은 나중에 여러 대기열 지원을 해킹했습니다. 처음부터 그런 방식으로 설계되지 않았기 때문에 유지 관리가 점점 어려워 져서 그 기능을 중단하기로 결정했습니다. 고객이 소란을 낸 후 총알을 깨고 여러 대기열을 올바르게 통합하도록 재 설계했습니다.

처음에 누군가가 나중에 여러 개의 대기열을 원할 가능성을 허용했다면 단기적인 노력만으로도 장기적인 슬픔을 덜 수 있었을 것입니다. 실제로 여러 대기열을 즉시 구현할 필요는 없었습니다. 대규모 재 작성이나 유지 관리 할 수없는 해킹이 필요하지 않은지 확인하십시오.

표면적으로는 미래의 요구 사항을 예측하는 점쟁이와 같은 능력을 필요로하는 것처럼 보이지만 실제로는 프로그래머가 무언가를 하드 코딩하거나 데이터베이스 테이블이라는 것을 알면 좋은 프로그래머에게 집중되는 경향이 있습니다. 애매하게 관련된 많은 열만 수집합니다.