주석에 대한 생각

2013-10-17 00:10

아래 링크에 주석에 대한 이야기가 나오는데 ..소견을 적어봅니다... http://quicket-engineering.tumblr.com/post/64119797473/deview-2013

이전 에 @이수홍 님께서 말씀하신데로 Spring 이나 여타 라이브러리들 에는 Javadoc 에 형식을 빌어 친절하게 주저리 주저리 주석을 달려있습니다.(비록 영어 일지라도.....ㅜㅜ )

그럼 비지니스적인 코드들에도 주석이 줄줄줄 필요할까????

경험 상 여타 프레임웍이나 라이브라리 이 외의 비지니스 적인 Product 코드에서 살아서 나에게 기쁨을 주는 주석은 거의 본적이 없었던것 같습니다.

위에서 언급하신 Spring 등등 에 주석이 많이 달려있는 이유는 그것이 변화가 많은 코드가 아니고 이미 많은 이들에 의해서 사용되어지기 때문에 초기 개발 부터 어느정도 방향성과 철학을 가진 코드들이기에 가능하지 않을까 생각합니다.

이에 반해 비지니스적인 코드들은 누구에 의해 사용되지 않고 대부분 재사용적인 측면에서 수명이 짧기 때문에 코드의 변화가 극심한데요 그렇기 때문에 어설픈 주석은 관리포인트만 가중시키는 결과를 낳고 결국 버려져 잘못된 정보를 독자에게 던져줍니다. 이런 경우에는 주석보다 먼저 코드를 통해 의도를 들어내는것이 우선적 고려 대상이라고 생각합니다.
대부분에 비지니스적인 코드들은 위 경우 일것이라고 생각이 되고 코드 내에 주석을 주절주절 다는 것은 의미없는 행동들이 아닐까요?

0개의 의견 from FB

5개의 의견 from SLiPP

2013-10-17 00:52

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

2013-10-17 09:19

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

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

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

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

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

2013-10-17 09:21

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

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

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

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

2013-10-17 14:34

제 의견으로는...

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

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

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

2013-10-17 16:54

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

의견 추가하기

연관태그

← 목록으로