향후 변경을위한 설계 또는 당면한 문제 해결 [폐쇄]

코드를 작성하거나 디자인하는 동안 첫 번째 인스턴스 자체에서 문제를 일반화하거나 매우 구체적인 문제를 해결하려고합니다.

문제를 일반화하려고하면 문제가 복잡해지기 때문에 (필요하지 않을 수도 있음) 요구 사항이 변경되면 특정 솔루션을 확장하는 것이 매우 어려울 수 있기 때문에 이것을 묻습니다.

해결책은 중간 경로를 찾는 것보다 쉬운 것이라고 생각합니다. 이 유형의 문제를 어떻게 해결합니까? 어떤 시점에서 일반화를 시작하면이 일반화가 충분하다는 것을 알고 있습니까?

미래를 위해 디자인하려고 할 때 너무 자주, 미래의 요구에 대한 예측이 잘못되었습니다. 처음에는 시스템을 과도하게 디자인하는 것보다 요구 사항이 어떻게 바뀌 었는지 실제로 알 때 리팩토링하는 것이 좋습니다. 동시에 발로 자신을 쏘지 마십시오. 확실히 중간 근거가 있으며 그것이 과학보다 예술이 어디에 있는지 아는 것입니다.

이것을 한 규칙으로 요약하자면 : 적을수록 좋습니다.

애자일에 익숙하십니까? 애자일의 큰 원칙 중 하나는 YAGNI 입니다. 나는 그것이 접근하는 가장 좋은 방법이라는 것을 알았습니다.

"필요하지 않을 것입니다." ... 프로그래머 는 익스트림 프로그래밍 (XP) 의 원칙으로, 필요하다고 판단 될 때까지 프로그래머가 기능을 추가해서는 안된다고 말합니다. Ron Jeffries 는 다음과 같이 말합니다. "실제로 필요할 때 항상 구현하고 필요할 때 예측하지 않는 경우에는 항상 구현하십시오."

... YAGNI는 XP가 "가장 간단한 일을 할 것"(DTSTTCPW)을 실천하는 원칙입니다. 이는 지속적인 리팩토링 , 지속적인 자동화 된 유닛 테스트 및 지속적인 통합 과 같은 다른 몇 가지 관행과 결합하여 사용됩니다 . 지속적인 리팩토링없이 사용하면 지저분한 코드와 대규모 재 작업이 발생할 수 있습니다. 지속적인 리팩토링은 자동화 된 단위 테스트를 안전망 (예상치 못한 버그를 감지하기위한) 및 지속적인 통합으로보다 광범위한 통합 문제를 방지합니다 ...

YAGNI는 지원 관행과 함께 유효한 원칙으로 보편적으로 인정되지 않습니다. 독립 실행 형이 아닌 지원 실무와 결합해야 할 필요성은 XP 의 원래 정의의 일부입니다 ...

"YAGNI"와 "PYIAC"(코너로 페인트하기) 사이를 연결해야하기 때문에 이것은 아마도 소프트웨어 개발에서 가장 어려운 부분 중 하나 일 것입니다.

"필요하지 않으면 기능을 작성하지 마십시오"라고 말하기 쉽습니다. 어려운 부분은 나중에 필요할 때 쉽게 기능을 추가 할 수 있도록 코드를 디자인하는 것입니다.

핵심은 현재 필요한 것보다 더 많은 코드를 작성하지 않는 확장 가능한 아키텍처를 설계하는 것입니다. 이를 잘 수행하는 능력은 실제로 많은 경험과 고통에서 비롯됩니다.

나는 디자인의 일반적인 방향에 대해 미리 생각하는 데 시간이 많이 걸리지 않습니다. 그런 다음 TDD를 사용하여 스토리 기반 민첩한 방법론을 따라 개별 스토리에 대한 솔루션을 개발합니다. TDD를 통해 구현할 때 높은 수준의 개요를 염두에두고 (a) 특정 구현을 지시하여 높은 수준의 개요를 따르거나 (b) 높은 수준의 이해 / 방향을 리팩토링하고 개선합니다. 테스트 / 구현 중에 배운 것.

나는 미리 계획하지 않는 것이 실수라고 생각하지만 너무 많은 일을하는 것은 아마도 더 큰 일 일 것입니다. 가능한 한 큰 그림으로 안내해 드리겠습니다. 그런 다음 응용 프로그램이 어떻게 개발 될지에 대해 마음 속에 배치 한 선을 따라 디자인이 유기적으로 커지도록하겠습니다. TDD를 사용하면 디자인 자체가 더 나은 디자인 원칙 (분리, 단일 책임 등)으로 강요되고 전체를 미리 생각하고 개발에 적용하려고 시도하는 것보다 변경과 관련하여 가단성이 있다는 것을 알았습니다.

