과거 코드에 대한 의견을 남기고 있습니까?

Question

나는 캐리 어를 시작했을 때 내가 쓰는 모든 모듈에 (올바르게) 주석을달라고했다. 방법이 무엇인지, 매개 변수가 사용되는 방법, 반환 할 때 무엇을 기대해야하는지 등을 알려줍니다.

그런데 거의 2 년이 지나서 나는 오해의 소지가 있거나 쓸데없는 의견으로 레거시 코드를 방문하기 시작했습니다. 그리고이 과정에서 저는 코드베이스에서 그것을 제거하는 데 사용했습니다.

내 직무에서 프로젝트 관리자는 내게 의견 남기기에 대해 걱정하지 말라고 지시했으며 단위 테스트를 사용하여 코드 작성 청사진을 남기도록 제안했습니다. 시간이 지남에 따라 코드가 변경되었지만 주석이 최신 상태를 유지하지 못하고 오히려 오해를 불러 일으키기 때문에 동의했습니다.

그런 다음 최근 Martin Fowler의 Refactoring 책에서 몇 가지 의견을 남길 수있는 범위를 볼 때마다 메소드를 추출했습니다. 그렇다면 모듈에 주석을 남기는 것은 정말로 쓸데없는 일입니까?

간단히 요약하면 다음과 같습니다. 내 경험에 따라 의견을 남기지 말고 다음 두 가지 옵션을 선택해야합니다. 1) 추출 방법. 2) 모듈의 의도를 지원하기위한 단위 테스트.

우리는 항상 의견을 남기지 않고 위의 두 가지 옵션에 의존해야합니까? 아니면 다른 대체물을 가지고 있습니까? 의견을 말하십시오.

관심을 가져 주셔서 감사합니다.

Answer 1

코드가 작동하는 방식을 중계하는 방식으로 주석을 사용해서는 안되며, 코드 자체가 적절하고 명확하게 작성되어야합니다. 대신, 을 설명하는 주석을 사용해야하며 코드에서 특정 접근 방식을 취한 이유는 무엇입니까? 이런 점에서 논평은 매우 귀중하고 확실히 과거의 일이 아닙니다.

Answer 2

글쎄, 개인적으로 나는 내 프로젝트를 다시 방문하려고 시도 할 때 몇 가지 표현을 통해 내가 앞으로 2 년 동안 혼란에 빠질 수도있는 경우 특히 의견을 남기는 것을 좋아합니다.

나는

Answer 3

댓글도 라이브러리를 설명하는 데 여전히 필수적 등 게임 개발, algos를 수행 할 때 주석이 일이 유용하다고 생각합니다. 물론 소스 코드를 연구하여 함수가하는 일을 파생시킬 수 있습니다. 그러나 자연 언어는 사람이 빨리 구문 분석하기 쉽고 사용자가 불필요한 세부 사항을 생략 할 수도 있습니다.

내가 공부하는 동안 아주 좋은 프로그래밍 언어 인 에펠 (Eiffel)을 사용해야했지만 끔찍하게 문서화되었습니다. 문서화 정책은 코드가 자체적으로 문서화되고 인터페이스가 사전 및 사후 조건에 의해 정의된다는 것입니다. 물론 이러한 제약 조건으로부터 유효한 입력을 유도 할 수는 있지만 함수 또는 입력 및 출력의 의미 적 의미를 전달할 수는 없습니다. 따라서 Eiffel의 라이브러리는 크게 문서화 된 Java 또는 .NET 기본 클래스와 비교하여 배우기가 극도로 어려웠습니다.

Answer 4

주석은 과거의 일이 아니 었습니다. 단위 테스트는 함수가 어떻게 사용되도록 의도되었는지 사용자에게 보여줄 수 있지만 함수가 특정 방식으로 보이는 이유를 설명하지는 않습니다. 이것은 리팩토링 할 때 특히 유용합니다.

아무 것도 가져 오지 않는 댓글은 코드를 가리고있는 잡음이지만 독자에게 몇 가지 상황을 알려주기위한 간단한 선은 가치가 있습니다.

Answer 5

코드의 현대적인 접근 방식은 가능한 한 더 많이 분화 (분무)하는 것으로 구성되어 있으므로 코드는 최소화되고 코멘트가 없으므로 인간의 눈에는 인쇄 할 수있는 방식이 아닙니다. 그러나 코드의 주석 (즉, 왜 코더가 이것을 대신했는지)은 일종의 위키 또는 일종의 상대 도구를 통해 사용할 수 있어야합니다. 우리를 위해 할 일종의 UI가 있기 때문에 코딩 작업은 점점 줄어들 것이라고 생각합니다. 예, 이러한 UI를 코딩해야한다고 말할 것입니다. 다른 사용자가 UI를 사용하고 있다고 생각합니다.