특정 사례를 해결하는 것보다 일반화 된 솔루션을 선호하는 경우

프로그래밍에서 우리는 종종 선택에 직면하게됩니다 : 생각할 수있는 각 사용 사례를 개별적으로 다루거나 일반적인 문제를 해결하십시오 :

즉각적인 문제를 해결하는 것이 더 빠르다는 것은 명백하지만, 일반화 된 솔루션을 만들면 향후 시간이 절약됩니다.

유한 한 사례 목록을 시도하고 다루는 것이 최선인지, 또는 모든 가능성을 다루는 일반적인 시스템을 만드는 것이 언제인지 어떻게 알 수 있습니까?

먼저, 당신은 소금을 전달합니다. 그런 다음 후추를 전달합니다. 그런 다음 강판에 파 르 마 치즈를 전달합니다. 이 시점에서 일반적인 조미료 전달 시스템을 개발하기에 충분한 경험이 있습니다.

동일한 방식으로 소프트웨어 프로젝트에서 작동합니다. 일반화 된 시스템에 대해 학습 단계로 개발 한 특수 목적 시스템을 사용하십시오. 따라서 범용 시스템을 시작할 때가되면 구축중인 제품에 대한 자신감이 높아집니다. 벨트 아래에 여러 특수 시스템이 있습니다.

유한 한 사례 목록을 시도하고 다루는 것이 최선인지, 또는 모든 가능성을 다루는 일반적인 시스템을 만드는 것이 언제인지 어떻게 알 수 있습니까?

경험.

알 수있는 유일한 방법은 한 경로를 시도해보고 엉덩이에서 어떻게 당신을 물리 쳤는지 보았습니다 (또는 많은 시간을 낭비했습니다). 엉덩이가 덜 들릴 때까지 반복하십시오.

그럼에도 불구하고, 당신은 정말로 모른다 ; 당신은 더 나은 추측이 있습니다.

dasblinkenlight 및 Paddy3118 의 답변을 바탕 으로 구현해야 할 사례가 여러 개인 경우 일반화 할 필요가 없습니다! XKCD 만화가 재밌는 이유는 그것이 조기 일반화를 초월하기 때문 입니다. 소금을 통과하라는 요청을 받았을 때, 보이지 않는 캐릭터는 모든 첫 번째 캐릭터가 소금 일 때 즉시 "임의의 조미료를 통과시키는 시스템 개발"로 도약합니다. 우리 모두가 조기 일반화 사례를 본 것으로 생각하기 때문에 이것은 개발자에게 좋은 농담입니다.

조기 일반화에 반대하는 원칙은 YAGNI (You Ai n't Gonna Need It)입니다. 웹에는 이것에 대한 많은 자료가 있지만 기본적으로 YAGNI는 실제로 여러 유스 케이스가 실제로 나타나지 않을 수있는 가능성을 포함하여 여러 실제 유스 케이스의 이점없이 일반화 할 때 많은 위험을 지적합니다. 또는 더 미묘하게도 실제 사용 사례가 없기 때문에 미래에 필요한 것에 대해 가정해야합니다. 이러한 가정은 틀릴 수도 있고 종종 틀릴 수도 있습니다.

작은 것에서는 일반적으로 사용하는 것이 더 쉽습니다. 예를 들어 어떤 유형의 쌍을 처리 하는 합리적인 사전 클래스를 만들 수있을 때 정수를 문자열로 매핑하는 조회 테이블을 처리하는 클래스를 만들지 마십시오 (첫 번째 유형은 일부 유형을 지원합니다) 비교).

이전의 삶에서 나는 지속적인 웹 소재를 다루는 기계류에 대한 많은 산업 자동화 프로젝트를 수행했습니다. 철강, 알루미늄, 종이, 플라스틱, ... 중간에 유용한 것을 수행 한 후 한쪽 끝을 풀고 다른 쪽 끝을 다시 감습니다. 한 산업에서는 "언 와인 더"가 아니라 "지불 릴"에서 시작합니다. 잘못된 용어를 사용하면 고객의 수백만 달러의 눈에 바보가됩니다. 하나의 프로젝트에서 다음 프로젝트로 재사용하기 위해 추상화 할 수있는 것이 거의 없다는 것에 놀랄 것 입니다. OTOH는 종종 시작점으로 프레임 워크 또는 템플릿을 만들 수 있습니다. 현재 작업에 맞게 사용자 정의되었지만 최소한 이전 프로젝트에서 학습하는 이점이있었습니다. 그리고 팀의 모든 사람들이 우리가 어디에서 출발했는지 알았습니다.

한 번, 두 번, 세 번, 일반화하십시오.

하나, 둘, 많은!

두 번째 경우에는 일반화에 대해 생각해야합니다. 세 번째를 요청하면 일반 코드에서 코드를 제공하고 이전에 개별적으로 해결 된 첫 번째 및 두 번째 사례를 테스트 사례로 사용해야합니다.