코멘트를 달면 안되는 이유
‘컴퓨터가 이해하는 코드는 바보라도 짠다. 진정한 개발자는 사람이 이해할 수 있는 코드를 짠다.’
마틴 파울러의 말이다. 어떤 면에서 컴퓨터는 사람보다 똑똑하다. 프로그램 언어를 이해하는 측면에서 말이다.
PL로 역할을 맡게 될 때는, 팀원(종종 혼자서 팀원일 때도 있다.)들에게 코멘트를 달지 말라고 한다. 코멘트는 어떤 측면에서 보면 meta-data이다. 즉, 코드로 설명할 수 없는 부분이라고 생각될 때 코멘트를 다는 경우가 많다. if에 if에 if 그리고 for문에 다시 재귀적인 호출… 마지막은 goto 문까지 나오는 코드를 만들어 놓으면, 결국에 가서는 자신이 만든 코드도 얼마 지나서 살펴보면 무슨 말을 하는지 모를 때가 있다. 이럴 때를 대비해서 코멘트 몇 줄을 달아 주는 것으로 유지보수를 기약할 수 있다고 생각한다.
지금 하고 있는 프로젝트는 지난해에 끝난 프로젝트의 연장선 상에서 진행되고 있다. PL도 바뀌고(내가 PL임) 팀원도 바뀌고 고객만 똑같다. 그리고 안 바뀐게 한가지 더 있다. 기존의 프로젝트 소스다. 개발자는 다른 사람이 짠 소스를 싫어한다. 아무리 훌륭한 소스라도 본인이 다시 짜고 싶어한다. 왜 일까? 이유는 간단하다. 기존 소스를 이해해야 신규 코드를 추가하는데, 기존 소스를 이해한다는 것은 코드를 짜는 이상의 집중과 시간이 필요하다.
아무튼 여차 여차해서 지금 프로젝트는 종반으로 치닥고 있다. 잘된 것도 있고, 더 노력해야 하는 부분도 있다. 그런데 누가 나에게 지금 프로젝트에서 가장 어려웠던 부분이 무엇이냐고 묻는다면… 나는 “코멘트”라고 하고 싶다. 이게 무슨 소리냐구? 일단 기존 소스를 이해하는 것도 쉬운 일이 아닌데, 거기에 달려 있는 “코멘트”가 친절하게도 다른 길로 인도하는 경우가 종종 있다.
오늘도 대전 갈 거리의 일이였는데, 부산까지 갔다가 다시 대전으로 왔다. 이야기인 즉… 기존 소스를 살펴 보니, int 형으로 선언된 변수에 들어갈 수 있는 값은 한정되어 있었다. 이 때는 보통 #define 을 사용해서 값을 정해 놓지만 오늘 작업한 소스에서는 단순히 값으로 넣는 식으로 되어 있었다. 그리고 값에 대해서 0 일 때는 무슨 무슨 값, 1일 때는 무슨 값 이런 식으로 코멘트가 달려 있었다. 제일 좋은 것은 #define을 사용해서 값을 처리하도록 refactoring 하는거지만, 마음의 여유가 없는 관계로 그냥 코멘트만 믿고 일을 진행했다.
그런데 이상하게 데이터는 맞는데 출력값이 이상하게 나왔다. 그래서 여기 저기 break point 걸어 놓고 살펴 보았지만 값이 이상하게 나올 이유가 없었다. 절망의 나락에 빠진 채 몇 시간을 허비하다… 머리를 식히는 도중에 int 형으로 값을 선언한 곳에 코멘트가 잘못 달린게 아닐까 라는 생각이 들었다. 값이 할당되는 부분에 break point를 걸고 출력 값을 살펴 보니 코멘트가 잘못 달려 있었다. –;;
아무튼 몇 시간의 삽질 끝에 버그를 발견했으니 다행이다.
오늘 에피소드처럼 코드는 거짓말을 하지 않지만 코멘트는 거짓말을 종종 한다. 코멘트를 항상 코드와 매칭시킬 수 있다면 코멘트를 다는 것은 좋다. 그러나 프로젝트 초반에 정한 convention에 따라서 코멘트를 완료 보고 시점까지 다는 프로젝트를 한번도 보지도, 경험하지도 못했다. 그래서 난 코멘트를 달지 말라고 한다. 코멘트를 한 줄 다는 것보다 코드 자체의 가독성과 품질을 높이는게 중요하다. 대신 unit test와 같은 테스트 툴을 사용하여 코드의 가독성을 높이는 방법이 더 낫다. 코드를 보고 사용 방법을 모를 때는 pair unit test를 살펴 봄으로써 유지보수의 실마리를 찾을 수 있기 때문이다.
코멘트를 다는 것은 컴퓨터에게도 도움이 안 될 뿐만이 아니라 종종 빨간 거짓말을 하게 된다.


March 3rd, 2006 at 11:41 am
DRY법칙 - 주석을 아껴라
구정을 맞이하여 할머니 댁에 가있는 동안 상대적인 시간의 여유가 생겨서(==심심해서 ), 이럴때 읽어보려고 가져온 책(==실용주의프로그래머)을 조금 읽어봤다. 역시 컴퓨터가 눈앞에 없어…