[우아한 형제들] 우아한 코드리뷰

[ 발표자 ]

박재성
- 우아한형제들 테크코스교육개발팀

[ 코드리뷰 환경 ]

- 교육 -> 깃헙
- 개발 -> 엔터프라이즈급 깃랩

[ 핵심 요약 ]

- 코드리뷰를 많이 하자 X / 코드리뷰를 많이 받자 O
- 코드리뷰 요청했을 때 첫 한시간 + 첫 코드리뷰에서 코드리뷰 질이 판단됨
-- 첫 리뷰어가 얼마나 공을 들이냐에 따라 다음 코드리뷰가 좋아진다.

 

[ 코드리뷰를 하는 이유 ]

- 개발자의 역할은 릴리즈 이후 지속적인 기능 변경, 추가 등 요구사항을 안정적이고 빠르게 반영하는 운영개발에 더 무게를 두기 때문 = 서스테이닝 업무
- 코드리뷰를 통해 소프트웨어 개발 생산성이 저하되지 않고 비교적 적은 비용으로 생산성 향상에 기여
- 출시 전 결함을 찾는것이 목적 + 팀원들의 피드백을 통해 동반 성장 하는 최고의 활동
-- 후배 개발자는 선배 개발자를 통해 배우고, 숙련된 프로그래머는 자신의 나쁜 습관을 고칠 수 있음
-- 다른 사람들이 내 코드를 리뷰한다는 사실 => 자연스럽게 더 나은 코드를 작성하도록 장려

[ 코드리뷰를 하지 말아야하는 이유 ]

- 업무량 증가
- 코드리뷰 병목 현상
- 예상할 수 없는 일정 (ex. 당장 릴리즈가 나가야하는 상황)
- 이기주의 (ex. 내 코드는 빨리 머지되기 바라지만, 남의 리뷰는 해주지 않음)
- 리뷰를 자신에 대한 비난으로 오해
- 책임 (ex. 코드 리뷰를 하고 나갔음에도 불구하고 이슈가 발생했을 때 나오는 문제에 대한 책임전가)

[ 좋은 코드 리뷰를 받는 방법 ]

1. 최적의 풀 리퀘스트(머지 리퀘스트, Line Of Code) 크기 찾기
- 리뷰가 1시간을 초과한다는 것은 문제가 많다는 것, 실패할 확률이 높음
-- 머지나 리베이스를 통해 소스가 변경될 가능성이 큼
-- 요구사항 자체가 변경될 가능성이 큼
- LOC가 200줄 이하일 때 결함 발견률이 크다.
- 코드리뷰에 쏟는 시간이 짧을 수록 결함을 많이 찾아냄
즉) 코드가 짧을 수록 코드리뷰 기간도 짧아지고, 결함도 많이 찾아낼 수 있다.
-- 현실적으로 어려운 이유는 하나의 변경만을 담지 않고, 기능변경과 리팩터링이 함께 일어나는 경우가 많기 때문

2. 커밋 메시지 (바로 윗줄 문제점을 해결하기 위한)
- build, ci, docs, feat, fix, perf, refactor, test
- 커밋 메시지를 통해 해당 커밋에서 작업한 내용에 대해 이해가 가도록 작성하도록
커밋 메시지 주도 개발

3. 테스트
- 리뷰어가 가장 빠르게 코드를 확인할 수 있는 방법
- 새롭게 추가된 코드나 버그 수정에 대한 단위 테스트가 충분한지 확인

4. PR 템플릿
- 리뷰어가 코드의 문맥을 빨리 파악할 수 있도록 충분한 정보를 제공하는 것이 중요
- 무슨 이유로 어떻게 코드를 변경했는지, 어떤 위험이나 우려가 발견되었는지에 대한 충분한 정보를 리뷰어에 제공하는
- 리뷰 받는 본인이 스스로 다른 에러들을 발견하게 되는 추가적인 혜택
ex) 해결하려는 문제, 어떻게 해결했는지, 어떤 부분에 집중해서 리뷰해야하는지(LOC가 많을 때)

RCA룰
- r : 꼭 반영 해주세요 (request changes)
- c : 웬만하면 반영해주세요 (comment)
- a : 그냥 의견 혹은 칭찬(칭찬이 중요, 개발을 계속 하게 만드는 원동력이 될 수 있음) (approve)

