코드리뷰는 왜 하고 어떻게 해야 유의미해질까

코드리뷰는 여러 측면에서 중요한 과정이다. 

회사 입장에서는 개발자가 회사를 떠나도 코드는 유지되야 하고(지식경영(knowledge management) 측면), 개발자는 성장할 수 있는 기회를 가지게 되며 팀 입장에서는 팀워크와 코드쉐어링을 통한 장애에 대한 불안감을 감소시킬 수 있다. 

 

도입 전 고려사항

• 코드 리뷰에 참여하는 구성원들의 인식이 같은 곳을 바라보는가? 문화로 받아들일 준비가 되어있는가? 
• 어떤 코드가 좋은 코드에 대한 기준을 먼저 정하자. 
• 전체적인 코드 컨벤션 확립과 코드 일관성을 유지하기 위한 도구 도입하자. 불필요하고 소모적인 리뷰로 인해 시간 낭비, 리소스 낭비를 예방해야 한다

 

코드리뷰에 대한 방법 및 리뷰 작성 시 고려사항들

 

1. 하나의 프로젝트는 일관성이 있어야 하고 클린코드를 지향하자. 

코드를 읽는데 드는 비용을 줄일 수 있고 실수를 방지할 수 있다. 

ex) 함수선언방식의 통일등 일정 수준의 컨벤션을 정해 일관성을 유지하게 하자

 

2. 커밋과 풀리퀘스트는 30분 이내 리뷰가 가능하도록 잘라서 하자. 

단 리뷰는 커밋단위보다는 전체 코드 맥락을 살피면서 해주는 것이 좋다. 

 

3. 자신의 개발보다는 코드리뷰에 우선순위를 두자.

먼저 개발을 완료한 사람의 코드가 먼저 머지가 될 수 있게 해야 한다. 

 

4. 개선이 필요한 이유를 충분히 구체적으로 작성하자.

ex) “data라는 이름은 현재의 자료구조가 무엇인지 그 의도를 알기가 어렵네요.

학점 정보를 담고 있는 자료구조 같은데 이와 관련된 변수명을 짓는다면 현재 정의한 자료구조가 무엇인지 그 의도를 쉽게 파악할 수 있을 것 같아요.”

 

5. 리뷰이가 스스로 고민 후 개선방법을 찾을 수 있도록 하자.

ex) “자바스크립트에는 배열에는 다양한 내장 메서드들이 존재합니다. 그중 filter 메서드를 활용해 보세요. 이 메서드를 활용하면 코드량을 줄일 수 있습니다.”

 

6. 리뷰가 양방향 소통이 될 수 있도록 하자. 

수정이 필요해 보이는 사항을 설명 후 해당 부분에 대한 리뷰이의 의도가 따로 있었는지를 다시 물어본다. 

왜 이렇게 짰는지를 직접 고민하고 설명할 수 있어야 한다. 

 

7. 리뷰를 위한 리뷰를 하지 말자. 잘한 건 칭찬해 주자. 

• 코드량이 적당해서 읽기 편하네요.
• 많은 고민이 코드에서 엿보이네요.
• 성능에 아주 유리한 코드라고 생각되네요.
• 전에 코드보다 훨씬 좋아진 거 같네요.
• 예외 처리가 꽤 꼼꼼해서 좋네요.
• 함수, 변수명이 직관적이어서 좋네요.

 

8. 리뷰 내용이 설계전반을 변경해야 한다면 코드를 짜기 전에 pre commit review를 활용해 보자.

프리 커밋 리뷰란, 'GitHub에 커밋이 되기 전의 리뷰'라는 뜻으로 실제 코딩 작업에 들어가기 전에, 어떻게 작업을 진행할지 가볍게 논의해 보는 리뷰를 말한다.

코드를 리뷰하는 대신 디자인 시안이나 요구 사항을 보고 어떻게 작성할지 이야기해 보는 사전 리뷰 단계인 것이다.

 

기대효과

1. 우선 앞서 이야기한 과도한 설계 변경에 대한 리뷰는 없을 것이다.
2. 서로의 관점을 공유함으로써 설계에 대한 인사이트를 얻을 수 있고 코드 품질에 대한 기준을 맞출 수 있다.
3. 해당 제품(또는 기능)의 도메인을 알아볼 수 있는 기회가 될 수 있다.
4. 코드 리뷰를 하게 됐을 때, 리뷰어 입장에선 리뷰 대상인 코드를 파악하기 쉬워지고, 이로 인해 깊은 코드 리뷰가 가능해진다.
5. 무엇보다 기능을 개발하기 전에 많은 고민을 하고 개발하기 때문에 빠르게 개발할 수 있다.

9. 코드리뷰로 인한 병목이 심하다면 제약이 없는 코드리뷰를 도입해 보자. 

