PR 리뷰의 한 가지 — 무엇을 안 보고 무엇을 보나
리뷰 시간은 유한하다. 무엇을 먼저 볼지 정하지 않으면 전부 흘린다.
리뷰에서 낭비하던 것
- 네이밍 취향 지적. 통과되든 안 되든 코드베이스에 별 영향 없음.
- 포맷 교정. linter 가 할 일을 사람이 함.
- 줄 수 세기. 300줄 넘는다고 무조건 쪼개라는 말은 맥락이 없다.
- “이렇게 짜도 돼요?” 류 질문형 코멘트. 의도가 불분명하면 상대도 어떻게 반응해야 할지 모른다.
이걸 열심히 하는 동안 진짜 문제를 놓쳤다.
지금 보는 순서
1. 변경 범위가 PR 제목과 맞는가. 인증 수정인데 결제 코드가 들어 있으면 일단 멈춘다. 범위가 섞이면 롤백 단위도 섞인다.
2. 에러 경로. 정상 흐름은 작성자가 이미 검증했다. 나는 실패 케이스만 집중해서 읽는다. 에러를 무시하거나, 잘못된 레이어에서 삼키거나, 로그 없이 넘기는 지점.
3. 외부 경계. DB, 외부 API, 큐 — 이 셋과 맞닿는 코드. 재시도, 타임아웃, 멱등성. 여기서 빠진 게 있으면 새벽에 깨어난다.
4. 테스트가 실패 케이스를 다루는가. 성공 경로 테스트만 있으면 코멘트 하나 남긴다: “이 입력이 들어오면 어떻게 됩니까.”
5. 배포 순서 의존성. DB 마이그레이션이 앱보다 먼저인가 나중인가. 이게 틀리면 리뷰가 아무리 좋아도 장애가 난다.
네이밍은? 정말 심각하게 오해를 부를 때만 코멘트. 그 외에는 Approve 찍고 닫는다.
다음 한 가지
다음 PR 리뷰 전에 위 5개를 체크리스트로 붙여두고, 한 달 뒤 실제로 쓰고 있는지 확인한다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.