7장 올바로 주고받는 코드 리뷰

[fkdl0048]

7장 올바로 주고받는 코드 리뷰

원활한 팀 협업과 높은 코드 품질을 목표로

대부분의 팀은 변경한 코드를 머지하기 전에 리뷰를 진행한다. 고품질 코드 리뷰 문화를 갖추는 것은 엔지니어 수준과 관계없이 모두가 함께 성장하며 코드베이스에 대한 이해를 서로 공유하는 데 도움이 된다. 반면 잘못된 코드 리뷰 문화는 혁신을 방해하고 개발 속도를 늦추며 사적인 감정 소모만 쌓이게 된다.

테스트 코드와 마찬가지로 잘못된 코드리뷰, 성숙하지 못한 팀에서는 오히려 악 형향이 된다.

코드 리뷰는 왜 필요한가

잘 수행된 코드 리뷰는 엄청난 가치를 지닌다. 버그를 찾아내고 코드를 깔끔하게 유지할 수 있다는 표면적이지만, 명확한 장점도 있는 한편, 자동화된 테스트나 런터 외에도 사람이 개입을 한다는 것 이상의 가치를 지닌다.

이는 교육 도구로서 동작하며, 인식을 확장시키고, 구현 결정 사항을 문서화하며, 보안 및 규정 준수와 관련해 변경 기록을 제공한다.

진짜 맞는 말만 하지만, 위에서 말한대로 이는 성숙한 팀에서만 가능한 이야기일 수 있다..

코드베이스 변경을 리뷰한다는 것은 곧 두 명 이상의 엔지니어가 한 줄 한 줄 모든 프로덕션 코드를 숙지한다는 의미다. 코드베이스에 대한 이해를 공유하는 것은 팀이 코드를 더 응집력 있게 개선하는 데 도움이 된다.

리뷰의 댓글 기록은 왜 이렇게 작성했는지 설명하는 문서로서의 역할도 수행한다. 코드가 왜 이와 같은 방식으로 작성됐는지 그 이유를 항상 명확히 이해할 수 있는 것은 아니다. 이럴 때 코드 리뷰는 세부 구현에 대한 결정 과정의 기록으로 활용할 수 있다.

일종의 문서화가 자동적으로 진행된다.

코드 리뷰의 모든 장점은 참여자가 신뢰도 높은 다른 말로 서로 믿는 관계에서 진행해야 효과가 나타난다. 형편없는 코드 리뷰는 오히려 장애물이 되기 때문에 개발속도가 더디게 된다

코드 리뷰는 얼마나 똑똑한지 증명하는 기회가 아닐 뿐더러 상대방이 관료주의적인 장애물이라고 낙인 찍는 기회도 결코 아니다.

코드 리뷰를 제대로 받는 방법

코드가 변경되는 과정을 보면, 우선 필요한 코드를 변경하고 이를 제출한 후 승인 받아 머지하는 과정으로 이뤄진다. 이는 PR(Pull Request)를 통해 이뤄진다.

코드 리뷰를 받을 때 준비해야 할 사항

잘 준비된 리뷰 요청은 결국 어떤 작업을 했는지 다른 개발자에게 쉽게 피드백을 전달할 수 있다. 이를 버전 제어 시스템을 통해 변경을 더욱 작게 유지하고 리팩터링 작업은 다른 리뷰로 분리하고, 테스트 등등의 작업까지 모두 포함해야 한다.

리뷰 초안이 있으면 위험을 낮출 수 있다

초안은 어디서나 시작할 수 있는 강제성을 주기에 매우 효과적이다. 다른 양식이 아닌 일원화시키거나 체크리스트의 역할도 한다.

테스트 실행을 위한 리뷰 제출은 금물이다

대규모 프로젝트는 복잡한 테스트 도구를 사용하는 경우가 많다. 이 경우 CI시스템을 사용하여 이 문제를 해결하기도 한다. 하지만 테스트를 실행할 목적으로 코드 리뷰를 제출하는 것은 낭비다.

따라서 테스트를 로컬에서 실행할 수 있는 방법을 알아보자. 로컬에서 더욱 디버깅이 용이하기 때문에 빨리 알아낼 수 있다.

코드 변경사항이 많을 때는 좀 더 면밀하게

변경한 코드가 많으면 다른 사람에게 설명하는 시간을 갖는 것이 좋다. 같은 멘탈 모델을 공유하고, 코드 변경사항을 이해하는 데 도움이 된다.

자신의 코드에 너무 집착하지 말자

코드에 비판적인 의견이 달리는 것은 견디기 어려운 일이다. 그렇다고 그런 의견을 너무 감성적으로 받아들여서는 안된다. 리뷰는 코드에 대한 것이지, 개발자에 대한 것이 아니다.

공감력을 갖되 무례함은 참지 말자

의사소통 방식은 누구나 다르지만 무례함은 그냥 넘겨서는 안 된다. 누군가의 말이 '요점만 간단히'가 아니라 '퉁명스럽고 무례한' 방법이 될 수 있다. 리뷰어에게 자유는 허락하되, 리뷰어의 댓글이 요점을 벗어나거나 무례한 경우에는 사실대로 알려주자.

