PR(Pull Request) 이란?
PR(Pull Request, 이하 PR) 이란 Github에서 코드 리뷰 를 받고, 변경 요청을 반영하고 다른 브랜치로 병합 하기 위한 수단이다.
팀 프로젝트의 PR 흐름
보편적으로 팀 프로젝트에서는 아래와 같은 일련의 과정을 거친다.
- 프로덕트를 만들기 위해 열심히
코드를 작성한다. - 팀 내의 브랜치 전략에 따라,
PR을 생성한다. - PR을 통해 코드 리뷰를 받고
변경 요청을 반영한다. - 팀 그라운드 룰에 따라,
팀원 중 일부가 Approve하면 특정 브랜치로 merge한다.
대단히 체계적이고 이상적인 흐름이다.
PR 전략의 문제점
위에서 언급한 바와 같이 PR이 이루어진다면 너무나도 아름다운 팀 프로젝트가 될 것이다.
하지만 현실은 그렇지 않다.
프로덕션 출시일은 다가오고, PR 코드리뷰에 피로감을 느낀 당신은 다음과 상황을 겪곤 한다.
A 개발자 : B 개발자님! 시간이 없어서
바로 merge하겠습니다.
B 개발자 : (버그 있으면 QA팀에서 잡아주겠지?) 네, 바로 merge 하세요.
C 개발자 : 내 코드 작성할 시간도 없는데코드 리뷰까지 해야 돼?
아이러니하게도 우리가 정한 체계적이고 아름답다고 생각했던 규칙에 얽매이면서 도리어 피로감을 느끼고 있다.
이러한 상황은 코드리뷰뿐만 아니라 프로젝트에 대한 애정도를 점차 떨어뜨릴 수 있다고 생각한다.
위 사진은 커디(Kerdy)의 초기 PR목록이다.
보이는 바와 같이, 프로젝트 초기에는 시간적으로 여유로운 경우가 많기 때문에 팀원과 코드 리뷰가 원활히 이루어지고, 팀원들이 Approve 한 이후에 Merge가 이루어졌다.
하지만 시간이 지나면서, 프로덕션 출시일이 다가오고 코드 리뷰가 점차 줄어들고, 어쩔 수 없이 Approve 없이 Merge가 이루어지는 모습을 볼 수 있다.
코드 리뷰, QA가 이루어지지 않다보니, 프로덕션에는 개발자가 캐치하지 못한 버그 부터, 디자인 규격 MISS 가 발생하곤 했다.
이에 따라, 커디 팀은 조금 더 유연하고 아름답게 다룰 수 있는 방법을 구상해보았다.
PR을 다루는 3가지 전략
기존에는 PR 전략을 1가지로 정해두고, 반드시 이를 지켜야 했기 때문에 크게 다음과 같은 문제가 있다.
코드 리뷰에 대한피로감모든 PR에 대한 팀원들의Approve를 기다리면서 발생하는개발 지연Ready to Ship이 약해짐 (출시 지연)
Ship 은 선박 또는 배를 의미한다.
프로덕션을 출시(Release) 하는 것을 선박에 화물을 실어 내보내는 것에서 비유한 표현이다.
우리는 여기서 생각을 조금 전환할 필요가 있었다.
과연 모든 PR에 대한 코드 리뷰가 필요할까?
PR을 조금 더 유동적으로 다룰 수는 없을까?
이러한 의문점을 해결하기 위해 커디 팀은 마틴 파울러(MartinFowler)가 제안한 Ship Show Ask 전략을 따라보기로 했다.
요약하자면, 아래 3가지 방식 중에 개발자 본인의 판단으로 상황에 따라 PR 전략을 유동적으로 선택 하는 방식이다.
Ship 🚢
Ship 은 일련의 코드 리뷰나 approve 없이 바로 PR을 merge 하는 방식이다.
예를 들면, 아래와 같은 상황이 될 수 있다.
- Show 에서 (또는 별도로) 받은
간단한 코드 리뷰를 반영했다. - 기존 문서를 수정했다.
사소한 버그를 수정했다.
위의 예시만 봐도 어떤 상황에서 Ship 방식을 적용하는지 이해할 수 있을 것이다.
바로 Merge 해도 문제가 발생하지 않는 상황을 본인이 판단하는 방식이다.
이로 인해, 사소한 상황에서도 PR이 Approve 될때까지 기다릴 필요가 없기 때문에, Ready to Ship 을 높이는 데에 큰 도움이 된다.
Show 💬
Show 또한 Ship 방식처럼 PR을 바로 merge 하는 방식이다.
다만, 조금의 차이가 있다.
전략의 이름이 나타내는 것처럼, 일단 Merge 는 이루어지지만, 자신이 작성한 코드를 팀원들에게 보여준다. (Show)
다시 말해, Merge 는 하지만 자신의 코드에 대해 다른 팀원들의 의견을 듣고 싶은 상황 을 의미한다.
의견과 대화를 나눌 수 있는 여지 를 만들 수 있다.
다음과 같은 상황에서 유용하게 사용될 수 있다.
- 코드 개선을 위해 팀원의 의견을 듣고 싶다.
- 팀원의 의견을 반영할 때에는
Ship으로 이어진다.
- 팀원의 의견을 반영할 때에는
- 새로운 사용한 패턴과 접근법을 공유하고 싶다.
- 리팩터링한 내용을 공유하고 싶다.
- 버그를 수정한 내용을 공유하고 싶다.
정리하자면, 팀원과의 커뮤니케이션 을 필요로 하는 전략이다.
Ask 🤔
Ask 은 복잡할 것 없이 기존에 우리가 따르던 방식 그 자체이다.
PR을 보내고 코드리뷰를 거친 후에 approve가 되면 merge하는 방식이다.
다음과 같은 상황에 적절하다.
- 큰 기능을 구현했을 때 자신의
코드/기능에 대한 확신이 없다. - 코드가
정상 동작하는지 확인받고 싶다. - 새로운 접근법이 어떻게 느낄지 궁금하다.
기능이 크고 버그가 생길 수 있어 두려운 경우, 동료 개발자의 의견과 검토를 받는 것이 중요하기 때문에 Ask 방식을 권장한다.
새로운 방식에 대한 사견
Ship Show Ask 가 반드시 정답이라는 것은 아니다.
다만, 기존 PR 전략에 문제가 있다고 느낀다면 팀 프로젝트에 적용해보는 것도 나쁘지는 않다고 생각한다.
또한, 위에서, 각 전략에 대해 적절하다고 제시한 상황 또한 정답이 아니므로, 경우에 따라 본인의 판단이 매우 중요한 전략이다.
마지막으로, 이 방식은 팀원과의 신뢰도가 높은 경우에 적용하는 것이 좋다고 생각한다.
Ship 방식의 경우 팀원의 코드 리뷰없이 바로 merge 하기 때문에, 팀원간 신뢰가 낮은 상태에서 진행 된다면 오히려 팀 내의 불화 로 이어질 수도 있다고 느꼈다.
커디 에서는 현재 글에서 소개한 PR 전략을 따르고 있다.
안드로이드 개발 팀의 신뢰도는 충분하고, 이제는 큰 기능보다는 자잘한 버그 수정, 기존 기능 개선, 패키지 구조 개선 위주로 진행하고 있기 때문이다.
만약 feature 가 추가되어야 한다면, 그 때에는 Ask 방식을 따르면 된다.
Reference
