남들 따라하는 것이 아닌, 우리만의 코드리뷰 문화를 이야기해보고 결정하여, 정착시켰으면 합니다.
1-2. 코드리뷰를 하면 뭐가 좋을까?
자신은 알고 있는 부분을 타인에게 설명하면서 다시 생각을 정립할 수 있습니다. (자신 실력 상승)
타인에게 설명하기 위해 작성한 코드를 한번 더 보게 되어 스스로 확인하게 됩니다. (셀프 피드백)
코드를 짤 때 최대한 이해하기 쉽게 짜게 된다. (가독성 좋고, 좋은 코드 작성 가능성 상승)
자신이 개발한 부분만 아는 것이 아니라, 동료들의 부분을 좀 더 알게 되어 전반적인 서비스 로직의 이해도가 올라간다. (서비스 이해도 향상)
Code Convention(패턴)을 확실하게 통일할 수 있다. (통일성)
자신이 놓친 실수를 피드백하고 도와줄 수 있다. ( print문 실수, 오타 등 실수캐치 )
동료의 코드를 보면서 새로운 스타일이나 깨달음을 얻을 수 있습니다. (발전)
즉, 코드리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 한다.
2. 코드 리뷰 매뉴얼
2-1. 기본 규칙
서로의 잘못이나 오류를 지적하려는 의도가 아니라 피드백을 해주는 것이다. ( 공격적인 말투는 절대 X )
코드엔 정답이 없기때문에, 무조건 누가 맞는게 아니라, 함께 발전시키는 것이다.
질문을 하거나 대답을 할 때는 상대방이 상황을 전혀 모르다고 가정하고 충분한 문맥을 전달해야 한다.
당장 운영에 문제가 있는 hotfix건과 주석 제거와 같이 로직에 큰 변화가 없는 건은 스킵한다.
작은 작업 및 기능 단위로 PR(Pull Request)를 올리고, Merge 전에 코드리뷰를 진행한다.
2-2. 코드리뷰 규칙 ⭐️⭐️
PR남기는 사람
PR 본문은 PR 템플릿(Pull Request Template)에 따라 일관된 형태로 남긴다.
PR에는 최소 2명의 리뷰 담당자를 지정한다.
리뷰어
리뷰 담당자는 가벼운 마음으로 아래 역할을 수행한다.
오타 찾기 ( print문, 오타, convention오류 등 )
모르는 것 질문하기 ( 변수명, 비즈니스 로직 등 )
질문받은 사람은 이를 설명하면서 다시 복기할 수 있고 질문한 사람은 답변을 보고 로직에 관한 지식을 얻는 게 목적
새로운 대안 제시하기 ( 이건 A 목적인 건가요? A 목적이 맞는다면 이렇게 해보면 어떨까요?)
되도록 읽는 사람이 한 번에 정보를 확인할 수 있도록 한다. ( 가독성 생각하기 )
급한 우선순위 작업이 아니라면, PR을 틈틈히 Review하자 ( 당일 내로 처리하는 것 추천 )
리뷰할 것이 없으면, 칭찬남기기. → 모든 리뷰는 댓글에 하면된다.
만약 너무 바쁜 상황이라, Reivew를 하지 못할 상황이라면 다른 사람을 리뷰어로 지정해달라고 말하자.
2-3 Pull Request Template
제목
PR의 제목에는 가장 뒤에 [D-??] (??에 숫자 넣기)
언제까지 리뷰를 요청하는지 적기. (우선순위 파악 목적)
만약 오늘까지 리뷰를 해줬으면 하면, D-0이렇게 추가
Ex) D-1 이벤트 페이지 구현완료
본문
### 작업 분류
- [ ] 버그 수정
- [ ] 신규 기능
- [ ] 기존 기능 수정
### 기능 기획
<!--
왜 이 기능을 추가했는지 간단하게 적기
ex) 고양이가 울지 않으니 고양이 같지 않아서, 고양이 야옹소리 기능 추가
-->
### 작업 개요 ( 대분류 )
<!--
ex) 고양이가 야옹 소리를 내도록 수정
-->
### 작업 상세 내용 ( 상세 분류 )
<!--
ex)
1. 네 발 짐승 클래스에 `크앙` 함수 추가
2. 고양이 클래스에서 `크앙` 함수에 `미야아옹.wav` 재생시킴
-->
### 테스트 내역
<!--
ex)
1. 페이징이 잘 처리되는지 확인
2. 특정한 값을 넣었을때 제대로 처리하는지 확인
-->
아래 링크를 참고하면 PR Template 생성 가능 (Repository 관리자만 가능 - Bitbucket 관련)
리뷰 내용 가장 앞에 Pn을 입력하면 좋을 것 같습니다. ( 코멘트를 강조하는 수준 표현 )
P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
P2: 웬만하면 반영해 주세요 (Comment)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
P3: 그냥 사소한 의견입니다 (Approve)
작성자는 P3에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
3. 마무리
더 좋은 코드와 서비스를 만들기 위해서는 좋은 개발문화가 있어야 합니다.
현실에 타협하지 않고 더 좋은 서비스를 만들기 위해 코드리뷰 문화가 더 잘 정착하면 좋다.
억지로 하는 것은 문화가 아닙니다. 우리가 왜 하는지 알고, 함께 자발적으로 만들어나가는 것이 문화라고 생각한다.
코드리뷰 문화도 정답이 있는 것이 아니라 팀의 특성에 따라 잘맞는 방법이 다르다.
제가 쓴 것이 정답이 아닌, 함께 이야기해보고 자신의 팀에 가장 잘 맞는 코드리뷰 문화를 만들면 좋겠습니다.
