클린코드 : 4장. 주석

내멋대로 요약

우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 

주석은 나쁜 코드를 보완하지 못한다. 나쁜 코드에 주석을 달지 마라. 새로짜라.

 

주석은 오래될수록 코드에서 멀어진다. 오래될수록 완전히 그릇될 가능성도 커진다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까.

주석을 엄격히 관리하는 것 보다 코드를 깔끔하게 정리한고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다.

 

(아래와 같이 주석이 필요하지 않도록 코드를 개선한 예시를 보여준다.)

 

예시 1. 

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

// [AFTER]
if(employee.isEligibleForFullBenefits())

 

예시 2. 

// [BEFORE]
// 전역 목록 <smodule>에 속하는 모듈이 우리가 속한 하위 시스템에 의존하는가?
if(smodule.getDependSubsystems().contains(subSysMod.getSubSystem()))

// [AFTER]
ArrayList moduleDepandees = smodule.getDependSubsystems();
String ourSubSystem = subSysMod.getSubSystem();
if(moduleDependees.contains(ourSubSystem))

 

그렇다면, 좋은 주석이란?

법적인 주석(저작권정보, 소유권정보), 정보를 제공하는 주석, 의도를 설명하는 주석..

그 마저도, 코드를 통해 개선하는게 최선이다.

 

느낀 것은..

이번 챕터는 정말 신선하다. 학생때나 직장인이 되서나, 이런 걸 적어도 되나? 싶은 것 마저도 주석을 써라 라고 들었기 때문이다.

하지만 저자는 우리에게 최소한의 주석달기를 권하고 있다. 심지어 실패를 만회하는 수단이라고 말한다.

 

주석이 코드의 변화를 따라가지 못한다는 말은 공감이 간다. 5년 정도 운영되었던 소스를 보면 description 마저도 현행화 되지 않아 정확하지 않은 정보를 담고 있다.

그럼에도 주석은 형상관리툴보다 더 사소한 내용들을 담기에 이전 개발자의 생각을 엿볼 수 있고, 비정확한 정보를 제공하고 있을 때는 코드의 수정 전 후를 예측해 볼 수 있게 한다. 그래서 ‘어떠한 주석이든 옳다’ 라는 생각에 믿어 의심치 않고, 내가 코드를 짤 때도 주석에 신경을 쓰는 편이다. 위에 정리한 예시를 봐도 전자가 개인적으론 더 깔끔하고 명확하게 느껴진다.

 

왜 저자는 주석이 필요없는 코드, 의도를 담은 코드를 강조할까 고민을 해보면, 우리가 그동안 '의도를 담은 코드'를 진지하게 고민을 해본적이 없기에 주석이 중요해 진건가? 라는 생각도 든다.

1장 깨끗한 코드에서 설명한 “깨끗한 코드는 잘 쓴 문장처럼 읽힌다”, “문학적으로 표현해야 마땅하다”라는 표현에도 의아했었는데, 지금 이 챕터에서 하는 이야기와 비슷한 맥락이라 생각하니 이해가 된다. 앞으로 ‘주석이 필요없는 코드를 짜는 것’에 대해 고민할 필요는 있어보인다.