기존 코드에서 버그를 수정하는 경우 코드에서 "실수"를 찾고 실수를 방지하기 위해 코드를 조정하는 습관에 빠지기 쉽습니다. 그러나 문제의 근본 원인이 디자인 오류 또는 알고리즘문제인 경우 코드에 다른 플래그 또는 goto 문을 추가하는 것만으로도 잘못된 방법입니다. 근본 원인을 그대로 유지했을 뿐만 아니라 이제 코드를 파악해야 하는 다음 소프트웨어 엔지니어를 이해하기 가 더 어려워졌습니다.
"내가 원래 코더라면 어떻게 이 문제를 해결했겠는가?" 하고 물어보도록 훈련한다. 그런 다음 "깨끗한 종이" 접근 방식과 실제로 앞에 있는 접근 방식의 차이점을 살펴보십시오. 그러나 실용적이어야 합니다. 나는 확실히 당신과 저자가 다른 접근 방식을 가지고 있기 때문에 함수를 다시 구현해야한다고 제안하지 않습니다. 이 단계를 생각 실험으로 수행하십시오. 실패한 테스트 사례가 있습니다. 저자는이 경우를 놓쳤다. 무엇이 그녀를 이 사건을 놓치게 한 가? 저자가 이 사건에 대해 알고 있었다면, 그녀의 접근 방식은 어떻게 달라졌을까요? 이러한 유형의 질문은 기본적으로 작동하지만 여전히 몇 가지 버그가있는 코드를 파고 들 때 매우 중요합니다.
이 경우 내부 함수에 다른 매개 변수를 추가하고 주 절차에 3개의 다른 항목지점에서 올바르게 초기화해야 하는 또 다른 자동 변수를 추가하고 중요한 지점에서 이 새 변수를 테스트하는 코드를 추가하는 대신 하위 단계가 수행된 순서를 변경하여 알고리즘을 복구할 수 있다는 것을 깨달았습니다. 일단 우리가 그렇게 하면 추가 변수와 특수 사례에 대한 필요성이 사라졌습니다. 최종 코드는 실제로 복구에서 첫 번째 시도의 아무 말도, 원래 코드보다 이해하기 훨씬 쉽습니다. 이것은 우리가 올바른 궤도에 있다는 자신감을 줍니다. 문제를 재현하는 테스트 사례는 원본(지나치게 복잡한) 수정과 수정된(단순화된) 수정 모두 문제를 해결하는 것으로 입증되었습니다. 이제 우리는 다른 것을 깨지 않았다는 것을 확신해야합니다.
이 수정 프로그램은 필드 릴리스(예: 고객 위치에 이미 설치된 테스트)로 향하고 있으므로 세 가지 유형의 집중 회귀 테스트도 실행됩니다. 그 중 두 가지는 POSIX 표준에 대한 지속적인 준수를 확인합니다 (버그 수정은 POSIX 기능을 구현하는 코드에 있음), 세 번째 유형의 테스트는 일반 시스템 수준의 회귀 테스트입니다.
알고리즘을 먼저 수정합니다. 알고리즘이 정확하면 코드를 처리합니다.
회사