작은 PR 규칙으로 코드 리뷰 효율 높이기

작은 PR 규칙 도입 배경

처음 술담화 개발팀에는 PR(Pull Request)에 대한 규칙이 없었다. 그래서 큰 프로젝트의 경우 하나의 PR로 올리는 경우도 있었다. 이 경우 방대한 코드 개발 양으로 코드 리뷰를 하기가 힘들었다. 코드 리뷰가 어려워지면 코드 퀄리티가 떨어지고, 버그가 발생할 가능성이 높아지는 등 단점이 많다. 이를 해결하기 위해 "작은 PR 규칙" 을 적용해보자는 목소리가 팀 내에 있었고, 실제로 도입해봤더니 많은 장점이 있었다.

 

작은 PR 규칙의 효과는 굉장했다!

작은 PR 규칙을 사용하는 방법

(git flow 기반으로 설명하겠다.)

1. develop에서 feature 브랜치를 만든다.

2. feature 브랜치에서 1번째 브랜치를 만들어 개발 완료 후 feature 브랜치에 첫번째 PR을 날린다.

3. 코드 리뷰에 시간이 걸린다면 1번째 브랜치에서 2번 브랜치를 만들어 이어서 개발한다.

4. 코드 리뷰를 반영하여 2번째 브랜치에 merge 하여 개발을 이어간다.

5. 이를 반복하여 feature/project에 모든 개발건이 완료되면 develop으로 PR 한다.

이때 코드리뷰는 모두 받았기 때문에 바로 merge 하면 된다.

 

작은 PR 규칙의 장점

1. PR 하는 코드 수를 줄여 코드 리뷰를 더 잘 받을 수 있다.

-> 코드의 퀄리티가 좋아진다 (중복 코드 삭제, 버그/실수 방지, 더 좋은 로직을 제안받을 수 있다, 코드 리뷰어의 부담을 줄인다, 기획에 맞는 코드가 제대로 개발 되었는지 확인받기 쉬워진다 등 장점이 무궁무진하다)

2. 코드 리뷰를 받는 중에 개발을 이어갈 수 있다.

3. 컨플릭트를 쉽게 해결할 수 있다. (동시에 여러명이 작업할 경우)

 

작은 PR 규칙의 단점

1. PR을 여러번 나눠서 해야한다.

 

개인적으로 장점이 단점을 충분히 커버하고도 남았다! 작은 PR 규칙 강력 추천

 

PR을 어떤 단위로 나눠서 해야할까?

이는 정답이 정해져있지 않다. 나같은 경우는 기능별로 나눠서 혹은 코드 리뷰하기에 적당한 라인이 되면 끊어서 PR 했다. 어떤 방법이든 코드 리뷰를 잘 받기 위함이라는 목적에 맞게 너무 많은 라인 수로 PR 하는 것만 피하면 좋을 것 같다.