[GitHub 100일 챌린지] Day 96 - 코드 리뷰와 리팩토링

100일 챌린지 Day 96 - 최종 프로젝트를 배포하기 전에 스스로 리뷰하고, 위험한 부분을 작게 리팩토링합니다.

배울 내용

1. Pull Request 기준으로 셀프 리뷰하기
2. 리팩토링할 부분과 그대로 둘 부분 구분하기
3. 리뷰 코멘트와 커밋으로 개선 과정을 남기기

---

1. 리뷰는 “틀린 코드 찾기”가 아니다

코드 리뷰는 단순히 실수를 찾는 시간이 아닙니다. 프로젝트가 나중에도 이해되고 수정될 수 있는지 확인하는 과정입니다.

최종 프로젝트에서는 특히 아래를 봅니다.

리뷰 기준
- 기능이 Issue의 완료 조건을 만족하는가?
- 불필요한 파일이나 디버깅 코드가 포함되지 않았는가?
- README에 적은 사용법과 실제 동작이 일치하는가?
- 테스트나 수동 검증 결과가 PR에 남아 있는가?
- 변수명, 파일명, 컴포넌트명이 역할을 설명하는가?

---

2. PR diff를 기준으로 셀프 리뷰하기

먼저 main과 현재 브랜치의 차이를 봅니다.

git diff --stat main...HEAD
git diff main...HEAD

GitHub에서 PR을 열었다면 Files changed 탭에서 직접 코멘트를 달아보세요. 혼자 하는 프로젝트라도 코멘트를 남기면 “왜 이렇게 고쳤는지”가 기록됩니다.

셀프 리뷰 질문:

• 이 변경은 하나의 목적에 집중하는가?
• 더 작은 함수로 나누면 읽기 쉬워지는가?
• 중복된 조건문이나 상수가 반복되는가?
• 에러/빈 상태/로딩 상태가 빠져 있지 않은가?
• 지금 리팩토링하면 위험한 부분은 없는가?

---

3. 리팩토링 범위 정하기

리팩토링은 코드를 예쁘게 만드는 일이 아니라 동작은 유지하면서 구조를 개선하는 일입니다. 기능 추가와 리팩토링을 섞으면 문제가 생겼을 때 원인을 찾기 어렵습니다.

좋은 리팩토링 예:

- 중복된 프로젝트 카드 렌더링을 `ProjectCard` 컴포넌트로 분리
- 필터 로직을 `filterProjects()` 함수로 분리
- 하드코딩된 URL을 데이터 파일로 이동
- 긴 조건문을 명확한 변수명으로 나누기

리팩토링 전후에는 같은 테스트와 수동 체크리스트를 다시 실행합니다.

npm test
npm run build

빌드 명령이 없다면 최소한 페이지를 직접 열어 핵심 흐름을 확인하세요.

---

4. 리뷰 반영 커밋 만들기

리뷰 후 수정은 별도 커밋으로 남기는 것이 좋습니다.

git add src/components/ProjectCard.js
git commit -m "Refactor project card rendering"

git add README.md
git commit -m "Document project data structure"

PR에는 아래처럼 남깁니다.

## 셀프 리뷰 반영
- 프로젝트 카드 중복 렌더링을 컴포넌트로 분리
- 필터 로직을 순수 함수로 이동
- README의 프로젝트 데이터 설명 보강

## 재검증
- [ ] 프로젝트 목록 표시
- [ ] 필터 동작
- [ ] 빈 결과 상태
- [ ] 모바일 화면

---

5. 머지 전 최종 확인

머지 전에는 로컬과 원격 상태를 확인합니다.

git status
git log --oneline --max-count=5
git push

작업 브랜치가 최신 main과 너무 멀어졌다면 rebase나 merge로 최신 상태를 반영한 뒤 테스트를 다시 실행합니다.

---

정리

완료 체크:

• PR diff를 기준으로 셀프 리뷰를 했다
• 리팩토링할 범위를 작게 정했다
• 리팩토링 후 테스트 또는 수동 검증을 다시 실행했다
• 리뷰 반영 내용을 PR에 기록했다

핵심 요약:

리뷰는 코드의 의도와 유지보수성을 확인하는 과정이며, 리팩토링은 작고 검증 가능한 단위로 진행한다.

다음: Day 97 - 문서화 완성 →

---

← Day 95 | 전체 커리큘럼 | Day 97 →