코드리뷰 작성 가이드
TIL## **우리는 왜 코드리뷰를 해야하나요?**
:fire: “소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다.
그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.”
- **버그의 조기 발견**(불필요한 시간과 비용을 절감)
- **개발 컨벤션 준수**(가독성과 유지보수 편의성 극대화)
- **중복 코드 방지 및 모듈의 재사용성 증대**
- **배움의 기회**(‘아, 이렇게 쉬운 방법이 있었구나?’)
## **우리의 코드 리뷰 규칙**
- 2일 이내에 리뷰를 완료하여 리뷰의 병목을 해소합니다. (피쳐 마감 일자에 따라 우선순위를 결정합니다.)
- 이슈가 있다면 페어프로그밍으로 같이 해결합니다.
- 각자의 개발스타일은 다릅니다. 기존에 자신의 스타일이 정답이라는 생각을 버리고, “나의 의견은 이러한데 당신은 어떻게 생각하시나요?”와 같이 의견을 묻는 것이 좋습니다.
- 리뷰어가 진행해주는 QA 중 이슈가 발생된다면 리뷰이는 코드 변경사항과 개발된 피쳐와 관련된 모든 사항에 대해 전체 테스트 및 확인을 다시 진행합니다. 놓친 부분이 한 군데 발생된다면 다른 곳도 꼼꼼하게 다시 한번 점검하는 것이 좋습니다.
- 공통 컴포넌트를 수정한다면 사용하고 있는 모든 부분을 체크하여 side effect 여부를 확인합니다.
- 앞으로도 함께 만들어가는 문화이니 어떻게 진행할지 같이 고민해봐요 :slight_smile: 언제든 의견 주세요<span dir="">\~</span>
## 리뷰 체크리스트
:grinning: MR올리기 전 아래 내용을 확인해주세요.
* [ ] **merge할 브랜치의 위치를 확인**하셨나요?
* [ ] **코드의 맥락(CONTEXT)을 이해할 수 있는 설명을 추가하셨습니까?** (ex.로그인 시 발생하는 이메일 인증 오류에 대한 버그 수정입니다)
* [ ] **기능이 정상적으로 동작**하나요?
* [ ] 변수명 등을 **통일성 있게, 축약 또는 생략하지 않고** 작성했습니까?
* [ ] **개발 컨벤션에 준수**하여 작성했습니까?
:grin: MR 올린후
* [ ] **기존 코드와 충돌이 발생**하면 머지 버튼이 비활성화 되기도 합니다! 그 부분까지 체크하여 충돌을 해결해야 리뷰를 진행할 수 있습니다.
:robot: **프로젝트를 진행하면서 체크리스트는 더효율적인 코드 리뷰를 위해 수정될 수 있습니다.**
## 리뷰어 체크리스트
:laughing: 팀원들은 체크리스트를 보며 코드리뷰를 진행해주세요.
* [ ] **왜 개선이 필요한지 이유를 충분한 설명**해주셨습니까?
* [ ] 작은 커밋 단위만을 보지 말고, **전체 코드의 맥락을 살피면서 리뷰**를 해주세요.
* [ ] **이해가 안가는 부분이 있다면 질문**해주세요.
* [ ] 리뷰를 위한 리뷰를 하지 마세요. **피드백 할 게 없으면 칭찬**해 주세요.:heartbeat:
:raising_hand_tone1:**리뷰를 어떻게 해야할지 모르겠다면 이 글을 한번 봐주세요**
https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/
https://blog.logi-spot.com/코드리뷰의-진짜-목적은-따로있다/
https://xo.dev/github-collaboration-guide/ 깃헙에 코드리뷰 요청 보내는법
https://www.youtube.com/watch?v=9FZaYz0s8s4 라매개발자 깃헙 코드리뷰 협업
cf. 체크사항
> ### **배울만한 점은 없는지**
>
> 코드리뷰에 많은 사람이 오해하는 부분 중 하나는, 경력이 많거나 실력이 뛰어난 개발자가 후배 개발자의 코드를 검사한다고 생각하는 것입니다. 코드리뷰에서 코드의 작성자와 리뷰어는 누가 더 경력이 높거나 낮을 필요가 없습니다. 또한, 코드리뷰의 목적은 코드 작성자에 게 피드백을 주는 것도 있지만, 해당 코드를 보면서 ‘아, 이런 식으로 코드를 작성하는 것도 가능하구나?’, ‘아, 이렇게 쉬운 방법이 있었구나?’와 같은 학습효과도 함께 가지고 있습니다. 그렇기 때문에 코드를 리뷰할 때는 피드백을 주기 위한 시각과 좋은 점을 배우려는 시각, 이 두 가지 시각의 균형을 맞추며 진행하는 것이 좋습니다.
'TIL' 카테고리의 다른 글
redux 내부는 context API 로 돌아간다고 하던데 그 작동원리를 알려줄 수 있어? (0) | 2024.08.09 |
---|---|
노드 버전 관리자들 중 Volta는 여러 버전의 프로젝트를 유지해야하는 환경에서 유리합니다. (0) | 2024.08.09 |
React - event handler 이벤트 핸들러의 e 는 어떻게 전달되는 걸까? (0) | 2021.11.15 |
시니어 프론트엔드 개발자처럼 크롬 개발자도구 사용하기 (0) | 2020.09.08 |
React- hooks (0) | 2020.01.29 |