왜?
규칙적인 코드 리뷰 시간 만들기
작업이 잠깐 중단될 때 시간 내기
개인의 속도를 고려하는 것이 팀의 속도보다 우선시되는 경우가 있습니다. 코드 작성과 같이 집중하고 있는 작업 중이라면 코드 검토를 위해 중간에 중단하지 마세요. 연구에 따르면 개발자가 중단된 후 다시 원활한 개발 흐름으로 돌아가는 데 오랜 시간이 걸릴 수 있다고 합니다. 따라서 코딩 중 중단하는 것은 다른 개발자가 코드 리뷰를 잠시 기다리게 하는 것보다 팀에 더 많은 비용을 초래합니다.
대신 검토 요청에 응답하기 전에 작업의 중단 시점을 기다리세요. 현재 코딩 작업이 끝났을 때, 점심 식사 후, 회의에서 돌아왔을 때, 휴게실에서 돌아왔을 때 등이 그 시점이 될 수 있습니다.
https://google.github.io/eng-practices/review/reviewer/speed.html
규칙적인 일정으로 시간 내기
우리에게는 기본적으로 오후 3시에 모든 사람의 캘린더에 고정된 1시간의 슬롯이 있다는 것을 의미합니다. 이렇게 하면 모든 사람이 하던 일을 멈추고 소중한 코드 리뷰 피드백을 기다리는 동료에게 그 시간을 할애할 수 있습니다. 공식적으로 시간을 할당하면 사람들이 코드 리뷰가 건강한 배포 파이프라인에 매우 중요하다는 사실을 기억할 뿐만 아니라 깨닫는 데 도움이 됩니다.
https://dev.to/mpermar/the-3pm-code-review-rule-2ppf
일정 시간만 코드 리뷰에 쓰기
제가 과거에 사용했던 또 다른 전략은 포모도로 기법입니다. 이 기법은 25분 동안 방해받지 않고 작업한 다음 몇 분간 휴식을 취하고 다시 25분 간격을 두고 작업하는 것을 제안합니다. 제가 가장 유익하다고 느낀 점은 몇 시간 동안 문제에 갇혀 있다는 느낌 없이 작업 중인 작업에 집중할 수 있다는 점입니다. 또한 25분 간격은 이메일과 인스턴트 메시징과의 연결이 끊어지지 않는다는 점에서 관리하기 쉽습니다. 아무도 짧은 시간 동안 메시지에 답장을 보내지 않는 이유를 궁금해하지 않으므로 메시지를 닫고 당면한 업무에 전념하지 못할 이유가 없습니다.
https://marcroussy.com/2017/04/01/finding-time-for-code-review/
코드 리뷰의 우선도를 높이기
좋은 팀에서는 코드 리뷰가 최우선 과제입니다. 손을 들어 외칩니다: "코드 리뷰가 필요해요!". 고객에게 가치를 제공하는 데 한 걸음만 더 가면 되기 때문에 팀원이 즉시 대답합니다: "바로 갈게요!"라고 대답하고 의자를 옆으로 옮깁니다. 그런 다음 검토, 몇 가지 수정 사항이 모두 초록색으로 표시됩니다. Git Push. 기능이 실행됩니다. 트래픽이 들어오기 시작하고 로그에 오류가 없습니다. 값이 전달되었고 작업이 완료되었음을 표시합니다. 리뷰어와 함께 웃으며 커피를 마시러 주방으로 갑니다.
https://sizovs.net/code-review/
또한 코드 리뷰의 중요성도 잊지 마세요. 프로그래밍 자체보다 더 중요합니다. 따라서 우선순위가 높아야 합니다. 코드 리뷰가 기다리고 있다고 해서 코딩을 즉시 중단해야 한다고는 말하지 않습니다. 하지만 검토를 여러 시간 미루지 말고 요청 후 몇 시간 이내에 완료하세요.
앞서 말했듯이 가능한 한 빨리 코드를 검토하여 동료가 작업을 완료하고 가치를 창출할 수 있도록 도와주세요. 다른 사람에게 코드 검토를 요청할 때는 빨리 검토되기를 바라는 것입니다. 그러니 다른 사람이 여러분에게 해주기를 바라는 것을 다른 사람에게 해주세요.
PR 작게 만들기
Cisco 시스템 프로그래밍 팀의 연구에 따르면 300줄에서 400줄 정도의 코드를 60분에서 90분 동안 리뷰하면 70~90%의 결함을 발견할 수 있다고 합니다. 각각의 PR을 릴리스 가능한 단위(기능(feature), 버그 수정), 혹은 의미있는 PR이 될 수 있는 하나의 응집된 아이디어로 다뤄야 합니다.
https://engineering.linecorp.com/ko/blog/effective-codereview
작성할 때 리뷰를 미리 생각하기
주석은 검토자에게 변경 사항을 안내하고 어떤 파일을 먼저 살펴볼지 알려주며 각 코드 수정의 이유를 설명해 주므로 작성자는 검토가 시작되기 전에 코드에 주석을 달아야 합니다. 주석은 다른 리뷰어가 프로세스를 쉽게 진행하고 더 깊이 있는 맥락을 파악할 수 있도록 작성해야 합니다. 추가적인 이점으로, 작성자는 동료 검토가 시작되기도 전에 추가 오류를 발견하는 경우가 많습니다. 동료 검토 전에 더 많은 버그를 발견하면 전체적으로 존재하는 버그 수가 줄어들기 때문에 결함 밀도가 낮아집니다.
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/