Code Review Rule 은
다른 사람이 작성한 코드나 문서를 확인할 때
어떤 기준으로 검토할지 정해두는 규칙이다.
코드 리뷰는 단순히 틀린 부분을 찾는 작업이 아니라
변경 내용을 더 안전하고 이해하기 쉽게 만드는 과정이다.
좋은 리뷰는
실수를 줄이고,
코드 품질을 높이고,
협업 흐름을 정리하는 데 도움이 된다.
리뷰 기준이 없으면
무엇을 봐야 하는지 애매해질 수 있다.
예를 들어 아래 같은 문제가 생길 수 있다.
- 겉보기만 보고 merge 함
- 기능은 되지만 구조가 이상한 부분을 놓침
- 문서 수정인데 내용 확인 없이 넘김
- 리뷰 의견이 너무 감정적이거나 모호함
- 중요한 버그를 merge 후에 발견함
그래서 리뷰할 때 볼 기준을 정해두는 것이 좋다.
리뷰는
무엇이 문제인지 명확하게 보고, 수정 방향이 보이게 말하는 것이 좋다.
보통 아래를 중심으로 확인한다.
- 기능이 의도대로 동작하는지
- 코드가 이해 가능한지
- 불필요한 변경이 없는지
- 문서나 이름이 적절한지
- 위험한 부분이 없는지
이 PR 이나 commit 이
무엇을 하려는 작업인지 먼저 본다.
관련 없는 파일까지 같이 수정되었는지 확인한다.
수정 내용이 실제 목적에 맞는지 본다.
변수명, 함수명, 구조가 이해 가능한지 본다.
버그 가능성, 예외 상황, 누락된 처리 여부를 본다.
문서 수정이면 오타, 설명 누락, 흐름을 확인한다.
리뷰 의견은
짧더라도 무엇이 문제인지 분명하게 쓰는 것이 좋다.
- 이 부분은 null 체크가 없어서 오류가 날 수 있습니다.
- 함수 이름이 역할을 바로 보여주지 않아서 조금 더 명확하면 좋겠습니다.
- 이 변경은 현재 PR 목적과 직접 관련이 없어 보여서 분리하는 편이 좋겠습니다.
- 별로임
- 이상함
- 다시 하세요
- 그냥 수정
작성자를 공격하는 식으로 말하지 않는 것이 좋다.
좋은 예:
- 이 로직은 예외 처리 누락 가능성이 있습니다.
나쁜 예:
- 이건 왜 이렇게 짰나요?
무엇이 문제인지와
왜 문제인지 같이 적는 것이 좋다.
오타, 스타일, 구조 문제, 버그 위험은
같은 무게로 다루지 않는 것이 좋다.
구체적으로 어느 부분이 문제인지 말하는 것이 좋다.
필수는 아니지만
구조가 깔끔하거나 설명이 잘 된 부분은 표시해도 좋다.
리뷰할 때는 아래 순서로 보는 것이 편하다.
- 동작이 깨지지 않는지
- 버그 가능성이 있는지
- 구조가 너무 복잡하지 않은지
- 이름과 문서가 이해 가능한지
- 스타일 문제
아래 정도면 merge 가능으로 볼 수 있다.
- 작업 목적이 명확함
- 치명적인 버그가 없음
- 충돌이나 깨진 부분이 없음
- 관련 없는 변경이 거의 없음
- 필요한 설명이 있음
- PR 목적도 안 보고 승인
- 코드 실행 가능 여부 확인 안 함
- 감정적으로 리뷰
- 모호한 코멘트만 남김
- 큰 문제를 놓치고 스타일만 지적
- 변경 목적 먼저 확인
- 버그 가능성 우선 확인
- 구체적으로 코멘트 작성
- 관련 없는 변경 여부 확인
- merge 가능 기준을 보고 판단
좋은 코드 리뷰 규칙은
변경 내용이 안전하고 이해 가능한지 기준 있게 확인하고, 수정 방향이 보이도록 명확하게 의견을 남기는 것이다.