architecture · high priority
Code Review & Refactoring
PR 리뷰 원칙, Nit/Suggestion/Blocking, Strangler Fig, Boy Scout Rule
학습 개요
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“코드 리뷰는 논문 피어 리뷰, 리팩토링은 집 리모델링이다. 리뷰는 "이 논문이 틀렸나요?" 가 아니라 "이 논문이 더 명확하고 설득력 있을 수 있을까요?"의 관점으로 한다. 리모델링은 집에 사람이 살면서 조금씩 개선한다.”
좋은 코드 리뷰는 버그를 잡는 것보다 팀 전체의 지식 수준을 높이는 데 더 큰 가치가 있다. 리팩토링은 새 기능을 추가하는 것이 아니라, 기존 코드를 더 이해하기 쉽게 만드는 작업이다.
핵심 개념
Nit (Nitpick)
선택적 개선 — 머지를 막지 않음. "Nit: 변수명을 더 명확하게 하면 좋을 것 같아요"
Nit: `data` 보다 `userList`가 의도를 더 잘 표현하는 것 같습니다.Suggestion
권장 사항 — 구현하면 좋지만 강제 아님. 더 나은 접근법 제안.
Suggestion: 이 패턴은 useReducer가 더 적합할 것 같습니다. 어떻게 생각하세요?Blocking
반드시 수정해야 머지 가능. 버그, 보안 취약점, 성능 문제.
Blocking: 이 부분은 XSS 취약점입니다. 사용자 입력을 반드시 이스케이프해야 합니다.코드가 아닌 코드를 리뷰하라
"왜 이렇게 했나요?" 보다 "이 방식을 선택한 트레이드오프가 있나요?"처럼 질문하라. 개인 비판이 아닌 코드 개선에 집중하고, 긍정적인 부분도 적극 언급한다.
PR 작성자를 위한 체크리스트
PR 크기 최소화
400줄 이하, 단일 목적 PR. 리뷰어가 맥락을 잃지 않도록
자기 리뷰
제출 전 본인이 먼저 리뷰. "이 코드를 처음 보는 사람이 이해할 수 있는가?"
컨텍스트 제공
PR 설명에 "왜", "어떻게", "테스트 방법" 포함
테스트 포함
변경 사항에 대한 테스트 코드 함께 제출
실무 적용
어떤 상황에서 사용하는가
200줄 이상의 거대한 컴포넌트를 분리하고 PR 리뷰를 통해 코드 품질을 높여야 할 때
어떻게 적용하는가
1) 관심사 분리 — UI/로직/데이터 레이어 구분, 2) Extract Custom Hook으로 로직 추출, 3) 한 번에 전체 리팩토링 대신 Strangler Fig으로 점진적 교체, 4) PR은 작은 단위로 나눠 리뷰 부담 최소화
흔한 실수와 안티패턴
- 리팩토링과 기능 추가를 동시에 하는 PR (리뷰하기 어렵고 버그 추적 불가)
- 테스트 없이 대규모 리팩토링 (회귀 버그 발생)
- 코드 리뷰에서 Blocking과 Nit을 구분 안 해 리뷰이가 우선순위를 모름
- 기술 부채를 무조건 나쁘게 보고 출시 전 무리한 리팩토링 시도
면접 질문
답변 방향 힌트
버그 발견 vs 지식 공유, 피드백 방식
반드시 언급할 키워드
- 코드가 아닌 코드 리뷰
- Nit/Suggestion/Blocking 구분
- 질문 형태로 피드백
- 긍정적 부분도 언급
- PR 크기의 중요성
예상 꼬리 질문
- 기술 부채를 어떻게 관리하나요?
- Strangler Fig 패턴을 적용해본 경험이 있나요?