오늘 같이 팀 프로젝트를 진행하는 팀원분의 repository를 확인해보다가 의문이 들어 팀원분께 질문을 드렸다.
PR 별로 작업 단위를 어떻게 가져가고 계시나요?
이러한 질문을 한 이유는 PR을 살펴보니 하나의 PR 안에 commit log가 여러 개 있었고, 그 commit 들은 PR과 연관성이 떨어져 있는 부분들이 많았기 때문이다.
그럼 어떻게 하면 좋은가요?
일단 나는 PR을 작성할 때 기능이나 작업별로 나눠서 작성했다. 또한 하나의 PR에는 하나의 commit이 들어가도록 작업을 하였다.
그럼 그렇게 한 이유는?
내가 그렇게 한 이유는 이전에 책에서 본 내용도 있고(아마 함께 자라기였던 걸로 기억한다),
같이 스터디를 했던 동료들과 서로 코드리뷰를 했었는데 PR의 작업 단위가 커지면 2가지 측면에서 문제가 생겼기 때문이다.
1. 코드리뷰를 하기 어렵다
PR의 작업 단위가 커지면 당연히 코드의 양도 많아진다. 그리고 읽는 사람 입장에서 작업의 단위가 작고 명확하지 않으며, 코드의 양이 많아지면 읽고 싶지 않게 된다. 즉, 읽는 사람을 생각하지 않았기에 가독성이 안 좋아지는 것이다.
만약 내가 새로 들어온 신입사원의 사수인데, 신입의 코드리뷰를 해야 한다고 생각해보자. PR 명만 봐도 작업이 두리뭉실하며 변경이 많은 코드랑 목적에 맞게 작게 쪼개서 올린 코드랑 비교해보면 어떤 게 더 보기 좋을까를 생각해보면 이해하기 쉬울 것이다.
2. 문제가 생겼을 때, PR 단위로 추적하고 복구하기 어렵다
RP를 commit 단위로 작게 쪼개서 작업을 하면 문제가 생겼을 때, PR 단위로 쉽게 추적하고 복구하기 쉽다. 그렇다면 반대로 그렇게 하지 않는다면 문제가 생겼을 때 쉽게 파악하기 어려울 것이며 복구도 어려워질 것이다.
내가 이 내용들에 대해 팀원분께 얘기를 해드렸더니 그분도 이 부분에 대해서 고민이 많았다고 한다. 그래서 어떤 파일을 건드렸는지 커밋별로 나눠져있으면 바깥에서 찾기 쉽지 않을까라는 생각으로 PR 하나에 여러개의 commit을 날렸다고 한다.
하지만 이걸 이용해서 commit 1개를 PR단위로 가져가면 더 쉽게 파악할 수 있게 된다.
어려운건 아니지만 귀찮은 작업
사실 최근에 내가 작업한걸 생각해보면 이 방법이 잘 지켜지고 있지는 않다. 어렵지는 않지만 귀찮기 때문이다.
작업을 하다 보면 중간에 현재 작업하고 있는 것과 관련이 없는 부분에서 수정하고 싶은 부분이 보일 때가 있다. 그러면 그 작은 부분 때문에 브랜치를 새로 만들고 PR을 날리기 귀찮아져서 PR 중간에 구겨 넣게 된다.
그러면 나중에 봤을 때, 이게 이 작업이랑 무슨 관련이 있는 거지라는 생각이 들 것이다.
왜 안 지켜졌을까?
이 부분을 개선하기 위해 왜 안 지켜졌는지를 자세히 생각해 보았다.
서로 코드리뷰를 하며 스터디를 할 때까지만 해도 잘 지켜졌지만, 그때랑 다르게 최근에는 개인프로젝트를 진행했으며, 지금은 팀 프로젝트를 진행하고 있지만 프론트 1명, 백엔드 1명으로 나눠져있기 때문에 서로의 코드를 볼 일이 그렇게 많지 않기 때문이다.
즉, 코드를 볼 사람이 없으니 조금은 대충해도 되겠지, 이 정도는 괜찮겠지라는 생각으로 지키지 않았던 것이다.
팀원분께 설명하면서 막상 내가 안지키고 있는걸 깨달으니 조금은 반성하게 된다.
이제부터는 항상 누군가 내 코드와 기록을 꼼꼼하게 본다고 생각하고 작업을 해야겠다.