Pull Request를 등록하는 개발자는 이 Pull Request를 통해 성장하고 싶을 때, 리뷰를 요청하면 된다. 리뷰 요청을 받는 사람은 기꺼이 리뷰에 응하면 된다.

• 모든 Pull Request에 대해서 리뷰를 하지 않아도 됐기 때문에 코드 리뷰 양이 적어졌다.
• 코드 리뷰 양이 적어졌기 때문에 요청이 들어왔을 경우 좀 더 빠르게 확인할 수 있게 되었다.
• 코드 리뷰가 스프린트의 병목이 될 가능성을 낮췄다.
• 심지어 리뷰가 필요한 Pull Request에서 리뷰가 요청이 왔으므로 유의미한 리뷰가 오갈 수 있는 확률이 더 많아졌다.

10. 사람이 아닌 코드를 리뷰하라. (영어 리뷰를 도입해 보자)

한글로 작성할 때보다 말투가 잘 드러나지 않고(이건 영어를 한국어만큼 자유롭게 사용하지 못해서이지 않을까 싶지만..) 

영어로 길게 작성하는 것은 어렵기 때문에 정말 중요한 이슈에 대해서는 서면보다는 대면으로, (페어 프로그래밍)으로 이뤄질 수 있다. (이것도...)

[출처]https://dbr.donga.com/article/view/1203/article_no/10411

 

11. pr의 라벨기능을 잘 활용하자.

ex) 리뷰 과정에서 새로운 관점을 배웠거나 좋은 리뷰라고 생각되는 Pull Request에는 Good Review라는 라벨로 표시하여 나중에 모두가 같이 볼 수 있도록 활용하자

[출처] https://tosspayments-dev.oopy.io/chapters/frontend/about#c73b64d5-0d73-4b5d-9ede-9cddcb6d4012

12. 코드리뷰를 할 여건이 되지 않는다면 고무오리디버깅(Rubber Duck Debugging)을 활용해 보자.

고무오리디버깅은 문제가 잘 해결되지 않을 때 고무오리에게 설명하는 방법. 

혼자 코드리뷰를 할 때도 동료에게 설명하듯 스스로 회고하고 개선방법이 있다면 메모를 남겨두자.

 

 

결론

- 잘 구축된 코드리뷰 시스템은 리뷰하는데 드는 시간보다 아끼는 시간이 더 크다. 빨리 가는 유일한 방법은 제대로 가는 것이다.

- 리뷰는 함께 성장하기 위한 수단으로 사용하자. 

 

참고

Google의 코드리뷰 :https://google.github.io/eng-practices/review/

Tricorder라는 정적 분석(잠재결함 분석) 도구와 Rosie라는 코드 정리 시스템(Large-Scale Cleanups and Code Changes)을 활용해 사용하지 않는 코드는 없애고 리팩토링이 필요한 경우에 효율적으로 리뷰를 한다고 알려져 있다

 

구글에서 코드리뷰 시 lgtm(look good to me) 를 얻으려면 다음의 세 가지 측면에서의 리뷰를 통과해야 한다.

• 첫째, 다른 엔지니어로부터 정확성(correctness)과 이해 용이성(comprehension)을 평가받습니다.
  즉, 작성자가 의도한 작업을 코드가 적절하게 수행하는지를 봅니다.
• 둘째, 변경되는 코드 영역을 관리하는 코드 소유자로부터 변경 코드가 적절하다는 승인을 받습니다.
  구글의 코드베이스는 트리 구조로 되어 있고, 디렉터리별 소유자들이 계층적으로 할당되어 있습니다. 그리고 소유자는 자신이 맡은 디렉터리의 문지기 역할을 합니다. 변경은 아무 엔지니어나 제안할 수 있고 LGTM도 제안자 외의 모든 엔지니어가 달 수 있습니다. 하지만 코드베이스에 변경을 반영하려면 해당 디렉터리 소유자의 승인이 반드시 필요합니다. 
• 셋째, 누군가로부터 ‘가독성’ 승인을 받습니다. 즉, 변경 코드가 해당 언어의 스타일과 모범 사례를 잘 따르고 조직에서 기대하는 방식으로 작성되었는지를 검사받습니다. 

 

참고한 사이트들

Code Review Developer Guide

효과적인 코드리뷰를 위한 리뷰어의 자세

코드 리뷰의 목적은 성장이어야 한다

토스페이먼츠 프론트엔드 챕터를 소개합니다

[DBR] 지속가능한 기술력 핵심은 ‘코드 리뷰’, 개발자 떠나도 제품 연속성 유지 가능

코드 리뷰 | TechWell

LGTM이 뭐지? : 구글의 코드 리뷰 & 코드 리뷰 유형