좋은 디자인은 미래의 변화를 수용하고 확실히 가치가 있습니다. UNIX 운영 체제와 "모든 것이 파일 철학"이라고 생각하십시오. 이 디자인 결정은 즉각적인 요구를 충족시키기위한 것이 아니라 향후 요구 사항을 고려하여 이루어졌습니다. "애자일 (agile)"설계에 기반한 운영 체제가 어떻게 보일지에 대해 생각하는 사람이 있습니다.

당신이 다루려고하는 것은 재사용과 관련이 있습니다 (즉, 현재 다루고있는 문제의 일반화로 나중에 작업 (코드)을 재사용 할 수 있습니다). 나는 전에 그것을 말했고 나는 그것을 다시 연결할 것이다 .

다른 사람들이 다음과 같은 효과에 대해 말하는 것을 들었습니다.

처음으로 문제를 해결했습니다. 솔루션을 처음 반복 할 때 참고합니다. 다시 반복하면 리팩터링됩니다.

"지금 + 1"을위한 디자인. 즉, 당면한 문제를 즉시 해결하고 다음 번에 변경을 요청할 때 이미 절반 이상 (또는 그 이상)을 수행하고 다음 중 하나를 선택할 수 있도록 충분한 기능을 구축하십시오. 나중에 리팩토링하거나 b) "now + 1"을 다시 해결합니다 ( "now"절반이 완료된 상태).

이것은 프로젝트에 달려 있으며, 간단히 말하면 경험은 "+1"이 무엇인지 가르쳐 줄 것입니다.

YAGNI 의 철학 , 당신은 그것을 필요로하지 않을 것입니다 : 기사에서 요약 할 수 있습니다 :

YAGNI 접근 방식을 옹호하는 사람들에 따르면, 현재로서는 필요하지 않지만 앞으로있을 수있는 코드를 작성하려는 유혹에는 다음과 같은 단점이 있습니다.

• 소요 시간은 필요한 기능을 추가, 테스트 또는 개선하는 데 소요됩니다.
• 새로운 기능은 디버깅, 문서화 및 지원되어야합니다.
• 새로운 기능은 향후 수행 할 수있는 작업에 제약을가하므로 불필요한 기능으로 인해 나중에 필요한 기능을 구현하지 못할 수 있습니다.
• 기능이 실제로 필요할 때까지 기능을 완전히 정의하고 테스트하기가 어렵습니다. 새 기능이 올바르게 정의 및 테스트되지 않은 경우 결국 필요하더라도 제대로 작동하지 않을 수 있습니다.
• 코드 팽창으로 이어집니다. 소프트웨어가 커지고 복잡해집니다.
• 사양과 어떤 종류의 개정 관리가 없으면 기능을 사용할 수있는 프로그래머에게는이 기능이 알려지지 않을 수 있습니다.
• 새로운 기능을 추가하면 다른 새로운 기능이 제안 될 수 있습니다. 이 새로운 기능들도 구현된다면, 크리핑 기능에 눈덩이 효과가 생길 수 있습니다.

나는 당면한 문제에 대한 디자인을 믿고 있으며 "언젠가 필요할지도 모르기 때문에"충족시켜야 할 모든 사례를 추측하여 디자인을 날려 버리지 않습니다.

기본적으로 특정 요구 사항 목록이 주어지면 디자인을 요구하지만 다음과 같이해서는 안됩니다.

• 솔루션에서 이러한 측면을 하드 코딩하는 대신 디자인 측면을 구성 할 수 있습니다. 런타임시 또는 전달시 (또는 HUP 후) 외부 구성 읽기를 통해 전달 된 매개 변수를 통해.
• 마법의 숫자로 코드를 묶고
• 기존 솔루션과 새로운 요구 사항에 적합한 접근 방식을 제공하기 위해 기존 솔루션을 수정 한 후에 재사용 할 수있는 이미 작성된 것이 있는지 확인하지 마십시오.

"가능한 미래"를 설계 할 때의 주요 문제는 항상 추측 만한다는 것입니다. 교육받은 추측을 할 수도 있지만 "밀어 넣을 때"는 여전히 일련의 추측 일뿐입니다.

이렇게하면 알려진 요구 사항에 의해 정의 된 특정 문제를 해결하기보다는 일반적인 경우에 맞게 솔루션을 압축 할 수있는 가능성이 매우 높아집니다.

그게 무슨 소리 야? "당신이 가진 모든 것이 망치 일 때, 모든 것이 못처럼 보이기 시작합니다."

누군가가 다음과 같이 말하는 것을들을 때마다 파운드가 있었으면 좋겠다. "하지만 나중에 볼 수있는 일반적인 경우에 더 적합한 솔루션입니다."