Clean Code .Part4

이번 장은 주석이다.

주석에 대해서 깊게 생각해본 적이 없다. 내가 작성한 코드에 대해서 저자가 누구고 언제 수정했는지 이 코드는 무엇인지를 적는 것이 내가 아는 범위 내에서 활용이었다.

이 장의 시작은 다음과 같이 시작한다.

나쁜 코드에 주석을 달지 마라. 새로 짜라. - 브라이전 W. 커니핸, P. J. 플라우거

프로그래밍 언어는 수많은 세대를 거듭해 진화해 왔다. 가독성과 표현력이 발전하면서 인간이 받아들일 수 있는 코드의 형태로 말이다.

코드로 의도를 표현하지 못하여 우리는 주석을 통하여 부가설명을 덧 붙인다. 주석은 실패를 의미한다.

그 이유 중 하나로 프로그래머는 주석을 유지 보수하지 않는다. 이는 그릇된 정보를 전달할 가능성이 커진다. 사실 이러한 주석은 빈번하게 접했다. 그리고 있어야 할 이유가 없는데도 습관처럼 남아있는 주석을 작성하는 사람들도 봤다.

코드는 매번 변화한다. 시간이 흐를 수록 쪼개지거나 합쳐져서 옮겨진다. 불행하게 주석은 코드를 따라가지 못한다.

저자는 주석을 엄격하게 관리하고 유지 보수해야 한다는 의견에 동의하지만 차라리 코드를 정리하고 표현력을 강화하는 방안을 제시한다. 그래서 애초에 주석이 필요 없는 방향을 지향한다.

코드를 작성하고 이걸 다른 사람이 보는 입장을 생각한다. 그리고 약간의 혼동의 여지가 있겠는데?라고 생각하고 주석을 세세하게 작성한다. 이는 작성자부터 작성일까지 포함된다.

주석은 나쁜 코드를 보완하지 못한다고 한다. 자신이 작성한 엉망진창인 코드에 부가설명을 작성하는 시간에 그 코드를 표현력이 풍부하고 깔끔한 코드로 만드는데 시간을 사용하라고 말한다. 동의한다.

그럼 나는 코드로 의도를 잘 표현하는 방법을 공부해야한다.

예제를 보자.

//직원에게 복지 혜택을 받을 자격이 있는지 검사
if( (employee.flags & HOURLY_FLAG) && (employee.age > 65))


if (employee.isEligibleForFullBenefits())

첫 번째 작성된 코드와 두 번째 작성된 코드의 차이점이다. 의도가 보인다.

함수를 작성할 때 함수의 이름안에는 의미가 존재한다고 했고 이름을 명명할 때 매우 신중히 하려는 행동을 표현하라고 했다. 그 결과를 지켰다면 주석이 없는 코드로 충분히 표현이 가능했을 것이다.

그렇다면 사용할 수 있는 주석이 존재할까?

사실 저자는 주석을 남기는 것을 그리 좋아하지 않는 것 같다. 기술이 발전함에 있어서 이러한 불필요한 바이트들이라고 표현하는 것을 보면 말이다.

내가 초기에 문제삼았던 이력을 기록하는 주석에 대한 글도 있다.

모듈을 편집할 때 마다 주석을 추가하는 행위에서 점점 모든 이력을 기록하는 주석이 달려 대댓글 형식이 되어버린다.

과거에는 이러한 변경 이력을 관리하는 관례가 바람직했다. 그땐 소스 코드 형상 관리 시스템이 없었으니까.

하지만 이제는 혼란만 가중할 뿐이라 이러한 이력은 소스 코드 형상관리 시스템에 맡겨도 되지 않을까?

또 내 습관이 보였다.

나는 함수를 작성할 때 추상화 수준이 매우 낮은 단계로 여러 블럭들이 합쳐지는 경우가 보이면

해당 블럭을 한눈에 파악하기 위해서 닫는 블록에 주석을 하곤 했다.

그런데 함수를 매우 작은 단위로 분해하고 의미를 갖도록 만드는 함수 파트에서의 조언처럼 함수를 작게 분해하여 한 가지일만 하는데 왜 함수가 길어서 주석으로 표시를 했던 거지라는 반성을 하게 되었다.

결국 함수 작성에 대해 클린 코드의 조언을 받고 개선하다 보면 이러한 닫는 블럭에 주석을 다는 습관도 고쳐지리라

Once Run 현실과 이상을 채우는 블로그