Joel on Software   조엘 온 소프트웨어

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

과거, TRS-80 Level-I BASIC은 오로지 A$와 B$라는 두 개의 문자열 변수만을 저장할 수 있었다. 마찬가지로, 필자가 타고난 두뇌 속의 버그 저장용 슬롯도 두 개밖에 되지 않는다. 즉, 필자가 한번에 기억할 수 있는 버그의 수는 두 개를 넘지 못한다. 만일 한꺼번에 세 개의 버그를 기억해야 한다면, 필경 셋 중의 하나는 놓쳐버렸을 테고 바닥에 떨어뜨린 이 버그는 침대 밑으로 쓸려 들어가 결국 먼지덩어리 속에 파묻히고 말 것이다.

버그 정보를 꾸준히 데이터베이스화 하는 것은 훌륭한 소프트웨어 팀이 갖춰야 할 덕목임에도 불구하고, 실제로 이를 제대로 실천하고 있는 소프트웨어 팀은 극소수라는 사실에 놀라지 않을 수 없다. 프로그래머들이 좀처럼 버리지 못하는 잘못된 믿음 중의 하나가 바로 모든 버그 정보를 기억할 수 있다거나 혹은 메모지에 적어두는 것만으로 충분하다는 것이다.

여러분이 잠시만 귀를 기울여준다면, 필자가 앞서 쓴 손쉬운 스케줄 관리법과 손쉬운 스펙 작성법에 이어 아주 손쉬운 버그 추적 방법에 대해서도 설명을 좀 해볼까 한다.

무엇보다, 버그 추적을 위해서는 진짜 데이터베이스가 필요하다. 두 사람의 프로그래머가 주말 동안 작은 코드를 하나 만들어내는 경우라면 그냥 텍스트 파일을 버그 추적용 데이터베이스로 사용해도 무방하다. 하지만, 이보다 작업 규모가 커지는 경우에는 실제 버그 추적용 데이터베이스가 필요하다. 시중에 나와있는 버그 추적 데이터베이스 제품은 매우 다양하다. (막간을 이용한 자사 홍보: 필자의 회사인 Fog Creek Software에서 내놓은 FogBUGZ는 사용이 매우 간편하면서도 기능은 강력한 웹 기반의 버그 추적 데이터베이스 제품이다. 자화자찬 같기는 하지만.)

버그 추적 과정의 예를 살펴보기 위해, 그 탄생의 순간부터 누군가에 의해 소멸될 때까지, 한 버그의 일생을 따라가 보자. 여기서는 저 유명한 버그 1203의 일생을 추적하기로 한다. 다음은 이 버그에 대한 데이터베이스의 내용이다.