특수 사례 및 휴리스틱을 관리하는 방법

StackOverflow https://stackoverflow.com/questions/958003

  •  12-09-2019
  •  | 
  •  

문제

나는 종종 잘 정의된 특정 알고리즘을 기반으로 하는 코드를 가지고 있습니다.이것은 댓글이 잘 달렸고 적절한 것 같습니다.대부분의 데이터 세트에서 알고리즘은 훌륭하게 작동합니다.

그러나 특정 데이터 세트의 특정 문제를 해결하기 위해 엣지 케이스, 특수 케이스, 휴리스틱이 추가됩니다.특수한 경우가 많아질수록 댓글이 점점 더 흐릿해집니다.나는 1년 정도 후에 이 코드를 다시 살펴보며 각각의 특별한 경우나 경험적 방법이 추가된 이유를 기억하려고 노력하는 것이 두렵습니다.

나는 때때로 소스 코드에 그래픽을 포함하거나 링크하는 방법이 있었으면 좋겠다고 생각합니다. "이 데이터 세트의 그래프에서 이 특정 기능으로 인해 루틴이 잘못 트리거되었습니다. 그래서 이 부분이 이 부분에서 발생했습니다. 코드가 추가되었습니다."

이와 같은 상황을 처리하는 모범 사례는 무엇입니까?

이러한 비정상적이거나 극단적인 경우를 처리하려면 항상 특수한 경우가 필요한 것 같습니다.코드를 상대적으로 읽기 쉽고 이해하기 쉽게 유지하려면 어떻게 관리해야 합니까?

사진의 특징 인식을 다루는 예를 생각해 보세요(정확히 제가 작업하고 있는 작업은 아니지만 비유가 적절해 보입니다).일반적인 알고리즘이 실패하고 특별한 경우가 필요한 특정 그림을 발견하면 가능한 한 해당 정보를 주석(또는 아래에서 제안한 것처럼 설명 함수 이름)에 기록합니다.그러나 종종 누락되는 것은 문제의 동작을 나타내는 특정 데이터 파일에 대한 영구 링크입니다.내 의견은 문제를 설명해야 하며 "이 동작의 예는 foo.jp 파일을 참조하세요"라고 말할 수 있지만 이 파일은 소스 트리에 없으며 쉽게 손실될 수 있습니다.

이런 경우 사람들은 참조를 위해 소스 트리에 데이터 파일을 추가합니까?

도움이 되었습니까?

해결책

프로젝트에 대한 지식 기반이나 위키가 있는 경우 여기에 그래프를 추가하고 다음과 같은 방법으로 연결할 수 있습니다. 매튜의 파울러 인용문e 및 엣지 케이스 변경에 대한 소스 제어 커밋 메시지에도 있습니다. 

//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
   //modify param to solve for edge case
   return param;
}

Commit Message: Solution for X and Y edge case, see description at KB#2312

더 많은 작업이 필요하지만 단순한 테스트 사례나 설명보다 더 철저하게 사례를 문서화하는 방법입니다.테스트 사례가 충분히 문서화되어야 한다고 주장할 수도 있지만, 예를 들어 실패한 데이터 세트 전체를 여기에 저장하고 싶지 않을 수도 있습니다.

모호한 문제는 모호한 해결책으로 이어진다는 점을 기억하십시오.

다른 팁

Martin Fowler는 자신의 리팩토링 책에서 코드에 주석을 추가해야 한다고 느낄 때 먼저 해당 코드를 메서드에 캡슐화하고 메서드에 주석을 대체할 이름을 지정할 수 있는지 확인하라고 말했습니다.

추상적으로 이름이 지정된 메서드를 만들 수 있습니다.

private bool ConditionXAndYHaveOccurred(object param)
{
   // code to check for conditions x and y
   return result;
}

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param)
{
   //modify param to solve for edge case
   return param;
}

그런 다음 다음과 같은 코드를 작성할 수 있습니다.

if(ConditionXAndYHaveOccurred(myObject))
{
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject);
}

어렵고 빠른 구체적인 예는 아니지만 1~2년 안에 가독성에 도움이 될 것입니다.

단위 테스트가 여기에 도움이 될 수 있습니다.특별한 경우를 실제로 시뮬레이션하는 테스트를 통해 코드가 해당 작업을 수행하는 이유에 대한 문서 역할을 할 수 있는 경우가 많습니다.댓글로 문제를 설명하는 것보다 이것이 더 나을 수도 있습니다.

이것이 특별한 경우 처리를 자체 기능과 적절한 주석으로 옮기는 것을 대체하는 것은 아닙니다.

나는 일반적으로 테스트 중심 개발 및 테스트에 너무 많은 스트레스를 주는 유사한 스타일을 옹호하는 것은 아니지만 이것은 여러 단위 테스트가 많은 도움이 될 수 있는 완벽한 사례인 것 같습니다.그리고 나중에 변경된 버그를 처음부터 잡아내는 것이 아니라 단순히 해결해야 하는 모든 특별한 경우를 문서화하기 위한 것입니다.

주석이 포함된 몇 가지 좋은 단위 테스트는 그 자체로 특별한 경우에 대한 가장 좋은 설명입니다.그리고 코드 자체에 대한 주석 달기도 더 쉬워졌습니다.코드의 해당 지점에서 해결 중인 문제를 설명하는 일부 단위 테스트를 간단히 가리킬 수 있습니다.

대한

때때로 소스 코드에 그래픽을 포함 시키거나 링크하는 방법이 있었으면 좋겠다. "이 데이터 세트의 그래프 에서이 특정 기능은 루틴이 잘못 트리거되게했기 때문에이 부분이 그 이유입니다. 코드가 추가되었습니다. ".

부분:

삽입하려는 "그래픽"이 그래프이고, 독시젠, 삽입할 수 있습니다 점 문서에서 그래프를 생성하려면 의견에 다음 명령을 입력하세요.

/**
If we have a subgraph looking like this:
\dot
digraph g{
A->B;
A->C;
B->C;
}
\enddot
the usual method does not work well and we use this heuristic instead.
*/

돈 크누스가 발명한 프로그래밍을 읽고 쓸 줄 아는 플롯, 그래프, 차트, 수학 방정식 및 이해를 돕기 위해 필요한 모든 것을 프로그램 문서에 쉽게 포함시킬 수 있습니다.읽고 쓸 수 있는 프로그램은 어떤 것이 현재의 방식인 이유와 시간이 지남에 따라 어떻게 그렇게 되었는지 설명하는 좋은 방법입니다.읽고 쓸 수 있는 프로그래밍 도구는 아주 많습니다."noweb" 도구는 가장 간단한 도구 중 하나이며 일부 Linux 배포판과 함께 제공됩니다.

문제의 구체적인 성격을 알지 못한 채 답변을 드리기는 쉽지 않지만 제 경험상 하드코드에 대한 특수한 경우의 처리는 피해야 합니다.기본 처리 알고리즘 외부의 특수한 경우를 처리하기 위해 규칙 엔진이나 이와 유사한 구현에 대해 생각해 본 적이 없습니까?

단순한 코드 주석보다 더 철저한 문서화가 필요한 것 같습니다.그렇게 하면 누군가 문서에서 문제의 함수를 찾아보고 특별한 경우가 필요한 예제 그림이 제시될 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top