코드와 주석을 같이 읽어보면 중복을 발견하게 됩니다. 그 경우 주석의 추상화를 높여서 중복을 제거합니다. 그 후에 다시보면 메소드/메소드/변수명과 크게 다르지 않는 경우가 있습니다. 그러면 주석을 삭제합니다. Comment refactoring catalog...ㅎㅎ

나도 주석을 거의 달지 않는 입장이라 이 글을 지지하는 입장이지만 상황에 따라 다른 측면도 있지 않을까 생각한다.

예를 들어 내가 일했던 xlgames는 개발자의 규모도 많지 않고 나름 팀내에서 코드 리뷰도 하고 같은 공간에 모여서 일을 했다. 이런 경우에는 이 글에서 말하는데로 주석보다는 소통을 통해서 충분히 해결해 갈 수 있는 여지가 있다고 생각한다. 한,두명의 개발자에 대한 공백이 생기더라도 일정 부분 문제 발생을 최소화할 수 있지 않을까 생각한다.

또한 이 글에서 이야기한 데로 소스 코드가 비지니스 로직을 담고 있는 경우라면 주석을 통한 해결보다는 메소드를 분리하고, 꾸준한 리팩토링을 통해 소스 코드에 의도를 드러내는 것이 더 중요하다고 생각한다.

하지만 서비스 전체적으로 사용해야 되는 라이브러리나 프레임워크 성격의 코드라면 주석은 추가하는 것이 유용하다는 입장이다. 또 한 측면으로 팀의 문화가 공유나 대규모라면 앞의 경우보다는 좀 더 적극적으로 주석을 추가해 주는 것이 유용하지 않을까?

즉, 팀의 문화, 규모, 소스 코드의 성격에 따라 주석의 양은 달라져야 할 듯하다. 단위 테스트 코드의 유무도 중요한 요소가 되겠네. 암튼 정답은 없다는 것.. context에 따라 최선의 선택을 해야된다는 것. 그러니 프로그래밍이라는 작업이 힘든 것이겠지.

저도 주석 참 좋아라 하는데요.(남이 잘 설명해둔..저는 쓰지않고 ㅡㅡ;;;)

여튼 이문제는 주석도 유지보수 할것인가?로 귀결된다고 보네요.

로 수십줄의 주석이 달린 메소드를 요구사항에의해서 수정되었을 경우 주석도 유지보수 할 것인가?..특히나 팀과 개발자의 자리이동이 잦은 비즈니스 애플리케이션에서..

단언컨데, 작업자도 유지보수 안합니다.(예외 인정!!) 그냥 메소드나 변수명 잘 짓는게 좋은거라 생각하지만, 개인적 현실은 시망..작명소라도 다니고 싶네요.

제 의견으로는...

코드에 대한 주석은 대부분의 경우에 필요 없는게 현실입니다. @eclipse4j 님도 말씀하셨듯이, 주석을 유지보수 하느냐는 문제가 있기 때문인데요.

해당 링크에 나온 부분은 "개발 문서"에 관한 부분이라, 저는 이 부분은 주석으로라도 남겨놓는 편이 좋다고 봅니다. (코드에 대한 주석 != 개발 문서)

따로 유지하는 방법도 있지만, 마찬가지로 유지보수 문제가 있으니까요.

전 일부러 반대쪽으로 얘기해 보려고 합니다. 보통 주석은 중복이니 서술적이고 가독성 높은 코드와 적절한 작명으로 주석을 대신하자는 얘기가 있지만, 그게 주석의 필요성을 100% 제거하지는 못한다고 생각합니다. 특히, 우리나라에서는 코드를 통해 의도를 표시하는 데 큰 한계가 있어서 미국 사람들이 말하는 걸 그대로 받아들일 수는 없습니다. 그리고 자바의 메서드 시그니처에는 경계 조건 같은 제약 조건과 기타 계약 사항을 모두 명시할 수 없습니다. jsr 303을 사용한다고 하더라도 말이죠. 그러니 적절한 주석과 (Javadoc 같은) 문서 작업은 필요하다고 생각합니다. 잘못하면 충분히 커뮤니케이션하지 않는 변명으로 clean code 원칙들이 사용될 수 있다는 얘기입니다.