요약
- 친절해야 한다.
- 논증하라.(자신의 추론을 입증하라)
- 명확한 가이드를 주는 방법과 문제점만 제시하고 코드 작성자가 결정하는 방법을 균형있게 한다.
- 코드 작성자에게 복잡한 부분에 대한 설명을 요청하는 대신에 코드를 단순화하거나 주석을 추가하도록 장려하라.
정중하게
일반적으로 당신이 리뷰하고 있는 코드의 작성자에게 매우 명확하고 도움이 되는 동시에 정중하고 공손해야 합니다. 그렇게 하려면, 당신은 항상 코드에 대한 의견을 남기고 개발자에 대한 의견은 절대 남기지 말아야 합니다. 항상 따라야하는 관례는 아니지만, 기분을 상하게 할 수 있거나 논쟁을 일으킬 수 있는 말을 할 때는 이를 지켜야 합니다. 예를 들면, 다음과 같습니다.
나쁜 예시: “동시성으로 얻을 수 있는 이점이 없는데 왜 당신은 쓰레드를 썼어요?”
좋은 예시: “작성한 동시성 모델은 성능상의 이점없이 시스템에 복잡도를 증가시키는 것 같아요. 성능상 이점이 없기 때문에 멀티 스레드를 사용하기보다 단일 스레드를 사용하는 것이 최선일 것 같아요.”
이유 설명하기
위에서 말한 “좋은” 예시에서 주목할 점은 개발자가 당신의 의견을 이해하는데 도움된다는 것입니다. 항상 이런 정보를 의견을 남길 때 포함할 필요는 없지만, 당신의 의도 또는 당신의 의견이 어떻게 코드 품질을 향상시킬 수 있는지 설명하는 것이 적절합니다.
지침사항 제공
일반적으로 코드 변경사항을 수정할 책임은 리뷰어가 아닌 코드 작성자에게 있습니다. 리뷰어가 코드 작성자를 위해 상세 설계나 코드를 작성할 필요는 없습니다.
그렇다고 리뷰어가 도움이 되지 않는다는 뜻은 아닙니다. 일반적으로 문제를 지적하는 것과 직접적인 지침을 제공하는 것의 적절한 균형을 유지해야 합니다. 문제를 지적하고 개발자가 결정하도록 하는 것은 개발자의 학습에 도움이 되며, 코드 리뷰가 더 수월해집니다. 또한 코드 작성자가 리뷰어보다 코드를 더 잘 알기 때문에 리뷰어보다 더 좋은 방법을 얻을 수 있습니다.
하지만, 때로는 직접적인 지침, 제안 또는 코드가 더 도움이 됩니다. 코드 리뷰의 주된 목표는 가능한 코드 변경사항을 최적화하는 것입니다. 두 번째 목표는 개발자의 기술을 향상시켜 시간이 지남에 따라 코드 리뷰가 점점 더 적게 필요하게 하는 것입니다.
설명 받아들이기
리뷰어가 코드를 보고 이해를 하지 못하여 코드 작성자에게 설명을 요청했다면, 대부분의 경우 코드 작성자는 코드를 더 명확하게 다시 작성해야 합니다. 때때로, 지나치게 복잡한 코드를 설명하는 것이 아니라면 코드에 주석을 추가하는 것도 적절합니다. 코드 리뷰 툴에만 쓰여진 내용은 나중에 코드를 읽는 개발자에게 별 도움이 되지 않습니다. 따라서 잘 알지 못하는 부분이나 리뷰어(또는 리뷰를 읽는 개발자)가 이미 알고 있던 내용을 설명하는 경우에만 허용됩니다.
