1. 정적 분석 및 테스트의 완벽한 통과
모든 PR의 기본은 정적 분석 도구와 테스트를 로컬 환경에서 통과시키는 것입니다. JavaScript 프로젝트의 경우 Prettier와 같은 자동 포맷터, ESLint와 같은 린터, 그리고 TypeScript의 타입 체크가 이에 해당합니다. 이러한 도구들은 Husky와 같은 pre-commit 훅을 통해 자동화하여 실수를 방지할 수 있습니다. 또한, 전체 테스트 케이스가 성공적으로 실행되는지 확인해야 하며, IDE에서 watch 모드를 활용하여 실시간으로 피드백을 받는 습관이 중요합니다.
2. 테스트 코드의 추가와 확장
Ruby, JavaScript, Python 등 주요 언어를 사용하여 개발할 때, 새로운 기능을 추가하거나 버그를 수정하면서 테스트 코드를 보강하지 않는 것은 미완성된 작업과 같습니다. 새로운 화면을 개발했다면 통합 테스트를, 복잡한 로직의 함수를 수정했다면 유닛 테스트를 작성해야 합니다. 작업 성격에 맞는 적절한 테스트를 추가함으로써 코드의 안정성을 확보하고 향후 발생할 수 있는 회귀 버그를 예방할 수 있습니다.
3. 코드의 가독성과 명명 규칙
초기 구현 시 선택한 변수나 함수 이름은 최선이 아닐 가능성이 높으므로, PR을 열기 전 반드시 재검토해야 합니다. 함수 이름이 그 역할을 명확히 설명하는지, 컴포넌트 이름이 도메인 개념과 일치하는지 확인하십시오. 명명 규칙을 개선하는 것은 코드의 가독성을 높이는 가장 직접적인 방법입니다. 다른 개발자가 코드를 보았을 때 의도를 즉시 파악할 수 있도록 최선의 이름을 선택하려는 노력이 필요합니다.
4. 관련성 있는 변경 사항 유지 및 Git 리베이스
PR은 특정 목적을 위한 변경 사항만을 포함해야 합니다. 개발 과정에서 탐색을 위해 수정했던 무관한 파일이나 불필요한 리팩토링은 제외해야 합니다. ‘보이스카우트 규칙’도 중요하지만, 핵심 변경 사항이 흐려지지 않도록 주의해야 합니다. 또한, Git 리베이스(Rebase)를 통해 의미 없는 커밋 메시지를 정리하고 히스토리를 깔끔하게 스쿼시(Squash)하여 리뷰어가 변경 이력을 쉽게 파악할 수 있도록 관리해야 합니다.
5. 문서화와 엣지 케이스 고려
소프트웨어 엔지니어는 종종 소통에 소홀하기 쉽습니다. README를 업데이트하고, 필요한 경우 코드에 주석을 남겨 의도를 명확히 전달해야 합니다. 주석의 단점보다는 소통 부족으로 인한 비용이 더 크다는 점을 명심하십시오. 또한, 폼 검증 시 빈 값 입력이나 예외 상황 등 명백한 엣지 케이스를 사전에 고려했는지 확인하고, 기술적인 트레이드오프에 대해 정직하게 기록하는 자세가 필요합니다.
6. PR 품질과 셀프 리뷰의 중요성
PR은 미래의 자신과 동료를 위한 기록물입니다. 작업의 이유(Why), 내용(What), 방법(How)을 상세히 적고 티켓 링크와 스크린샷을 첨부하십시오. 특히 PR을 생성한 후 직접 코드를 훑어보며 셀프 리뷰 주석을 남기는 과정이 매우 유익합니다. 특정 로직의 위험성이나 리팩토링이 필요한 지점을 미리 언급함으로써 리뷰어와 건설적인 토론을 시작할 수 있으며, 이는 팀 전체의 코드 품질 향상으로 이어집니다.