주도적으로 행동하자

다른 사람에게 여러분의 코드를 리뷰해달라고 부탁하는 일을 너무 부끄러워 하지 말자. 리뷰어는 수많은 코드 리뷰 요청과 타켓 관련 알림을 받으므로 속도가 빠른 프로젝트에선 리뷰를 놓치는 경우도 있다.

코드 리뷰를 제대로 해주는 방법

훌륭한 리뷰어는 리뷰 요청을 몇 단계로 나눈다. 요청을 선별함으로써, 요청의 긴급도와 복잡도를 결정하고 그 변경사항을 리뷰할 시간을 마련한다.

리뷰 요청을 선별하자

리뷰에 대한 요청의 중요도를 선별하는 것부터 시작해야 하며, 중요도가 높으면 곧바로 리뷰를 진행해야 한다. 그 외에도 해당 팀의 선별 기준이나 리뷰어의 선호도에 따라 리뷰 요청을 선별할 수 있다.

리뷰를 위한 시간을 마련하자

코드 리뷰는 운영 업무와 유사하다. 리뷰의 횟수와 빈도는 다소 예측 불가능하다. 리뷰 요청을 받을 때마다 하던 일이 중단돼서는 안 된다. 리뷰 시점을 잘 선택하지 않으며 리뷰를 하느라 오히려 생산성이 떨어진다.

따라서 일정상에 코드 리뷰를 위한 시간을 마련해두자.

코드 변경사항을 이해하자

다짜고짜 의견부터 남기는 식으로 리뷰를 시작해서는 안 된다. 먼저 읽어본 다음, 필요한 질문을 충분히 해본다. 결국 코드 리뷰란, 리뷰어가 해당 코드의 변경 목적을 이해할 때 비로소 그 가치가 나온다.

포괄적인 피드백을 제시하자

변경의 올바름, 구현, 유지보수성, 적합성, 보안성 등에 대한 피드백을 제공하라. 스타일 가이드나 읽어 어렵다거나 헷갈리는 부분도 지적하고, 테스트 코드를 읽어보고 발생할 수 있는 버그에 대해서 조언하라.

의견을 지나치게 간결하게 쓰지도 말자. 정중하게 표현하려는 방식과 그 이유를 설명하자.

좋은 점은 인정하자

코드를 리뷰하다 보면 문제를 찾는 데만 급급해질 수 있지만 코드 리뷰가 항상 부정적일 필요는 없다. 좋은 점에 대해서도 의견을 남기자! 코드를 읽으면서 뭔가 새로운 것을 배웠다면 그 점을 언급하자.

이슈, 제안, 사소한 흠결은 잘 구분하자

리뷰 의견은 중요도가 서로 다르다. 중립적인 제안과 사소한 흠보다는 중요한 이슈에 더 신경을 써야 한다. 스타일에 대한 피드백을 남기는 것을 주저하지는 말되 사소한 일임을 명확히 표시하자.

• 선택적 제안, 원저자에게 맡김, 승인과는 무관 등의 접두어를 사용하여 반드시 필요한 것은 아님을 표시하자.

대충대충 리뷰는 금물

코드를 제대로 보지도 못했는데 리뷰를 승인해야 하는 부담에 시달릴 수 있다. 급한 변경이나 동료로부터의 압박, 얼핏 보기에 쉬운 듯한 변경, 반대로 변경 규모가 너무 큰 리뷰를 마주하면 이런 부담을 느낄 수 있다.

따라서 그의 입장을 고감하여 리뷰를 빨리 마무리하자라고 생각할 수 있지만, 이런 유혹에 넘어가 대충 리뷰한다면 오히려 더 많은 시간을 낭비하게 된다.

웹 기반 리뷰 도구에만 의존하지는 말자

코드 리뷰는 보통 깃허브 PR 인터페이스 같은 전용 UI로 처리한다. 이런 코드 리뷰는 단지 코드만 살펴본다는 점을 잊지 말자. 언제든 변경사항을 체크아웃하고 다운로드해서 로컬에서 실제로 실행해볼 수 있다.

가능하다면 로컬에서 코드를 실행해보고, 테스트를 실행해보자.

테스트 리뷰도 잊지 말자

테스트 코드를 먼저 읽어보고 리뷰를 시작하는 편이 유용할 때도 종종 있다. 테스트 코드는 실제 코드의 동작 방식과 사용 방법을 설명해준다. 코드의 유지보수와 간결함을 위해 테스트를 반드시 확인하자.

어떻게든 결론을 맺어야 한다

개선사항을 너무 오래 질질 끌지는 말자. 리뷰 요청자가 신속히 승인을 받을 수 있게 도와주자. 지나치게 완벽을 추구하지는 말고 변경의 범위를 확장하지 말며 어떤 댓글이나 의견이 중요한지 명확히 묘사하고 서로 동의하지 않는 부분이 곪아 터지지 않도록 주의하자.

좋은 품질을 추구해야 하지만 고집스런 불통의 자세는 금물이다.