티스토리 뷰

Software Engineering/Knowhow

버그 노트

엘키 2015. 1. 31. 18:00

버그는 프로그래머의 숙명이다.

 

섬세하게 만들려한 IOS, OS X에도 버그는 종종 있으며, 사실 많은 사람이 M$ 부르지만 나의 경우는 매우 감사하고 있는 MS 경우에도 버그는 많다. 구글도 예외는 아니고. (구글 apps 초창기 패치할 마다  언어 관련, IME 관련 문제를 겪게 했던 일은 나름 유명한 일화다.)

 

이러한 회사는 분명히 업계의 엘리트가 모여있을 텐데 어째서 이렇게 버그가 나오는걸까?

 

어찌보면, 버그는 당연한 숙명이다.

 

하나의 어플리케이션을 작성하기 위해, 작성된 위지윅 툴을 사용하더라도, 버그가 없다고 단정 지을 없다.

하물며, 코드가 들어가고, 각종 코드를 재사용하고, 다른 코드를 얹는 과정에서는 복잡도와 결합도는 증가하고, 당연히 버그가 생길 여지도 많아진다.

 

그렇다면 버그를 없애려는 노력과 기반은 당연히 마련해야 할테고… (나의 디버깅 관련 글들은 대부분 주제에 대한 글로 이루어져 있다) 그렇게 했는데도 발생한 버그들에 대해선 어떻게 대처해야 것인가?

 

나는 대안으로 기록. 버그 노트를 작성해야 한다고 생각한다.

 

꽤나 많은 프로그래머들이 버그를 부끄러워한다.

숨기려고도 하고, 괴로워 하기도 하고.

 

하지만 나의 경우는 꽤나 많은 버그가 환경에 영향을 준다고 생각한다. , 기존에 작성된 코드가 버그의 수나 버그의 수위를 조절한다고 생각하고.

 

, 그렇다면 버그는 부끄러워 대상이 아니고 개선해야 대상이다.

 

그럼 하나 질문.

 

개선을 위한 습관으로  어떤 노력을 해보셨나요?

 

흔히들 하는 핑계가 경력이 쌓이면 저절로 고쳐져요같은 경험론이다.

주변 지인들과 수많은 얘기와 경험 해보고 내린 결론은 절대 버그는 경험과 비례하지 않는다. (물론 절대적 경험치나 기본기가 부족한 경우는 버그를 양산하기도 한다. 혹은 절대적으로 촉박한 일정도 그런 문제를 만들기도 하고)

 

오히려 위에 언급한 시스템이 버그를 줄여든다.

 

추가적으로 개인적인 노력도 반드시 필요하다고 생각한다.

나의 경우는 그런 의미로 버그 노트를 작성해왔다. 대략 9년여 되가는 습관은, 나의 버그 수를 줄이진 않았어도 같은 종류의 버그 재발은 급격히 줄여줬는데, 자체적인 회고를 주기적으로 거치는 것도 병행하는 덕택일거다.

 

반드시 자신의 버그를 돌아봐야 한다고 생각한다.

그러기 위해 버그 노트를 작성하고, 과정에서 기록되어야 것은 다음과 같다.

 

  • 현상
  • 추정
  • 과정
  • 원인
  • 해결책

 

항목을 채우다보면, 잘못된 해결책이나, 미흡한 원인 파악, 잘못된 추정등이 밝혀진다. (종종 잘못된 현상 보고도 있긴 하고)

 

그런 과정을 반복하다보면, 자신의 잘못된 습관이 보인다. 습관을 고쳐나갈 수록, 퀄리티 높은 프로그래머가 된다고 생각한다.

 

물론 이런 노력없이도, 좋은 퀄리티의 프로덕트를 만들어 내는 분들이라면 괜찮지만, 아니라면 버그를 줄이기 위해 버그 노트를 써보면 어떨까?


댓글