[Github] ⚡️더 자주 Merge 되는 PR 만들기 - 빠른 협업하기(feat. 라인, 배민, 뱅크샐러드)

 

 

 

자주 Merge되는 PR을 만들 위한 방법

 

  Github을 통해 개발팀은 협업을 하게 되는데 코드 리뷰를 받고, approve하는 과정을 진행하게 됩니다. PR에서 Merge되는 과정을 짧고 빠르게 만들기 위한 방법을 알아보며 살아있고 빠르게 업데이트되는 서비스를 만들 수 있도록 해봅시다.

 

 

 

  요즘 많은 개발팀이 PR(Pull Request)을 통해 Github에서 협업하는 것을 볼 수 잇는 있습니다. 하지만 우리는 매번 (1)PR을 보내고, (2)리뷰어가 리뷰를 진행하고, (3)Approve(승인)를 하기 전까지 항상 기다리기 마련입니다. Github에서 PR을 관리하는 다양한 방법이 있지만 오늘은 작은 PR이라는 주제로 리뷰어의 코드 리뷰 부담을 줄이고, PR comment를 잘 작성하여 한눈에 어떤 내용인지 알아 볼 수 있도록 만들어 보겠습니다.

 

  먼저, 코드 리뷰는 모든 조직이 동일하지 않으며 다양한 사례들이 존재합니다. 특히 팀의 규모, 업무 진행 방식, 회사의 특성에 따라 다양한 방식으로 진행되기 때문에, 코드 리뷰를 통해 그 팀의 개발 문화를 살펴볼 수도 있습니다.

 

 

 

자주 Merge되는 PR이 되려면 어떻게 해야할까요?

  다른 동료들이 자주 시시각각 날라 오는 PR에 대해서 모니터링하고 있다면 조금 더 빠를 수 있을까요? 하지만, 현실적으로 각자의 업무를 진행중에는 매번 확인하는 것이 어려울 수 있는 것이 현실입니다. 따라서 업무 사이에, 또는 갑자기 생긴 짬에 확인하는 경우도 많습니다.

 

  개발을 하다보면 하나의 기능을 개발중에 주변에 다른 것들을 건들기도 하여 수정/추가된 코드 라인의 수가 많게는 10,000 이상되는 경우도 있습니다. 하지만 우리는 협업을 위해서 더 이상 이러한 만행을 저질러서는 안됩니다. 리뷰를 진행하는 리뷰어의 입장에서 10,000줄 이상의 코드 리뷰는 한번 망설일 수 있게 하는 태도를 가질 수 있게 합니다. 이럴수록 내가 날린 PR의 Merge는 나날이 길어질 수 있게 되는 것이죠.

 

 

어떤 작은 규칙을 만들까?

  여러 조직의 개발팀에서는 PR 규칙이라는 것을 만들어 더 원활한 리뷰를 할 수 있도록 만듦니다. 오픈된 개발팀들의 작은 규칙에 대해서 알아봅시다.

 

라인

효과적인 코드 리뷰를 위해서 - LINE ENGINEERING

효과적인 코드 리뷰를 위해서 - LINE ENGINEERING

• 변화를 작게 유지하자(300줄 미만)
• 리뷰는 자주 짧은 세션으로 진행하자
• 리뷰를 위해 최대한 빨리 PR을 보내자(뭉통이로 PR하지 않고 짧게 자주)
• 다수의 팀들에서는 300줄 미만이라는 작은 규칙을 지키며 PR을 만들고 PR에 대한 시간을 짧게 가져가는 것으로 합니다.

 

배달의 민족

공통시스템개발팀 코드 리뷰 문화 개선 이야기 | 우아한형제들 기술블로그

공통시스템개발팀 코드 리뷰 문화 개선 이야기 | 우아한형제들 기술블로그

• PR의 코드는 삭제된 코드를 포함하여 최대 300줄 미만으로 유지
• 하나의 티켓에서 여러 개의 PR을 만들어도 됨(더 작게 쪼개라)
• 리팩토링은 기능 및 버그 수정과 분리하여 진행

 

뱅크샐러드

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

• Pull Request, Commit 단위는 최소의 기능 단위로 세분화(200~300줄 이내)
• 테스트 코드는 Mock json이 라인 수의 대부분을 차지하므로 제한을 두지 않음

 

 

 

 

 

PR Comment 잘 남기기

  PR의 단위 만큼 역시 중요한 것은 PR Comment를 어떻게 남기나 인데요. PR Comment에 따라 리뷰어는 리뷰를 하는 시간을 더 줄일 수 있고 내가 무슨 작업을 위해서 PR을 남겼는지 알 수 있게 해줍니다. 디테일하고 읽기 쉽게 작성하는 것이 중요하지만, 우리는 매번 많은 시간을 사용하는데 부담을 느낄 수 있기 때문에 가장 기본적으로 남겨놓아야하는 것들에 대해서 알아봅니다. 그 중 가장 중요한 것은 ‘왜’입니다.

1. PR의 제목에서 왜 이 작업을 했는가를 간단 명료하게 표현합니다.
2. Comment에는 작업에 대한 자세한 왜(이유), 작업 내용, 미리보기(첨부)와 같은 내용을 작성합니다. 미리보기에는 한눈에 알 수 있는 어떤 것이든(이미지, 비디오, 참조 내용) 넣을 수 있습니다.

PR Comment

 

  간단한 Comment 작성을 통해 PR을 날리는 과정도 최소화 한다면, 더 자주 빠르게 PR을 할 수 있게 됩니다. 또한 간단 명료하게 작성해줌으로서 리뷰어의 입장에서도 내가 어떤 작업을 했고, 왜 PR을 했는지 알 수 있습니다. 가장 중요한 것은 왜입니다.

 

 

 

 

 

  지금까지 다양한 더 자주 Merge 될 수 있는 PR을 만드는 방법에 대해서 알아보았습니다. 작게 쪼개고 그에 대한 근거를 간단 명료하게 작성한다. 간단한 것 같으면서도 어렵게 느껴질 수 있겠지만 Github로 협업하는데 가장 좋은 방법이며, 프로젝트를 빠르게 만들어 나갈 수 있는 방법이라는 생각이 듭니다. 저 역시 작은 개발 조직에서 큰 조직으로 이동하게 되면서 이 고민을 더 많이 하게 되었는데 이 글을 작성하면서 좀 더 정리가 되었다고 생각합니다.