코드리뷰하기 좋은 PR이란 무엇일까
github 의 Pull Request 를 이용해서 코드리뷰를 하고 있다. 코드리뷰라고 하면 참 좋은데 하다보면 다양한 어려움도 있기 마련이다. PR이 너무 커서 보기 힘든 경우도 있고, 내가 얼른 리뷰받아서 배포해야하는데 리뷰가 늦어져서 답답한 경우도 있다. 좋은 PR과 코드리뷰를 하려면 무엇을 고려해야할까 고민해보다가 나름의 고민결과를 적어본다.
# 작은 PR
리뷰를 요청하는 개발자는 본인의 변경이니 코드가 눈에 잘 들어오지만, 타인이 작성한 코드를 봐야하는 리뷰어 입장에서는 큰 PR은 검토하기가 쉽지 않다. 그리고 결과적으로 큰 PR은 리뷰어들이 리뷰를 진행하는데 시간을 오래 걸리게 만든다. 이는 리뷰어 입장에서도 고통이지만 얼른 리뷰를 받아야하는 요청자 입장에서도 답답한 상황이 된다. 때문에 개발하는 기능을 최대한 분리해 작은 PR을 요청하는게 좋다. 작은 PR의 기준은 상황이나 변경 내용에 따라 다르겠지만 개인적으론 file change 7개가 넘어가면 분리해서 PR 을 올리는걸 검토한다.
# 큰 변경을 포함해야한다면
하지만 개발을 하다보면 필연적으로 file change 가 많아지는 변경을 할때가 있다. 가령 예를 들면 자바에서 패키지를 변경하는 것 등이다. 해당 패키지에 의존하고 있는 다른 패키지가 많았다면 file change 는 수십개에 이를수도 있는데 이를 작은 PR로 올리기란 쉽지 않다. 이럴땐 어쩔 수 없이 올려야하는데 이때 유의해야할 부분은 질적 변경과 양적 변경을 구분하는 것이다. 무슨 말이냐면 패키지 변경으로 인해 변경되는 양이 많다면(양적 변경) 이땐 패키지 변경 외 다른 기능 변경(질적 변경)을 PR에 포함하지 말자는 것이다. 조금 더 주의깊게 리뷰를 받아야하는 질적 변경 부분이 양적 변경에 묻혀 정상적으로 리뷰를 받지 못할 수도 있다. 리뷰를 진행하는 입장에서는 패키지 변경으로 인한 변경이 잔뜩 있는데 그 사이에서 질적 변경을 찾아내 리뷰를 한다는게 생각처럼 쉽지 않기 때문이다. 패키지 변경은 패키지 변경만 포함하여 PR을 올리고, 이 외 질적 변경 부분은 별도 작은 PR로 올리는게 리뷰를 진행하기에 수월하다.
# 지속적 푸시
PR을 생성해놓고 추가 커밋을 계속 푸시하는 경우가 있는데, 리뷰를 요청한 뒤에는 가급적 추가 푸시를 자제해야한다. 리뷰어는 PR이 올라왔을때 해당 버전에 대해서 리뷰를 하고 approve 를 한 것인데, 그 이후로 추가 커밋을 넣어버리면 리뷰어가 승인하지 않은 부분까지 포함된다. 참고로 당연하게도 리뷰 과정에서 코멘트가 달린 부분을 수정한 커밋을 얘기하는건 아니다.
이를 방지하기 위해 추가 커밋이 발생하면 자동으로 approve 가 풀리는 기능도 있는데 이 기능은 기계적으로 approve 를 풀어버리기 때문에 실제로 적용하면 불편한 점도 많다. 막판에 로그를 추가한다거나 하는 이유로 발생한 커밋에 대해서도 PR을 초기상태로 돌려버리기 때문이다. 불특정 다수와 진행하는 오픈소스 프로젝트가 아니라 사내에서 신뢰할 수 있는 같은 팀원끼리 진행하는 프로젝트라면 굳이 이런 기능까지 적용할 필요가 있는지는 고민해볼만 한 것 같다. 좋은 PR문화를 위해 서로 추가커밋을 자제해주면 굳이 쓸 필요가 없기 때문이다.
다른 사례로, 리뷰 요청자는 지속적으로 개발을 해야하기 때문에 리뷰어들이 빠르게 리뷰를 해주지 않으면 PR 생성 후 진행한 개발내용을 PR에 그대로 추가하는 경우도 있다. 하지만 이렇게 해버리면 기존 PR에 커밋이 추가될 뿐만 아니라 결과적으로 PR이 커지는 문제가 발생한다. 기존 PR을 다듬는 수준의 작은 커밋이라면 어느정도 양해할 수 있지만 독립 PR이 가능한 수준의 변경이라면 그 변경도 별도 PR로 올리는게 리뷰를 진행하기에 용이하다. 다만 아직 이전 PR이 main 브랜치에 머지되어 있지 않아 새로 PR을 생성하면 기존에 올라가있던 PR을 포함하는 형태의 큰 PR이 생성될텐데, 이때 추가 PR 생성은 베이스 브랜치를 main이 아니라 기존에 올라가 있던 PR을 대상으로하면 추가 변경에 대해서만 PR이 생성된다.
# 빠른 리뷰
위 내용들은 리뷰를 요청하는 입장에서 고려해야할 부분에 대해 정리했다. 마지막으로 그럼 리뷰를 진행하는 리뷰어들이 가져야할 자세는 동료의 PR을 최대한 빠르게 리뷰해주는 것이다. 물론 본인의 다른 업무로 인해 빠르게 보기 힘들 것이다. 하지만 내가 빠르게 봐주지 않으면 동료의 업무가 느려지게되니 최대한 짬을 내 리뷰를 빠르게 진행하는 노력을 해야한다. 지금은 내가 리뷰어지만 어차피 개발조직내에서 내일은 내가 리뷰 요청자가 될 것이기에 모두가 동료의 PR을 빠르게 리뷰해주는 문화를 만들면 결국은 내 PR도 빠르게 리뷰받을 수 있기 때문이다. 그리고 리뷰 요청자가 위 규칙들을 잘 지켜줬다면 PR의 크기가 크지않아 빠르게 리뷰하는것도 용이할 것이다.