코드 리뷰에 대한 고찰

요즘 계속해서 동아리 앱을 개발하고 있다. 안드로이드 팀에서 코드 리뷰를 도입하며 느낀점을 정리했다.

코드 리뷰 목적

나는 몇 개의 앱을 출시 해본적이 있으나 같이 개발하는 팀원은 프로젝트 경험이 많지 않다. 어떻게 하면 팀원을 성장시켜 팀원이 프로젝트에 더 많은 기여를 할 수 있을까 고민을 했다. 방법 중 하나로 코드 리뷰를 도입하게 되었다. 내가 팀원의 코드를 리뷰하며 직접적으로 개선 방향이나 지식을 전달할 수 있다. 반대로 팀원이 나의 코드를 리뷰하며 팀원이 잘 모르던 부분을 코드를 보며 배울 수 있다.

다른 이유도 있다. 프로젝트의 품질을 높이고 싶었기 때문이다. 상호간 코드 리뷰를 하여 한 사람의 시각으로만 문제를 바라보지 않고 넓은 시각으로 접근하고 싶었다. 이는 잘못 작성된 코드로 인해 발생될 수 있는 문제들을 예방해주었다.

고수준에서 저수준으로

무작정 코드를 라인 단위로 살펴보며 수십개의 Change Request를 요청하는 것은 바람직하지 않다. 처음에는 전체적인 맥락을 파악하며 고수준에서의 코드 리뷰를 진행하자. 그 후에 저수준으로 접근하여 사소한 부분에서의 리뷰를 진행하자. 처음부터 사소한 부분에서만 리뷰를 진행한다면 작성해야할 리뷰 분량이 많아지고 리뷰를 받는 사람도 피곤해진다.

이유를 설명하자

리뷰 중 코드 개선이 필요하여 의견을 남길 때는 충분한 이유를 설명하자. 단순히 “변수 이름을 바꿔주세요.“와 같은 리뷰는 리뷰를 받는 사람이 왜 변경해야하는지도 모른채 수정을 진행하기 때문에 바람직하지 않다. 그렇기 때문에 리뷰에는 충분한 설명을 포함하자.

질문도 리뷰이다

리뷰를 통해 몰랐던 부분을 배우고 질문하여 지식을 채울 수 있다. 상대방의 코드를 통해 유용한 API나 라이브러리의 존재를 알 수 있다.

PR마다 코드 변경량의 크기는 적당히

PR마다 코드 분량이 500줄을 넘지 않는 것이 적당하다고 생각한다(물론 현실적으로 지키기 어려울 때가 있긴 하다). 너무 많은 변화가 있으면 리뷰어가 제대로 리뷰를 하기 어려워져 리뷰의 수준이 떨어지게 된다. 작업의 단위를 적절히 나누는 것이 중요하다.

또한 하나의 PR로 여러개의 이슈를 동시에 해결하는 것은 좋지 않다. 귀찮음 때문에 하나의 브런치에서 여러개의 이슈를 해결한다면 PR이 어떤 변경을 내포하는지 모호해지며 이로인해 리뷰어의 몰입도가 떨어진다.

어투

비언어적 요소가 없이 텍스트로만 이루어져 있기 때문에 감정 전달에 오해가 발생할 수 있다. 최대한 부드러운 어투로 전달을 하자. “이건 왜 이렇게 했죠? 고치세요.”식의 말투보다는(극단적이긴 하다..) “이 부분은 이러이러한 방법으로 구현하셨네요. 저러한 방법을 고려해보는건 어떨까요?”식으로 말이다.

테스트 코드

비지니스 로직을 포함한 부분에 테스트 코드를 작성하면 리뷰어가 앱을 빌드하며 직접 테스트하지 않고도 리뷰를 진행할 수 있기 때문에 리뷰어의 시간을 절약할 수 있다. 그리고 테스트 코드는 리뷰 외에도 장점이 많기 때문에 비지니스 로직을 포함한 코드는 꼭 테스트 코드를 작성하자.