코드 리뷰에서 반대 의견을 다루는 방법
코드 작성자는 때때로 당신의 리뷰 의견을 동의하지 않거나 리뷰가 너무 까다롭다고 불평할 수 있습니다.
누구 말이 맞나?
개발자가 당신의 제안에 동의하지 않는다면, 먼저 그들이 옳은지 고민해봅시다. 종종 리뷰어보다 해당 코드를 더 잘 알고 있기 때문에 실제로 그들은 코드의 특정 측면에서 더 나은 통찰력을 가질 수 있습니다. 그들의 주장이 맞는 말입니까? 코드의 품질 관점에서 맞는 주장입니까? 만약 그렇다면, 그들이 옳다는 것을 알리고 문제가 해결되도록 하십시오.
그러나 개발자가 항상 옳은 것은 아닙니다. 리뷰어인 당신이 더 옳다고 생각이 든다면 그 이유를 추가적으로 설명해야 합니다. 그 설명에는 코드 작성자의 답변에 대한 이해와 변경 요청 이유이 포함되어 있어야 좋습니다. 특히, 당신의 제안이 코드 품질을 향상시킨다면 더욱 더 의견을 적극적으로 주장해야 합니다. 코드 품질 향상은 작은 단계에서 이루어지는 경향이 있습니다. 항상 정중하며 당신은 리뷰어가 하는 말을 듣고 있다는 것을 알게 하십시오. 무조건 리뷰를 승인하지 않습니다.
코드 작성자의 기분이 나빠지면 어쩌지?
때때로 리뷰어들은 자신이 코드 개선을 요청하면 개발자의 기분이 나빠질거라고 생각합니다. 때로는 개발자가 기분 나빠할 수 있지만 나중에는 당신이 그들의 코드 품질을 향상시키는데 도움을 준 것을 매우 고마워합니다. 당신이 정중한 의견을 남긴다면, 일반적으로 개발자는 기분 나빠하지 않습니다. 개발자는 보통 코드 품질에 대한 리뷰어의 주장보다는 의견을 작성하는 방식이 정중하지 않을 때 기분이 상합니다.
나중에 정리할게요
개발자들은 일반적으로 일을 빨리 끝내고 싶어합니다. 따라서 코드 변경사항을 반영할 때 사소한 내용에 대한 리뷰를 하고 싶어하지 않습니다. 그래서 나중에 정리한다고 하는데, 당신은 지금 수정되도록 해야 합니다. 몇몇 개발자들은 후속 커밋(변경사항)을 반영하여 이런 문제들을 해결하기도 하지만 경험에 따르면 개발자가 기존 변경사항을 작성한 후 시간이 지날수록 이러한 정리 작업은 덜 일어납니다. 사실, 개발자가 현재의 코드 변경사항을 처리한 후 정리를 하지 않는 한, 정리 작업은 절대 일어나지 않습니다. 개발자가 무책임한 것이 아니라 해야할 일이 많고 다른 작업으로 인해 잊혀지기 때문입니다. 따라서 코드 리뷰가 완료되기 전에 지금 코드 정리를 해야 한다고 주장하는 것이 가장 좋습니다. “나중에 정리하도록” 하는 것은 코드의 품질을 떨어뜨리는 일반적인 원인이 됩니다.
코드 변경사항에서 새로운 복잡한 로직이 있다면, 긴급상황이 아닌 한 반영 전에 정리해야 합니다. 만약 지금 당장 진행할 수 없다면 이슈를 제기하고, 생성한 후 자신에게 할당해야 합니다. 또한 선택적으로 제기된 이슈를 참조하는 코드에 TODO 코멘트를 작성할 수도 있습니다.
엄격한 리뷰에 대한 일반적인 불만
유연한 코드 리뷰를 중단하고 엄격한 리뷰를 적용하면, 일부 개발자들은 매우 크게 불만을 가질 수 있습니다. 코드 리뷰 속도를 높이 일반적으로 이러한 불만은 사라집니다.
이러한 불만이 사라지는데 몇 개월이 걸릴 수 있지만, 결국 좋은 코드를 만드는데 도움이 된다는 것을 알게되며 때로는 가장 큰 불만을 가졌던 사람들이 엄격한 코드 리뷰를 더 지지하기도 합니다.
갈등 해결
위의 모든 내용을 다 지켰음에도 리뷰어와 개발자 사이의 갈등이 있다면, 갈등을 해결하는데 도움이 되는 지침과 원칙은 코드 리뷰의 표준 원칙을 참고하세요.
“구글의 코드 리뷰 가이드: 리뷰어 편” 의 마지막 글입니다. 처음으로 돌아가려면 여기를 클릭해주세요.
