이 글은 GitHub 공식 문서의 내용을 번역하면서 개인적인 경험과 인사이트를 추가한 것입니다.
Rule 1: Making your changes easy to review
PR에서 명확한 컨텍스트를 제공하면 리뷰어들이 빠르게 무엇이 변경되었는지, 그리고 왜 중요한지 파악할 수 있습니다. 이는 리뷰 과정을 더 빠르고 매끄럽게 만들어 주고, 오고가는 대화를 줄이며, 팀이 더 나은 피드백을 제공하고 확신에 찬 결정을 내릴 수 있도록 도와줍니다.
GitHub 문서에서 말하는 핵심
GitHub 문서에서 제시하는 "less back-and-forth"의 목표:
🎯 효율적인 PR 작성법
- 작은 PR: 단일 목적에 집중
- 명확한 컨텍스트: 제목, 설명, 목적 명시
- 자체 리뷰: 제출 전 스스로 검토
- 보안 검토: 사전 보안 이슈 해결
실제 적용 예시
단계적 리뷰
- 1단계: 도메인 전문가 리뷰 (비즈니스 로직)
- 복잡한 도메인 로직은 사전 논의
- 2단계: 일반 개발자 리뷰 (코드 품질)
PR에서의 활용
## PR 설명 예시
### 변경 사항
- UserFeatureFlagRelation 엔티티에 새로운 필드 추가
### 도메인 컨텍스트
- 사용자별 기능 플래그는 1:N 관계가 아닌 별도 테이블로 관리
- 성능상 조인 대신 별도 조회 사용
- 참고: [도메인 설계 문서 링크]
### 리뷰 포인트
- 도메인 로직이 올바른지 확인 부탁드립니다
- 성능 영향도 검토 부탁드립니다Rule2: Write small pull requests
리뷰어들이 PR이 무엇을 하는지 빠르게 이해할 수 있도록 명확한 제목과 설명을 작성하세요. PR 본문에는 다음을 포함하세요:
- PR의 목적
- 변경 사항 개요
- 추적 이슈나 이전 대화와 같은 추가 컨텍스트에 대한 링크
리뷰어들을 돕기 위해 필요한 피드백 유형을 공유하세요. 예를 들어, 빠른 검토가 필요한지 아니면 깊은 분석이 필요한지요? 또한 GitHub Copilot을 사용하여 PR 요약을 생성할 수도 있습니다.
실제 적용 예시
Quick look(빠른 검토)
- "코드 스타일만 확인해주세요"
- "문법 오류만 체크해주세요"
- "전체적인 구조만 봐주세요"
Deeper critique(깊은 분석)
- "아키텍처 설계가 적절한지 검토해주세요"
- "성능 영향도를 분석해주세요"
- "보안 취약점을 체크해주세요"
- "도메인 로직이 올바른지 검토해주세요"
PR에서의 활용
## 리뷰 요청 타입
- [ ] Quick look (빠른 검토)
- [x] Deeper critique (깊은 분석)
### 필요한 피드백
- 도메인 로직 검토
- 성능 영향도 분석
- 보안 취약점 체크
- 아키텍처 설계 검토Rule3: Review your own pull request first
제출하기 전에 자신의 PR을 리뷰하고, 빌드하고, 테스트하세요. 이렇게 하면 다른 사람들이 리뷰를 시작하기 전에 놓쳤을 수 있는 오류나 오타를 발견할 수 있습니다.
마무리
지식이 부족해서 파악이 안된 Rules은 담지 못했지만, PR의 핵심 목적을 다시 한번 정리해보았습니다.
왜 PR이 중요한가?
PR은 개발자 협업에서 가장 빈번하게 수행하는 작업입니다. 이 과정이 수월해야 전체적인 업무 품질과 성과가 향상됩니다. 따라서 PR 작성과 리뷰에 신경 쓰는 것은 필수적입니다.
기본이지만 실천이 어려운 이유
위의 3가지 규칙은 가장 기본적인 내용이지만, 실제로 실천하기는 쉽지 않습니다. 마치 영어 공부를 많이 해도 실제로 영어를 못하는 것처럼, 이론과 실천 사이에는 큰 간극이 있기 때문입니다.
이 글의 목적
이 글의 목적은 협업하는 개발자들이 기본적인 PR 규칙을 함양하여 더 나은 협업을 할 수 있도록 돕는 것입니다.
작은 실천이 큰 변화를 만듭니다.
PR 하나하나를 신중하게 작성하고 리뷰하는 습관이 팀 전체의 개발 문화를 바꿀 수 있습니다.
더 나은 협업을 위해 함께 노력해 나가길 바랍니다. 🚀