피처 교차 다루기

최근 에이 기사 에서 기능 교차점에 설명 된 것과 유사한 문제가 점점 더 많이 목격되었습니다 . 다른 제품이라는 용어는 실제로는 다른 제품으로 귀속되는 경향이 있지만 일반적으로 가능한 제품 구성의 형태로 이러한 문제가 발생합니다.

이 유형의 문제에 대한 기본 개념은 간단합니다. 제품에 기능을 추가하지만 다른 기존 기능의 조합으로 인해 문제가 복잡 해지는 경우가 있습니다. 결국 QA는 이전에 아무도 생각하지 못했던 간단한 기능과 단순한 버그 수정 기능이 중대한 설계 변경을 요구할 수있는 기능의 조합으로 인해 문제를 발견했습니다.

이 피처 교차 문제의 크기는 매우 복잡합니다. 현재 소프트웨어 버전에 N기능이 있으며 새로운 기능 하나를 추가 한다고 가정 해 봅시다 . 또한 각 기능을 켜거나 끌 수 있다고 말하면 작업을 단순화하고 이미 2^(N+1)고려할 수있는 기능 조합 이 있습니다. 더 나은 단어 / 검색어가 없기 때문에 이러한 조합이 특징 교차 문제 라고 언급합니다 . (확실한 용어에 대한 참조를 포함한 답변에 대한 보너스 포인트.)

이제 제가 고심해야 할 문제는 개발 프로세스의 각 수준에서 이러한 복잡성 문제를 해결하는 방법입니다. 명백한 비용상의 이유로, 각 조합을 개별적으로 다루기를 원하는 것은 유토피아적인 시점까지 비현실적입니다. 결국, 우리는 정당한 이유 때문에 지수 복잡성 알고리즘을 피하려고 노력하지만, 개발 과정 자체를 지수 크기의 괴물로 바꾸는 것은 완전히 실패로 이어질 수밖에 없습니다.

따라서 예산을 폭발시키지 않고 적절하고 유용하며 전문적으로 수용 가능한 방식으로 완성 된 체계적인 방식으로 최상의 결과를 얻는 방법은 무엇입니까?

• 사양 : 새로운 기능을 지정할 때-다른 모든 자식과 잘 작동하는지 어떻게 확인합니까?

  새 기능과 함께 기존의 각 기능을 체계적으로 검사 할 수 있지만 다른 기능과는 별개입니다. 일부 기능의 복잡한 특성을 고려할 때이 분리 된 뷰는 이미 너무 복잡 2^(N-1)하여 기꺼이 무시한 다른 기능으로 인한 요인 은 물론 구조적 접근 방식 자체가 필요합니다 .

• 구현 : 기능을 구현할 때 코드가 모든 경우에 올바르게 상호 작용 / 교차하는 방법은 무엇입니까?

  다시 한번, 나는 복잡한 복잡성에 대해 궁금합니다. 두 가지 교차 기능의 오류 가능성을 줄이는 다양한 기술을 알고 있지만 합리적인 방식으로 확장 할 수있는 기술은 없습니다. 그러나 사양 중 좋은 전략은 구현 중에 문제를 억제해야한다고 가정합니다.

• 확인 : 피쳐를 테스트 할 때이 피쳐 교차 영역의 일부만 테스트 할 수 있다는 사실을 어떻게 처리합니까?

  단일 기능을 단독으로 테스트하면 오류가없는 코드 근처에서 아무 것도 보장 할 수 없다는 것을 알기는 어렵지만 2^-N수백 가지의 테스트로 인해 모든 해양에서 한 방울의 물을 덮지 않는 것처럼 보입니다. . 더 나쁜 것은 가장 문제가 많은 오류는 기능의 교차로 인해 발생하는 오류로, 문제가 발생하지 않을 것으로 예상되지만 강한 교차가 예상되지 않으면 어떻게 테스트합니까?

다른 사람들이이 문제를 어떻게 다루고 있는지 듣고 싶지만, 주제를보다 깊이있게 분석하는 문헌이나 기사에 주로 관심이 있습니다. 따라서 개인적으로 특정 전략을 따르는 경우 답변에 해당 출처를 포함시키는 것이 좋습니다.

우리는 이미 정지 문제로 인해 프로그램의 검증이 가장 일반적인 경우 유한 한 시간 내에 불가능하다는 것을 수학적으로 알고있었습니다. 이런 종류의 문제는 새로운 것이 아닙니다.

실제로, 우수한 설계는 교차 피쳐의 수가 2 ^ N보다 훨씬 적도록 디커플링을 제공 할 수 있지만, 잘 설계된 시스템에서도 확실히 N보다 높은 것으로 보입니다.

소스에 관해서는, 소프트웨어 디자인에 관한 거의 모든 책이나 블로그가 가능한 한 2 ^ N을 줄이려고 노력하고있는 것 같습니다. 하다.

이 기사에서 디자인이 어떻게 도움이 될 수 있는지에 대한 예를 들어, 기사에서 eTag에서 복제와 색인 생성이 모두 트리거되어 일부 기능 교차가 발생했다고 언급했습니다. 이들이 개별적으로 각각의 필요성을 알리기 위해 다른 통신 채널을 사용할 수 있다면 이벤트 순서를보다 쉽게 ​​제어 할 수 있었으며 문제가 더 적었을 수 있습니다.

