인터넷에 찾아보면 코드 리뷰를 진행해야 하면 좋은 이유가 많이 있지만 사실 실감하기는 어렵습니다. 라피신 과정에서 첫 평가를 진행하며 자연스럽게 코드 리뷰를 시작하기는 했지만 왜 해야 하는지에 대한 고민은 잘 하지 않았던 것 같기도 하고요. 필자는 "합법적으로 내가 풀어야 할 과제의 풀이법을 듣는 자리", "많은 것을 배울 수 있는 자리"라고는 생각했지만, 사실 그건 동료 평가에 대한 생각이었지, "코드 리뷰"에 대한 생각은 아니었던 것 같습니다.
그렇다면 왜 코드 리뷰를 진행해야 할까요?
만약 서비스되고 있는 git에 누군가 버그가 담긴 코드를 실수로 main에 올리면 어떤 일이 일어날까요? 당장 배포 중인 서비스가 마비될 것입니다. 반면에 merge 전, 코드 리뷰가 필수적으로 필요하다는 규칙이 있다면 어떻게 될까요? 다른 누군가가 확인하고 사전에 오류를 예방할 수 있을 것입니다.
이처럼 코드 리뷰를 진행하면 사전에 문제를 발견하고 제거할 수 있습니다.
또한 인수인계의 용이성도 있는데요. 사전에 merge 한 코드에 대해서 문제가 발생한 경우, 코드를 작성한 사람이 아닌 코드 리뷰를 진행한 사람도 복구가 가능합니다. 이 경우 복구 시간을 줄일 수 있겠죠?
코드 리뷰를 잘 진행하면 할수록 맥락 공유에 있어서 더 유리한데요. 갑작스럽게 인력에 변수가 생겼을 때 대처하기 더 쉽게 하고, 엔지니어 가담 가능성을 높일 수 있습니다.
각자 다른 개인의 방식을 하나의 팀으로 합의시키고, 코딩 컨벤션부터 전반적인 설계 원칙까지 점진적으로 맞춰가는 데 도움을 줍니다. 만약 이런 것들을 정해놓기만 하고 코드 리뷰를 진행하지 않으면 지적하는 사람이 없기 때문에 점점 코드 스타일은 통일감이 없어지고, 인수인계 및 디버깅에 어려움을 만들 것입니다.
반면에 코드 리뷰를 진행하며 컨벤션에 관하여 고치기며 계속해서 요청(request changes)한다면 팀의 방식으로 합의시켜 코드 이해에 쉽게 하고, 코드 리뷰 진행을 더 쉽게 만들며, 오류를 잡는 데에 도움을 주어 다시 제품 품질의 향상과 보존에 도움을 줄 것입니다.
그렇다면 코드 리뷰가 왜 좋은지 알아보았으니, 절차와 규칙에 대해서 알아볼까요?
- 왠만하면 PR를 올린 하루 내로 코드리뷰를 하자.
- 진행하는 과정에서 생기는 궁금증은 바로 해결한다.
- 각 질문들은 코멘트로 남긴다.
- 이에 대한 해결안도 꼭 코멘트로 남긴다.
- 리뷰어가 납득해야 한다.
- 코드 작성에 합당한 이유가 있어야 한다.
- 2명의 동의가 있어야 한다.
- 만약 리뷰어가 이해를 하지 못할 경우 그 자리에서 코드리뷰를 종료하고, 어떤 방향으로 수정할 지 결정하고 같은 PR에 작성한다.
- 만약 결정이 나지 않는다면 제 3자를 부른다. (주로 리더를 호출)
- 수정이 필요한 경우 그 PR를 유지해서 같은 리뷰어에게 코드 리뷰를 다시 진행한다.
-
최대한 PR를 주기적으로 올린다.
: 너무 많은 코드를 올리면 리뷰하기 정말 힘들겁니다.
: 기능 정의서에 있는 단위마다 대신 같은 플로우에 있는 기능을 묶어서 진행합니다.
-
최대한 git을 올바르게 사용해서 리뷰 준비.
: CI 파이프 라인이 통과되는지를 먼저 체크
-
열심히 구현한 코드를 PR을 올린다.
: 최대한 자세히 어느 부분을 구현했는지 적고 자신이 생각할 수 있는 오류의 상황을 미리 적어본다.
: 리뷰어 설정을 한 뒤 최대한 오프라인으로 진행. 만약 상황이 힘들다면 온라인을 진행.
-
모든 준비를 한 뒤 리뷰어에게 디스코드로 연락
-
코드 리뷰 요청을 받으면 PR를 읽고 에러 상황을 예측하자.
: 추상화의 정도와 전체적인 로직을 쭉 파악하자.
: 이것까지 봐야하나 싶은 것도 보고, 중요한 로직은 더더욱 집중해서
-
리뷰 자체를 두려워 하지 말고 자신의 생각을 이야기하자.
: 모르는 부분이 있다면 모른다고 이야기해서 자신의 걸로 흡수하자.
: 만약 고칠 부분이 있다면 최대한 자세히 설명하고 참고할만한 레퍼런스를 제시해서 빠르게 이해해서 고칠 수 있게 하자.
-
고칠 부분이 없다면 칭찬하자.
: 칭찬은 고래도 춤추게 한다. 굳이 빈틈을 찾지 말자.