버그 수정을 위한 12가지 주요 단계

보스: 그럼 이 버그를 고치는 데 얼마나 걸리나요?

미숙한 프로그래머: 한 시간만 주실래요? 최대 2시간? 바로 끝낼 수 있어요!

경력 프로그래머: 이렇게 말하면 물고기를 잡는 데 얼마나 걸리나요? !

버그를 수정하는 데 시간이 얼마나 걸릴지 미리 알기는 어렵고, 특히 코드를 처음 접하는 경우 상황은 더욱 혼란스럽습니다. James Shore는 "The Art of Agile"이라는 책에서 문제를 해결하려면 먼저 문제가 무엇인지 알아야 한다고 분명히 지적합니다. 시간을 정확하게 예측할 수 없는 이유는 핵심을 찾는 데 시간이 얼마나 걸릴지 모르기 때문입니다. 이것만 알면 버그 수정에 걸리는 시간을 합리적으로 예측할 수 있습니다. 그런데 이 시간에는 원추리꽃이 벌써 추워진 것 같아 걱정스럽습니다. Steve McConnell은 다음과 같이 말했습니다.

"문제 찾기 - 문제 이해 - 이것이 프로그래머 업무의 90%입니다."

많은 버그는 특정 코드 줄만 변경하면 됩니다. 하지만 많은 시간이 필요한 것은 나중에 무엇이 올바른지 알아내야 한다는 것입니다. 마치 낚시를 할 때 미끼를 어디에 놓아야 할지, 물고기가 미끼를 잡기 쉬운 때 등을 알아야 하는 것처럼 말입니다. 버그에는 네 가지 유형이 있다고 합니다. 첫 번째 유형은 찾기 쉽고 고치기 쉽고, 두 번째 유형은 찾기 어렵지만 고치기 쉽고, 세 번째 유형은 찾기 쉽고 고치기 어렵습니다. 유형은 찾기도 어렵고 고치기도 어렵습니다. 가장 비극적인 것은 마지막 유형이다. "찾고 찾아도 황량하고 황폐하다", 온갖 고생 끝에 마침내 돌을 뚫고 나가도 무의식적으로 거기만 긁힐 수밖에 없고, 무기력하게 한숨을 쉬었습니다. "길은 길고 멀다." 새로 출시된 코드가 아닌 이상 버그를 찾는 것은 맹인이 코끼리를 느끼는 것과 같다고 할 수 있습니다. 혼란스럽고 어떤 버그 유형에 속하는지 알 수 없습니다.

버그 찾기 및 수정

"버그 찾기 및 수정"이 무슨 뜻인지 아시나요? 그렇죠, 디버깅이에요! 끊임없는 디버깅, 수많은 디버깅! 광범위한 작업을 통해 Paul Butcher는 다음과 같은 구조화된 단계를 요약했습니다.

1. 목적을 명확히 합니다. 예외 보고서를 주의 깊게 검토하여 버그인지 확인하고, 다양한 유용한 정보를 찾고, 문제의 핵심을 찾아 재현해 보세요. 보고서와 중복되는지 다시 확인하세요. 중복이 발생하면 관련된 사람들이 이를 어떻게 처리했는지 확인하십시오.

2. 준비 - 올바른 코드를 찾아 제거를 사용하여 작업 공간을 정리합니다.

　3. 테스트 환경을 맞춰보세요. 고객이 컴퓨터 구성 작업을 하는 경우 이 프로세스를 건너뛸 수 있습니다.

4. 코드의 목적을 명확히 하고 기존 테스트 도구를 사용하여 모든 것이 제대로 작동하는지 확인합니다.

5. 이제 낚시를 할 수 있습니다. 오류를 재현하고 진단합니다. 재현할 수 없으면 수리 작업을 했다는 것을 증명할 수 없습니다.

　6. 테스트 케이스를 작성하거나, 기성 테스트 케이스를 통해 버그를 잡아보세요.

7. 수리 모드로 진입 - 다른 부품에 영향을 주지 않는지 확인하세요. 그러나 수정을 시작하기 전에 리팩토링을 수행하는 것이 좋습니다. 그래야만 두려움 없이 코드를 망칠 수 있기 때문입니다. 또한 사후 회귀 테스트를 통해 새로운 버그가 추가되지 않는지 확인할 수도 있습니다.

8. 코드를 정리합니다. 단계별 리팩토링을 통해 코드를 더 쉽게 이해하고 더 안전하게 만들 수 있습니다.

9. 다른 사람을 찾아 검토해 보면 당국도 혼란스럽고 구경하는 사람들도 혼란스러워질 것입니다.

　10. 이 수리 과정을 다시 확인해 보세요.

11. 이 버그가 다른 브랜치에 영향을 미치는지 확인하려면 메인 라인에서 시작하지 마세요. 이러한 변경 사항을 병합하고, 코드의 차이점을 처리하고, 모든 검토 및 테스트를 검토하는 등의 작업을 수행합니다.

12. 생각해보세요. 무엇이 잘못되었고 그 이유는 무엇인지 신중하게 생각해 보십시오. 왜 수정이 작동합니까? 이런 유형의 버그가 또 어디에 나타날까요? Andy Hunt와 Dave Thomas는 "The Pragmatic Programmer"라는 책에서 "버그로 인해 많은 시간이 소요된다면 그 이유를 알아내야 한다"고 지적했습니다. 또한, 앞으로 더 이상 비슷한 문제가 발생하지 않도록 경험과 교훈을 통해 어떻게 배울 것인지도 고민해야 합니다. 그리고 우리가 사용하는 방법과 도구에 개선할 수 있는 것이 있습니까? 그리고 이러한 버그의 영향과 심각도.

버그를 찾는 것과 고치는 것 중 어느 것이 더 시간이 걸리나요?

버그를 찾고 수정하는 시간보다 테스트 환경을 설정하고, 문제를 재현하고, 버그를 테스트하는 데 걸리는 시간이 훨씬 더 길 수도 있습니다. 그러나 소수의 명백한 버그의 경우 쉽게 찾을 수 있지만 이를 수정하는 것은 이상적이지 않을 수 있습니다.

책 "소프트웨어 만들기"에는 "대부분의 소프트웨어 취약점의 소스"를 주로 논의하는 장이 있습니다. 드웨인 페리는 수리에 비해 버그 발견(버그 이해 및 버그 재현 포함)이 더 중요하다고 분석합니다. 시간이 더 오래 걸립니다. 연구에 따르면 대부분의 버그(거의 3/4)는 찾기 쉽고 수정하기도 쉽습니다. 5일 이내에 완료됩니다(이는 강력한 SDLC, 광범위한 검토 및 테스트를 통한 대규모 실시간 시스템을 기반으로 함). 하지만 아주 역겨운 버그도 있습니다. 쉽게 잡을 수 있어도 고치려면 열심히 노력해야 합니다.

발견/수리 수리 시간5일

문제 재현 가능 72.5% 18.4%

재현이 어렵거나 전혀 불가능 현재 5.9% 3.2%

그러므로 버그를 빨리 고칠 수 있다고 장담했다면 대부분의 경우 당신이 옳을 것입니다. 하지만 내기에서 졌다면, 그건 당신이 큰 곤경에 처했다는 뜻이에요.

그러니 다음번에 상사가 버그 언제 고쳐지냐고 물으면 “곧 고쳐질 거예요”라고 멍청하게 대답하지 마세요.