아니면 아닐 수도 있습니다. 나는 RavenDB에 대해 아무것도 모른다. 피처가 실제로 서로 얽히게되면 아키텍처는 피처 교차 문제를 방지 할 수 없으며, 2 ^ N 교차의 최악의 경우를 피할 수있는 피처를 미리 알 수 없습니다. 그러나 아키텍처는 구현 문제로 인해 최소한 교차를 제한 할 수 있습니다.

RavenDB와 eTag에 대해 틀렸어도 (그리고 논증을 위해 그것을 사용하고 있습니다-그들은 똑똑한 사람들이고 아마도 그것을 얻었을 것 입니다.) 아키텍처 가 어떻게 도울 수 있는지 분명해야합니다 . 사람들이 이야기하는 대부분의 패턴은 새로운 기능이나 변경되는 기능에 필요한 코드 변경 횟수를 줄이기 위해 명시 적으로 설계되었습니다. 예를 들어 "디자인 패턴, 재사용 가능한 객체 지향 소프트웨어의 요소"와 같은 소개에서는 "각 디자인 패턴을 사용하면 아키텍처의 일부 측면이 다른 측면과 독립적으로 달라질 수 있으므로 특정 유형의 시스템에보다 강력한 시스템을 만들 수 있습니다" 변화".

내 요점은 실제로 실제로 일어나는 일을 살펴보면 실제로 피쳐 교차점의 Big O에 대한 감각을 얻을 수 있다는 것입니다. 중 - (생산성 예) 발견이 대답을 연구, 나는 기능 점수 / 개발 노력의 대부분의 분석을 발견 덜 아주 약간 선형 성장 위의 선형 함수 포인트 당 프로젝트 노력의 성장, 또는보다. 나는 조금 놀라운 것을 발견했다. 이것은 꽤 읽기 쉬운 예입니다.

이 (그리고 비슷한 연구들 중 일부는 코드 라인 대신 함수 포인트를 사용합니다)는 기능 교차가 발생하지 않고 문제를 유발한다는 것을 증명하지는 않지만 실제로 파괴적이지 않다는 합리적인 증거처럼 보입니다.

이것은 어떤 방법으로도 최선의 대답은 아니지만, 귀하의 질문의 요점과 교차하는 것들에 대해 생각하고 있으므로 언급 할 것이라고 생각했습니다.

구조적 지원

제가 아는 바로는, 기능이 버그가 있거나 다른 기능과 잘 맞지 않는 경우 기능 관리 / 조정을위한 프로그램의 핵심 구조 / 프레임 워크에 의해 제공되는 지원이 부족하기 때문입니다. 더 많은 시간을 플레잉하고 코어를 반올림하면 새로운 기능의 추가가 쉬워 질 것이라고 생각합니다.

내가 일하는 응용 프로그램에서 공통적 인 것으로 밝혀진 한 가지는 프로그램의 구조가 일종의 객체 또는 프로세스 중 하나 를 처리하도록 설정 되었지만 우리가 수행하거나 수행하려는 많은 확장 프로그램입니다. 많은 종류의 처리와 관련이 있습니다. 응용 프로그램 디자인 초기에이 점을 더 고려했다면 나중에 이러한 기능을 추가하는 데 도움이되었을 것입니다.

스레드 / 비동기 / 이벤트 중심 코드가 포함 된 여러 X에 대한 지원을 추가 할 때 매우 중요합니다. 왜냐하면 그 물건은 매우 빨리 나빠질 수 있기 때문입니다. 이와 관련된 많은 문제를 디버깅하는 기쁨을 얻었습니다.

비록 프로토 타입이나 일회성 프로젝트에서 이러한 종류의 노력을 미리 정당화하기는 어려울 것입니다. 이는 지출이 장기적으로 가치가 있었음을 의미합니다.

디자인

프로그램의 핵심을 설계 할 때 하향식 접근 방식으로 시작하면 사물을 관리 가능한 덩어리로 바꾸고 문제 영역을 둘러 쌀 수 있습니다. 그 후 상향식 접근 방식을 사용해야 한다고 생각합니다. 이렇게하면 작업을 더 작고 유연하며 나중에 추가 할 수 있습니다. (링크에서 언급했듯이, 이런 방식으로 작업을 수행하면 기능 구현이 더 작아 져 충돌 / 버그가 줄어 듭니다.)

시스템의 핵심 빌딩 블록에 중점을 두어 시스템이 모두 제대로 상호 작용하는지 확인하면 시스템을 사용하여 구축 한 모든 항목이 올바르게 작동하고 나머지 시스템과 더 잘 통합되어야합니다.

새로운 기능이 추가되면 프레임 워크의 나머지 부분을 디자인 할 때와 비슷한 경로를 디자인 할 수 있다고 생각합니다. 기능을 구현할 때 프레임 워크에서 원래 블록을 재사용 할 수 있다면 분명히 도움이 될 것입니다. 완료되면 기능에서 얻은 새로운 블록을 이미 핵심 프레임 워크에있는 블록에 추가하고 원래 블록 세트로 테스트하여 다른 시스템과 호환되고 향후 사용할 수 있습니다. 기능도 있습니다.

단순화하십시오!

나는 문제를 단순화 한 다음 솔루션을 단순화하는 것으로 시작하여 늦게 디자인에 대한 미니멀리스트 입장을 취했습니다. 프로젝트에서 디자인 반복을 단순화하는 데 시간이 걸린다면 나중에 추가 할 때 매우 유용하다는 것을 알 수있었습니다.

어쨌든, 그것은 나의 2c입니다.