리뷰 중인 CL 헤쳐보기

무엇을 살펴봐야 하는지 알았다면 이제는 효율적으로 코드를 헤쳐보는 순서를 살펴본다.

첫번째: 거시적인 관점에서 바라본다.

CL 설명문을 읽고 무슨 일을 하는 CL인지 먼저 파악한다. 만일 불필요한 작업이었다면 즉시 그 이유를 설명한다. 그리고 이런 경우에는 대안을 함께 제시하면 좋다. 예를 들어 “훌륭하게 코드를 고쳐주셔서 고맙습니다! 다만 저희는 FooWidget을 아예 제거하는 방향으로 나아가고 있어서 해당 부분은 추가적으로 수정하고 싶지 않습니다. 대신 BarWidget 클래스를 리팩토링 해주실 수 있을까요?”

리뷰어는 예의를 갖춰 CL을 거절하고 대안을 제시했다. 상대방과 의견이 다르더라도 우리는 항상 상대 개발자를 존중해야 한다. 다만 이렇게 거절되는 CL이 생각보다 많다면 팀의 개발 프로세스를 한번 점검하여 수고스럽게 작성한 코드가 버려지지 않게 하고, 차라리 개발을 본격적으로 시작하기 전에 반려하도록 한다.

두번째: 핵심 부분을 찾아낸다.

가장 많은 로직 변화가 발생한 파일을 찾아라. 그 곳이 CL의 핵심 부분이다. 여기서부터 코드를 읽으면 나머지 작은 부분들을 더 빨리 이해할 수 있다. 만약에 CL이 너무 커서 핵심 부분을 찾기 어렵다면 작성자에게 물어보거나 CL을 여러개의 CL로 분리하도록 요청한다.

핵심 부분의 설계가 잘못되었다면 나머지를 다 보기 전에 즉시 알린다. 나머지 부분은 설계를 수정하면서 자연스럽게 사라질 가능성이 높다. 설계 이슈를 최대한 빨리 전달해야 하는 이유는 다음과 같다.

• 일반적으로 개발자는 코드 리뷰를 요쳥하고 나서 해당 CL에 이어서 다른 작업을 시작하기 때문에 설계를 늦게 고치면 나중에 수정해야할 코드가 점점 많아진다.
• 코드의 설계를 바꾸는 일은 오래 걸린다. 마감 기한도 맞춰야하기 때문에 기간 내에 품질 좋은 코드를 만들려면 하루 빨리 재설계를 시작해야한다.

세번째: 나머지 부분들도 적절한 순서대로 살펴본다.

거시적인 코드 설계에 문제가 없다면 나머지 파일들도 빠짐없이 살펴본다. 코드 리뷰 툴에서 정렬된 순서대로 봐도 좋고, 테스트 코드부터 봐도 도움이 된다.

다음: 코드 리뷰의 속도