5. 정적 코드 분석과 코딩 스타일
- 리뷰어의 눈은 중요한 비즈니스로직과 알고리즘 확인을 위해 아껴두기
- 정적 코드 분석과 코딩스타일 확인은 소나큐브나 eslint와 같은 툴에 맡기자

6. 코드리뷰 드래프트
- 코드가 100% 준비되기 전에 검토하고 더 일찍 피드백 받는 방법
- 리뷰어가 작은 세부사항을 보지 않고 큰 그림을 찾는 좋은 신호
- 코드리뷰를 게시할 때 리뷰어가 이미 대부분의 코드를 검토했기 때문에 검토하는 데 필요한 시간도 줄어듦
- 스스로 먼저 코드리뷰 해봄

7. 오프라인 코드리뷰
- "코드 자랑 대회"라고도 부른다네 ㅎ
- 소프트웨어 장인
- 때론 글보다 말이 ?

[ 좋은 코드리뷰를 하는 방법 ]

코드리뷰 피라미드
1. code style : 
2. tests
3. documentation
4. implementation semantics
5. api semantics
- 1,2 : 자동화 / 3~5 : 이 부분을 리뷰하는 데 집중
https://velog.io/@broccolism/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0-%ED%94%BC%EB%9D%BC%EB%AF%B8%EB%93%9C
https://jiyeonseo.github.io/2022/04/03/the-code-review-pyramid/

RCA룰 사용
- r이 1개라도 있으면 무조건 수정
- c는 그냥 기분에 따라서
- a는 무조건 approve

[지속가능한 코드리뷰]

- 일시적으로 코드의 품질을 높이려 하지 말고, 함께 성장하기 위한 수단으로 리뷰를 활용
- 코드리뷰에 참여하는 구성원들의 인식이 같은 곳을 바라보는지 => 단순한 업무로 보는지/문화로 받아들이는건지
- 좋은 코드에 대한 기준을 맞추기, 토론이 중요
- 전체적인 코드 컨벤션 확립과 코드일관성을 유지하는 도구 도입
- 불필요한 리뷰로 시간 소비 금지
- 코드리뷰에서 발견된 결함은 팀 구성원을 평가하는 데 사용할 수 있는 기준이 되어서는 안됨
- 보상이나 승진의 기반이 된다면 개발자는 해당 프로세스에 적대적이 되므로, 그냥 문화로 받아들이자

 

---

형식적인 코드리뷰로 흘러가지 않는 방법
=> 오프라인 코드리뷰 등

결함이 없는 경우 어느 수준까지 피드백을 해줘야 하나
=> 명령형이 아닌, 청유형으로 리뷰를 쓰자, 월권행위라고 판단하는 것은 리뷰어가 아닌 리뷰이(리뷰를 올린 사람)이다.

코드 리뷰 관리를 위한 조직 혹은 전사적 기준
=> 우형은 깃랩을 관리하는 조직이 있음

기억에 남는 좋은 코드리뷰/ 나쁜 코드리뷰 사례
=> 리뷰어와 리뷰이의 적극적인 커뮤니케이션이 중요함, 일방적인 커뮤니케이션은 좋지 않음

코드의 품질이 어느 정도인지 정량적으로 판단하는 방법
=> 대표적으로 소나큐브, 코틀린 등을 사용

바쁜 프로젝트 일정에 방해가 되지 않게 리뷰하는 요령
=> 페어 프로그래밍을 통해서 개발을 하게 된 경우는 리뷰를 했다고 판단
=> 우형은 아무리 바빠도 개발 자체는 페어 프로그래밍을 함

좋은 코드 샘플을 접할 수 있는 방법
=> grep.app


DDD, (Given, When, Then)

혼자서 개발할 때 코드리뷰 하는 방법
=> "셀프 코드리뷰" 수행

코드리뷰 병목현상을 줄이는 부분
=> 코드리뷰하는 시간을 업무시간으로 아예 따로 빼서 다같이 코드리뷰 하는 시간을 갖도록 함
=> 리뷰가 너무 많으면 지정 리뷰어를 이용, 리뷰이가 리뷰어를 지정하거나 랜덤으로 지정하거나, 리뷰어는 2명 이상으로

전체 업무 시간 중 코드리뷰 시간
=> 배민 기준 32시간 기준 5시간 정도 / 5일 중에 하루

코드 리뷰 중 의견이 다른 경우
=> 결정권자 리뷰이 / 아키텍처인 경우는 PL