코드리뷰

코드 리뷰

코드리뷰란 코드를 검사하여 문제를 식별하고 소프트웨어 품질을 개선하는 데 사용되는 동료 평가 과정입니다. 우리는 이 과정에서 함께 성장할 수 있고, 제품에 대한 이해를 공유할 수 있습니다.

즉, 코드 리뷰는 교육 도구이며 문서화 도구로 쓰일 수 있습니다

코드베이스 변경을 리뷰한다는 것은 두 명 이상의 개발자가 프로덕션 코드를 숙지한다는 의미입니다. 코드베이스에 대한 이해를 공유하면 팀이 코드를 더 응집력 있게 개선하는 데 도움이 됩니다. 리뷰 과정에서 남긴 기록은 코드를 왜 이렇게 작성했는지 설명하는 문서의 역할도 수행합니다.

하지만, 잘못된 리뷰는 아무런 가치를 제공해 주지 못할뿐더러, 개발 속도를 더디게 합니다. 심지어 본연의 목적인 잠재적인 버그나 개선 사항을 놓치게 되고 시간을 비효율적으로 사용하게 됩니다.

올바른 코드리뷰

올바른 코드리뷰란 무엇일까요? 잠재적인 버그를 잡아낼 수 있어야하고, 함께 성장하며 제품에 대한 이해를 높일 수 있는 과정이 되어야 합니다.

리뷰 준비

우선 본인이 코드리뷰를 받을 준비가 되어 있어야 합니다. 잘 준비된 리뷰 요청은 다른 개발자가 쉽게 이해하고 건설적인 피드백을 줄 수 있게 만들어 줍니다.

리뷰어는 작성자에 비해 변경사항에 대한 지식과 정보가 부족합니다. 프로그래밍 언어에 대한 지식일 수도 있고, 변수가 담고있는 객체나 값에 대한 정보, 업무와 비즈니스 영역이 될 수도 있습니다. 이러한 결락은 코드의 내용을 이해하는데 장애물이 되고 혼란을 일으킵니다.

또한 일관적이지 않은 코드도 내용을 이해하는데 장애물이 되곤 합니다. 작성자가 의식적으로 지키지 않더라도 prettier나 eslint의 도움을 받을 수 있습니다. 관련 리뷰사항이 계속해서 발생한다면, rule을 추가 하는 것을 검토해야 할 것입니다.

작성자는 리뷰를 준비할때 다음 사항을 검토해 봐야 합니다.

MR이 코드 변경에 대한 충분히 설명을 담고 있는지
변경사항에 대한 테스트 방법을 명시했는지, 좀 더 나아간다면 테스트를 작성했는지
기획이나 디자인 링크 혹은 공식문서나 관련 포스트의 링크를 적절히 제공했는지

Self-Review

리뷰를 받기 전에 변경사항에 대해서 본인이 먼저 리뷰를 합니다. 각 변경사항에 대해 직접 주석이나 Review의 comment를 이용해서 설명합니다. 이러한 설명은 리뷰어에게 코드리뷰를 좀 더 수월하게 할 수있고, 맥락의 파악에 도움이 될 수 있습니다. 추가적으로 이 과정에서 발견하기 쉬운 결함을 쉽게 발견할 수 있고, 리뷰어에게 좀 더 리뷰에 몰입할 수 있게 도와 줄 수 있습니다.

적절한 리뷰의 양

뇌는 한 번에 처리할 수 있는 정보의 양이 제한적입니다. 코드의 변경사항이 많아지게 되면 결함을 발견하는 능력이 현저히 떨어집니다.

만약 리뷰의 양이 크다면 작성자에게 리뷰요청을 나눠줄것을 요청할 수 있습니다. 그렇지 않다면 작성자에게 팀원들을 대상으로 어떤 코드를 왜 변경했는지에 대해 설명하는 회의를 열 수도 있습니다.

적절한 코드의 라인 수

리뷰를 위한 시간 할애

시간 당 리뷰하는 코드의 양이 많아져도 결함을 발견할 확률이 떨어지게 됩니다. 적어도 한 시간에 500줄 미만의 페이스로 리뷰를 해야 적절한 코드 퀄리티를 유지할 수 있습니다.

적절한 시간당 리뷰 라인 수

그렇다고 5시간 6시간 계속해서 리뷰를 하는 것은 좋지 않습니다. 사람의 집중력은 60분 이상부터 떨어지기 시작합니다. 물론 중간중간 휴식시간을 가지며 진행한다면 업무의 질을 크게 향상 시킬 수 있다고 합니다. 하지만 검토를 몰아서 하기 보단 자주 진행하는것이 리뷰 생산성에 도움이 된다고 할 수 있습니다.

다음과 같은 루틴을 가지는 것을 검토해 볼 수 있습니다.

한 번에 60분이 넘지 않도록
한시간에 500줄 미만 페이스
매일 리뷰를 위한 일정시간을 할당

좋은 코드 리뷰 문화

결함이 나쁜것이 아닙니다. 결함은 팀의 코드 퀄리티를 끌어 올릴 수 있는 기회입니다. 주니어팀원에게는 시니어에게 배울 수 있는 좋은 기회이고, 경험이 많은 프로그래머도 안 좋은 습관을 고칠 수 있는 기회가 될 수 있습니다.
사소한 리뷰도 주저하지 말되 표시를 하자 리뷰의 의견마다 중요도가 다를 수 있습니다. 사소한 것도 리뷰를 남기는 것에 주저하지 말되 명확한 표시를 남길 수 있습니다. 가령 nit 로 표시해서 원저자의 선택의 맡기거나 self resolve 버튼을 누를 수 있도록 할 수 있다. 원활한 리뷰를 위해 Pn 규칙이나 이모지를 활용 하는 방법도 좋은 것 같습니다.
좋은 점은 인정하자 리뷰를 하다보면, 문제를 찾는 데만 급급할 수 있습니다. 리뷰가 항상 부정적일 필요는 없습니다. 좋은 점에 대해서도 의견을 남길 수 있습니다.
리뷰 초안(Draft)이 위험을 낮출 수 있습니다 많은 개발자들은 코딩을 통해 생각을 가장 잘 표현합니다. 리뷰 초안을 제출해서 지금 하고 있는 일의 방향이 맞는지 확인할 수 있습니다. 이를 잘 이용한다면 엉뚱한 방향으로 업무를 진행할 위험이 줄어듭니다.
어떻게든 결론을 맺어야 한다. 개선사항을 너무 오래 질질 끌어서는 안됩니다. 통상적으로 리뷰어는 전체적인 시스템 코드의 품질을 확실히 개선할 수 있는 상태가 되면 완벽하지 않더라도 승인을 해야 합니다. 물론 코드를 개선하거나, 추가 적인 아이디어가 생길 수 있습니다. 하지만, MR이 늘어지고 비대해지지 않도록추가적인 작업은 적당한 선에서 마무리 하고 추가적인 Issue나 티켓을 생성하도록 합니다.

참조

목차