Code Review에 대한 단상

6 August 2019 · 3 minutes read

Code Quality

코드 리뷰(Code Review)는 개발자가 작성하는 코드의 품질(Code Quality)을 유지하기 위한 활동이다.
코드의 품질은 여러가지 측면에서 측정될 수 있는데, 가장 많이 언급되는 항목들이 다음과 같다:

코드가 읽기에 얼마나 쉽고 예측 가능한지, 숨겨진 버그는 없는지, 코드의 수정과 개선이 복잡하지 않고 얼마나 단순한지 보는 것이다.
완전히 새로운 코드를 작성해나가는 것이 아니라면, 개발자는 코드를 작성하는데 대부분의 시간을 다른 사람이(혹은 과거의 스스로가) 작성한 코드를 읽고 분석하는데 보낸다.
코드가 복잡하고 예측하기 어려울 수록, 즉 코드의 품질이 낮을 수록 개발자의 생산성은 급격하게 낮아질 것이다.
그리고 마치 길목 어딘가에 방치된 쓰레기에 점점 더 많은 쓰레기가 쌓이는 것 처럼, 품질이 낮은 코드의 수명이 길어질 수록 더욱더 품질이 떨어지게 된다.

코드의 품질을 유지하기 위해 정적 코드 분석 도구를 활용하거나, IDE에 lint 도구를 함께 사용하는 등의 방법을 사용할 수 있다.
하지만 설계에 대한 논의, 즉 답이 true/false가 아닌 정해지지 않은 상황에서의 의사결정은 코드 리뷰를 통해 해결할 수 있다.

Code Review

앞서 코드 리뷰는 코드의 품질을 유지하기 위한 활동이라고 얘기했다. 하지만 이를 개발 프로세스에서 강제하기는 어렵다.
코드의 리뷰라는 절차가 개발 - 배포 사이에 추가 되는것 자체에 거부감을 가질 수 있으며, 코드 리뷰하는 행위가 자신에게 어떤 득이 되는지 체감되지 않는다. 그리고 당장 내가 해야 하는 일이 산더미인데 다른 사람이 작성한 코드를, 그것도 내가 잘 모르는 업무 영역의 코드를 읽고 논의를 하는 것 자체가 부담스러울 수 있다.
따라서 코드 리뷰는 ‘개발 문화’로서만 정착될 수 있다.

구성원간에 어떤 행위가 문화로써 정착이 되려면 그 행위가 구성원에게 어떤 득이 있는지 알려져야 하고, 그 행위가 강제적이지 않고 자연스러워야 한다. 그리고 이를 위한 적절한 도구가 있어야 한다.
내가 생각하는 코드 리뷰의 가장 큰 장점은 코드 리뷰 활동이 개발자간 서로 배움의 장이 자연스럽게 형성되는데 있다고 생각한다.
과거에 한번은, 일주일에 한번 팀의 모든 사람이 회의실에 참석하여 코드를 작성한 사람이 설계와 코드에 대해 설명하고, 다른 사람은 그 코드를 리뷰하는 시간을 가진 적이 있다. 강제적이었고 매우 부자연스러웠다. 회의실에서 진행하는 pt는, 코드를 리뷰하기에는 적절한 도구도 아니었다.
이제는 GitHub의 Pull request와 같은 도구를 활용해서 누구나 자연스럽게 리뷰 요청을 하고, 리뷰할 수 있는 장이 마련되었다. PR을 올리는 것 자체만으로 다른 팀원들에게 ‘소중한 시간을 내어 제 코드를 한번 봐주세요’라고 알리는 것이니 더 이상 미래의 나에게 미루거나 타협하면서 코드를 작성할 수 없다.
설계, 작게는 어떤 클래스의 속성에 대해 질의 응답할 수도 있고, 내가 미처 발견하지 못한 논리 오류를 알게 될 수도 있다.
다른 개발자의 업무 영역을 살짝 들여다 보고 배울 수도 있고, 리뷰를 남기기 위해 자료를 수집하면서 스스로 더 배울 수도 있다.

거창하게 생각할 필요도, 그렇게 시작할 필요도 없다. 일단 작은 수정 단위로 리뷰를 올려서 서로의 코드를 조금씩만 들여다본다면, 배움의 장이 될 뿐만 아니라 우리가 담당하는 제품의 코드 품질까지 두 마리의 토끼를 잡을 수 있지 않을까?

트윗 1. 이걸 보고 코드 리뷰가 히고 싶어진다면 정상입니다.

*코드 리뷰 가이드는 Code Review, github.com/thoughtbot을 참고히면 좋다.

Updated 6 August 2019