오픈소스 컨트리뷰션 PR
- 아래 PR은 내가 오픈소스 컨트리뷰션에서 에러가 생기는 부분에 대해 파악하고 해당 이슈에 대한 PR 을 올린 것이다.
- 비교적 단순한 이슈 해결에 대한 PR 인데, PR의 크기가 큰 것을 볼 수 있다.
협업 시 PR의 중요성
- 기능을 합치는 단위
- 다른 개발자들 / 동료들이 내가 작성한 코드의 완성본을 접하는 순간
- 리뷰를 받을 수 있는 절호의 기회
PR을 작성할 시 주의할 점
내 PR을 보는 동료는 본인이 작성한 코드가 아니고 무슨 내용인지 명확히 모르기 때문에, 시간을 많이 소비하게 될 수 있다.
리뷰어와 리뷰이 모두가 힘들어진다
- 왜냐하면 변경사항의 규모가 크기 때문에(이 PR은 추가된 라인이 800여 줄에 이른다. 상당히 많은 양 )
- 리뷰이의 입장에서는 아무리 코드를 완전하게 작성하려고 해도, 한번에 많은 양의 코드를 작성하게 되면 자신이 테스트 해본 부분 이상의 예상치 못한 오류가 무더기로 발견되는 경험을 할 가능성이 높아진다.
- 그렇게 되면 수정하고 반영해야할 사항들이 많아지고, 그만큼 PR은 계속해서 커져만 가게 된다.
내 PR은 왜 이렇게 커졌을까?
-
PR에 이미지도 첨부하고 기존에 어떠한 문제가 있었는지,상세하게 기술하려는 의도 (GREEDY 함) 가 덕지덕지 들어가다 보니, 너무 비대한 PR이 되고 만 것이다.
-
의도는 나쁘지 않았지만, 협업하는 동료가 자신이 한 기능에 대한 내용 서술을 이와 같이 장황하게 작성한다면, 어떨까?
-
자신이 작성한 코드가 아니니, PR에 대한 의미를 명확히 이해하기 위해 오랜 시간을 들여 PR에 적힌 내용을 읽을 것이다 => 그러다보면 집중력도 저하되고, 제대로 된 PR 리뷰가 어려워질 것이다.
-
동료가 집중력을 잃게 되면 어떤 일이 생길까?
- 더 많은 에러와 이슈를 잡아낼 수 있던 효율이 감소
- 소요하는 시간이 기하급수적으로 증가 -> 코드 리뷰의 우선순위가 밀리게 된다.
긴 PR의 Side Effect : 기능을 배포하기까지 오랜 시간이 걸리게 된다.
그럼 PR을 어떻게 작성해야 할까?
리뷰어를 배려하라
- 코드 컨벤션을 잘 지켜라.
- 깔끔하고 잘 동작하는 코드를 만들기 위해서 정해 놓은 규칙인데 이를 무시하거나 인지하지 못한 채로 커밋을 작성하게 되면 이에 대한 리뷰가 먼저 들어올 것이다.
- 이는 불필요한 코멘트이고 시간 낭비가 될 수 있으니 지양하는 것이 좋다.
잘 재고, 잘 쪼개라.
- 자신이 해야할 업무 분량에 대해서 명확하게 계산이 되어야 한다.
- 그래야만 큰 PR을 만들지 않고 일정 단위로 잘 분리된 여러 개의 PR을 빠르고 정확하게 리뷰받고 병합할 수 있다.
- API 개발이라면 그 기능과 동작에 따라 분리하여 작업할 수도 있을 것이다. 이 부분은 나에게도 연습이 더 필요할 것 같다.
이슈 베이스 브랜치를 활용하라.
- 새로운 베이스 브랜치와 세부 작업에 대한 브랜치를 두고 작업하게 되면, 작은 크기의 PR을 만드는 데 도움이 될 것이다.
Reference
- PR을 작성할 시 주의할 점에 대해 다른 분들의 생각을 참고한 블로그 !
PR에 대한 생각이 담긴 블로그
좋은 PR에 대한 생각이 담긴 블로그
