4단계

이로써 디버깅은 크게 다음 4단계로 볼 수 있다.

 

1. 정상 시스템이 어떻게 작동하는지 알아낸다.

2. 문제의 원인을 아직 모른다는 사실을 인정한다.

3. 문제를 일으키는 원인이 무엇인지 알아낼 때까지 데이터를 살펴본다.

4. 증상이 아닌 원인을 고친다.

 

꽤 간단한 원칙이지만, 사람들은 이런 원칙을 수시로 어긴다. 내가 겪은 프로그래머 대부분은 버그가 생기면 자리를 잡고 앉아서 버그에 관해 생각해보거나 원인이 무엇일지 이야기하고 싶어 한다. 둘 다 결국은 추측이다.

시스템에 관한 정보나 디버깅에 도움이 될 데이터를 알려주는 사람과 대화하는 건 괜찮다. 하지만 다른 사람들과 둘러앉아서 버그의 원인이 무엇일지 단체로 추측하는 건 그냥 혼자 앉아서 추측하는 것과 별반 다르지 않다. 동료를 좋아하고, 다 함께 잡담을 나누는 게 즐거울 수는 있다. 하지만 보통은 자신의 시간뿐 아니라 동료들의 시간까지 낭비하는 데 그치는 경우가 많다.

 

그러니 다른 이들의 시간을 빼앗지 마라. 코드베이스를 필요 이상으로 복잡하게 만들지도 마라. 방금 소개한 디버깅 방법을 써라. 이 방법은 모든 시스템, 모든 코드베이스, 모든 시점에 통한다.