Code Review를 잘하는 방법

Code Review를 잘하는 방법

• 코드리뷰란
• 코드리뷰 핵심
• 작성자 관점
• 리뷰어 관점

코드리뷰란

정의

새로운 코드를 작성했을 때 기존의 코드에 합치기 전, 새롭게 작성된 코드에 대한 의견을 나누는 과정

Bus Factor

일종의 하이 리스크를 측정하는 용어 중 하나

같이 프로젝트를 하는 팀원 중 한 명이 버스에 치여서 병원에 입원(혹은 사망)해서 프로젝트에 참여하지 못했을 때 그 프로젝트에 위기가 오느냐 오지 않느냐를 측정하는 낮을 수록 좋지 않은 수치

Bus Factor가 낮다는 이야기는 프로젝트 내 특정인에게 모든 정보가 많이 쏠려 있고 공유가 잘되지 않는다는 의미

조직에서 Bus Factor 값을 높이기 위해서 하는 활동 중 하나가 코드 리뷰

코드리뷰 핵심

코드 리뷰의 궁극적인 목표는 작성자와 리뷰어가 다름

작성자는 기능 구현을 위해 만든 코드를 빠르게 배포하는 목표

리뷰어는 코드를 꼼꼼하게 확인해서 프로젝트의 리스크를 줄이는 데 목표

작성자 관점

코드는 코드일 뿐 감정적인 수용 금지

리뷰어의 좋은 의도를 생각하고 꼰대 마인드셋을 버리고 제안에 대해 감사하며 불치하문의 자세

배움과 성장의 기회로 삼고, 동일한 지적을 받지 않도록 개선 노력

PR(코드 변경)을 최소한으로 작게

가급적 한 PR에 LOC(Line Of Code)는 400줄 이하로 작성

버그 하나 당 하나의 PR로 작성

버전 업데이트 및 리팩토링은 별도의 PR로 분리

규모가 큰 변경 사항은 의미 있는 작은 단위 PR로 각각 분리

리뷰어가 질문 없이도 맥락(Context)을 이해할 수 있도록(Why) 정보 제공

리뷰어가 질문없이도 코드리뷰를 할 수 있게끔 필요한 맥락(Context)를 제공

빠른 시일 내 리뷰를 받도록 최선의 노력이 필요

기능을 구현하고 한참이 지나도록 리뷰를 못 받은 건 작성자의 잘못

빠른 시간에 리뷰를 받고 피드백을 반영하여 최종 승인을 받는 것이 코드 리뷰의 완성 목표

리뷰어가 리뷰한 내용에 대하여 명확하게 반응 전달

리뷰어가 리뷰를 해줬다면 그에 대해 확인했거나, 질문이 있거나, 동의하지 않는다면 그에 대한 반응을 즉시 명확하게 해주는 것은 필수

ack(Acknowledge)와 같은 축약어의 사용도 좋음

리뷰어 관점

컨벤션에 관한 리뷰는 자동화

작성자의 좋은 의도를 전제하여 수용

각자의 생각에 따른 craft방식이 다를 수 있기 때문에 리뷰어가 생각하는 방향이나 방식과는 다를 수 있기 때문에 오픈마인드로 작성자의 의도를 수용하고 호기심을 가지고 친절하게 코드 리뷰

필요하다면 의도나 해당 코드 작성 배경에 대한 질문

해결사가 아니라 조언자일 뿐이라는 마인드로 리뷰

코드가 잘못된 부분이 있더라도 잘못된 게 아니라 그저 방식이 다르기에 ‘좀 더 낫다고 생각하는 참고할만한 다른 방식을 조언한다’는 마인드로 친절하게 코드 리뷰

명확하고 구체적인 피드백

뭉툭하고 추상적인 피드백 대신 최대한 구체적으로 이유와 함께 대안/추천하는 방법을 제안

일반적인 코드리뷰가 아닌 리뷰어라면 구체적으로 어떤 줄을 어떻게 변경할지 예시를 들어가면서 피드백

중요성에 따라 명확한 행동을 요구

리뷰할 때 접두어를 통해 의도를 강조해주는 편이 작성자가 피드백을 수용하고 반영할 때 도움

접두어 예시

• 질문 QQ(Quick Question)
• 마이너옵션 NIT(Nitpicking)
• 변경 요청 RC(Request for Change)

리뷰 완료 여부를 명확하게 반응 전달

승인이나 변경 요청 혹은 질문에 대해 명확하게 리뷰 진행 상태나 상황을 전달하여 작성자가 의구심을 가지지 않게끔 배려