주석은 Why > What > How 순으로...

프로그램 코드의 주석은 코드 이해와 유지보수성을 좋게 하는 중요한 요소이다.

그러나 실무 환경에서는 잘 지켜지지 않는 경향이 있다. 개발 규칙이 철저하게 지켜지는 환경이라면 몰라도 그렇지 않을 경우 종종 무시되곤 한다.

 

코드에 주석을 다는 것이 중요하다는 것은 두말이 필요 없을 것이며, 더 나아가 주석에 어떤 내용을 담을 것인가도 매우 중요하다 하겠다. 특히 다른 사람이 작성한 방대한 코드를 분석하게 될 경우 주석의 퀄리티(?)는 분석을 얼마나 빨리 정확하게 하는가의 주요한 잣대가 된다.

 

주석의 퀄리티는 주석에 담긴 내용으로 평가할 수 있다. 개인적으로 주석의 내용은 다음과 같은 순으로 작성하는 것을 권장.. 아니 필수라고 하고 싶다.

 

Why > What > How

 

지금 자신의 주석 습관을 되새겨 보자. 대체로 What 을 설명하고 있지 않는가?

 

제일 중요한 것은 Why이다. 즉 해당 코드가 왜 이렇게 작성되었는가?에 대한 대답이다. 특히 오랜 시간 유지보수되어온 코드라면 Why는 더욱 중요해진다. 대부분의 프로그램은 시간이 감에 따라 수정/보완이 되고, 요구사항/환경의 변화와 시스템의 제약사항 등으로 처음 보는 사람이 쉽게 납득하지 못하는 형태로 변모되기 일쑤다.

 

다시 말해 코드 자체가 이해 되지 않는 경우보다는 왜 코드를 이렇게 작성해야 했는가?... 에 대한 대답이 필요하게 되는 것이다. 이것은 코드를 잘 작성했고 못했고의 문제가 아니다. 코드의 히스토리에 대한 의문이다.

 

필자는 실제로 방대한 시스템을 인수받을 일이 있었다. 그 시스템은 오랜 시간 운영 되어온 시스템으로 주석이 잘 작성되어 있지 않았을 뿐더러 있는 주석의 경우에도 대부분 What를 설명하고 있었다. 따라서 코드 분석에 가장 많은 시간을 할애한 부분이 바로 Why에 대한 대답을 찾는 것이었다.

 

사실 코드를 읽을 수 있는 프로그래머라면 What과 How는 어렵지 않게 파악이 가능하다. 그러나 Why의 경우 쉽지 않다. 특히 코드 자체가 아니라 시스템의 제약사항이나 요구사항의 특수성을 반영한 코드를 Why 없이 분석한다는 것은 참으로! 쓸데 없는 에너지가 낭비되는 것이다.

 

(참고로 개발자 들이여... 남의 코드를 보고 무조건 까지 말자. 그에게 말 못할(?) Why가 있었을지도 모른다)

 

결론! What과 How도 간단하게 명시하는 것이 좋지만 귀찮다면 Why 라도 남기도록 하자.

 

혹시 '누구 좋으라고' 라는 의문이 드는가? 그렇다면 당신은 지친 개발자!