Code Review를 해볼까?

💡코드리뷰 도입 이유

앞으로 한 달 뒤에 프로젝트를 진행할 예정인데, 지금까지는 팀원들과 코드 병합 목적으로 Github을 사용했다. 하지만 항상 구현만을 목표로 하고, 구현에 필요한 코드에는 관심이 없었다. 어떻게 하면 더 좋은 구조로 코드를 작성할지, 더 나은 접근법은 없을까 같은 고민을 하면서 개발 방향을 구현이 아닌 코드로 잡아보고자 코드 리뷰 도입을 생각했다.

코드리뷰란?

리뷰어가 구현한, 수정한 코드를 리뷰하는 것

코드리뷰하면 좋은점

1. 좋은 퀄리티의 코드
2. 결점을 초기에 발견
3. 배움과 지식을 전파(스터디 문화)
4. 상호간의 책임감을 가질 수 있다.

어디에 중점을 두어야 할까?

1. 기능 완성도
2. 코드 부작용 가능성
3. 가독성과 유지보수성
4. 일관성, 간결성
5. 성능
6. 예외처리
7. 재사용성
8. 테스트 범위

코드리뷰 단위를 얼마나 잡을까?

1. 우선 변경을 최소한으로 할 수 있는 코드를 작성하도록 노력하자.
   → 너무 잦은 코드 리뷰는 팀원들을 지치게 해 오히려 악영향을 끼칠 수 있다.
2. Commit 단위로 리뷰
3. 의미있는 단위 (To Do List)

Github Code Review

1. Issue 생성

   1. New issue
   2. 팀원과 정한 규칙에 맞게 이슈 제목 작성 (ex: [BackEnd] DB 연동)
   3. 작성한 코드/기능에 대한 설명 작성
   4. Assignees에 이슈 생성자 할당
   5. Labels에 이슈 종류에 맞는 카테로리 선택
   6. Submit new Issue

2. 자신이 작성한 코드 커밋

   1. git branch develop (브랜치 생성)
   2. Git checkout develop
   3. git add .
   4. git commit -m “comment”
   5. git push -u origin develop

3. Develop 브랜치에서 push를 하면 pull request

   1. request한 사람이 코멘트와 이미지를 첨부해 설명
   2. reviewer가 코드를 보면서 수정이 필요한 부분 또는 재사용이 가능하거나 더 좋은 방법이 있다고 판단되는 부분이 있다면 코멘트를 단다.
   3. request가 정말 merge 하면 안된다고 판단되면 Request Changes, merge해도 괜찮다면 Approve
   4. 팀원 중 몇명 이상이 Approve 한다면 merge

📌유튜브 참고
Github으로 Code Review 하는 방법