Bug(벌레), 프로그램

이놈의 벌레 참 많다.
얼마 되지는 않았지만 충남에 벌레의 습격이 있었다.
모든걸 먹어치우는. 모든 벌레가 나쁜것은 아니지만 해충은 나쁘다.

프로그램에서도 벌레는 꼭 퇴치해야할 것들이다.

난 지금 열씸히 게임서버를 제작중이다. 그런데 꼭 작업을 하다보면 이렇게 돌아간다.

1. 바쁘다. 그냥 생각한대로 코딩을 시작한다.
2. 완성됬다. 오 그런대로 돌아간다. 근데 구조적인 문제가 많다.
3. 젠장 열받는다. 다시 뜯어 고친다.
4. 완성됬다. 돌아간다. 근데 또 문제가 많다.

5. 울면서, 명세서 부터 다시 시작한다. 문제점과 해야할일을 쭈욱 적어 미리 구조나 설계를 실시한다.
6. 작업을 실시하고 완성한다.
7. 버그를 수정한다.
8. 제품을 릴리즈 한다.

솔직히 이게 얼마전까지 내가 겪고 해왔던 일이다. 아마 대부분 혼자 하는 사람들이라면
이 과정을 거칠 것이다.

하지만 PM이 있고 설계 담당자가 있다면 5~8번으로 마무리 지을 것이다.
명세서는 꼭 필요하다고 느낀다. 물론 지금도 열씸히 쓰고있다.

나 뿐만아니라 내가 만든것을 보는 모든 사람들(개발자,영업담당자등)을 위해 쓴다.

서론이 길어졌는데 내가 할얘기는 버그다.
조엘온소프트웨어의 저자 조엘스폴스키도 버그는 꼭 퇴치해야만 한다고 했다. 단 그 비용을 산정하라고 했다. 아주 미비한 버그를 잡기위해 엄청난 비용을 들이는 것은 바보 같다고 한다.

버그 없는 프로그램은 프로그래머의 신앙과 같다.
자기가 만든 제품에 문제가 없길 바란다.
나도 그런다. ^^

요즘 고민하는 것은 이렇다.

"과연 Bug를 언제 고칠 것인가.? 여러분은 어떠세요?"

보통 3가지다

1. 만들면서 고친다.
2. 버그가 나오면 기록해두고 나중에 고친다.
3. 1번과 2번 중간입장

대부분 3번이라고 생각한다. TDD에서 Test의 중요성과 페어프로그램을 강조한다. 이부분이 좋은것중 하나는 개발하면서 만드는 가장 밑단의 컴포넌트 부터 버그 없는 것을 만들어 나가면 결국 그위에 올라가는 모든 것들이 Bug가 없게 되는것이다.

Bug 없는 제품이라. 세상엔 없지 ㅡ.ㅡ; 후~

난 이렇게 생각하고 움직인다.
1. 프로그램을 할때 만난 Bug나 고쳐야 할것은 이슈트랙커에 무조건 등록한다.
2. 하나의 컴포넌트를 만들면 그에대한 TestCase 를 만들어 테스트한다.(최대한 문제점을 줄인다.)
3. 제품이 어느정도 윤곽이 잡히면(alpha 나 beta) Bug를 해결해 나간다.

그러나, 시간에는 쫒기고, 할일은 많고, Bug는 쏟아지고 후~ (변명.. ㅋㅋ)

Bug 없는 프로그램을 위해 오늘도 달리자!!

by ncanis(조성준)