본 문서는 google code review guide를 보고 요약한 글 입니다.
때로는 개발자가 리뷰한 의견에 반대할 수도 있습니다. 그들은 리뷰어의 제안에 동의하지 않거나 너무 엄격하다고 불평할 것입니다.
1. 누가 옳은가?
코드 작성자가 리뷰어의 제안에 동의하지 않은 경우, 먼저 리뷰어의 의견이 옳은지 생각해보아야 합니다. 코드 작성자들은 리뷰어보다 코드를 더 잘 파악하고있는 경우가 많기 때문에, 특정 측면에서는 리뷰어보다 더 나은 판단을 할 수 있습니다. 코드 작성자의 주장이 합리적인가요? 코드 품질의 관점에서 의미가 있나요? 그렇다면, 코드 작성자가 옳다는 것을 알려주고 문제가 해결되도록 만들어야합니다.
그러나 코드 작성자가 항상 옳은 것은 아닙니다. 이 경우 리뷰어는 자신의 제안이 맞다고 믿는 이유를 추가로 설명해야 합니다. 코드 작성자의 답변에 대한 이해와 변경을 요청한 이유에 대한 정보가 모두 설명되어있는 것이 좋은 설명이라고 할 수 있습니다.
특히, 리뷰어의 제안이 코드 품질를 개선할 것이라고 판단되면, 변경에 대한 의견을 계속 밀고나가야 합니다. 코드 품질 개선은 작은 발걸음 부터 시작됩니다.
항상 예의를 지키고, 단지 동의하지 않을 뿐 리뷰어가 코드 작성자의 말을 경청하고 있다고 알려야 합니다.
2. 코드 작성자가 화나지는 않을까 (Upsetting Developers)
리뷰어가 개선을 요구하면 코드 작성자가 화날것이라고 생각합니다. 때로는 코드 작성자가 화를 내기도 하지만, 일반적인 경우 코드 품질을 향상에 도움을 준 것에 대해 매우 감사하게 생각하게 될겁니다. 보통 의견이 정중하다면 코드 작성자는 실제로 전혀 화를 내지 않습니다. 실제로 코드 작성자가 화를 내는 경우는 리뷰어의 고집스러운 주장이 아닌, 리뷰어가 의견을 작성한 방식이 문제일 확률이 큽니다.
3. 나중에 다듬기 (Cleaning It Up Later)
리뷰어의 의견에 반대하는 일반적인 원인은, 코드 작성자가 일을 빨리 마무리 짓고싶어하기 때문입니다. 그렇기 때문에 코드 작성자가 나중에 코드를 정리할 것이라고 말하고, 리뷰어는 이 CL을 동의해야 하는 상황이 올 수도 있습니다.
일부 개발자는 코드를 정리하는 후속 CL을 즉시 작성하지만, 경험에 따르면 코드 작성자가 원래 CL을 작성한 후 시간이 더 많이 흐를수록 이러한 정리 작업이 일어날 가능성이 낮아집니다. 실제로 코드 작성자가 현재 CL을 작성한 직후에 정리 작업을 수행하지 않으면 코드는 정리되지 않습니다. 이는 코드 작성자가 무책임한 것이 아니라, 할 일이 많고 다른 작업으로 인해 정리 작업이 잊혀지기 때문입니다.
그렇기 때문에, 리뷰어는 CL이 merge되기 전에 코드 작성자가 지금 정리 작업을 해야한다고 말하는 것이 좋습니다. 나중에 정리를 하는 것은 코드 품질을 떨어뜨리는 일반적인 방법입니다.
코드 작성자는 CL이 복잡성을 증가시키는 경우 긴급한 상황이 아니면 리뷰를 요청하기 전에 CL을 정리해야 합니다. 만약 불가피하게 CL을 즉시 정리할 수 없는 경우, 코드 작성자는 정리 작업을 위해 task를 만들어 자신에게 할당해야 합니다. 혹은 TODO 주석을 추가하는 것이 선택지가 될 수도 있습니다.
4. 엄격함(strictness)에 대한 일반적인 불만
이전에 상당히 느슨한 코드 리뷰를 받았던 개발자에게 엄격한 리뷰를 하는 순간 일부는 크게 불평할 것입니다. 이런 경우 리뷰 속도를 높이면 일반적으로 불만이 사라집니다.
이런 불만이 사라지는데까지 몇 달이 걸릴 수 도 있습니다. 하지만 결국 개발자는 엄격한 코드 리뷰의 가치를 깨닫게 되며, 때로는 가장 강하게 불평했던 사람이 엄격한 코드 리뷰의 가장 강력한 지지자가 되기도 합니다.
5. 갈등 해결
위의 모든 사항을 따랐음에도 갈등을 여전히 해결 할 수 없는경우에는 The Standard of Code Review 를 참고합니다.