2분 59초 안에 좋은 PR 작성하기

서론 전 여담

아, 안타깝게도 필자의 능력 부족으로 인해

글을 3분 만에 읽을 수는 없다...

 

다만, 결과적으로, 3분 카레보다 빠르게 좋은 PR을 작성할 수 있도록 글을 쓰고자 노력했다!!

 

서론

Git을 여러 사람과 사용하게 된다면, Remote Repo로 Github을 쓸 일이 정말 많다.

특히 회사에서 Github을 쓰게 된다면, Pull Request(이하 PR)을 날릴 일이 엄청 많다.

기능 하나에 PR 한 번이라고 해도 무방하고,
기능을 쪼개서 개발하고 있다면 더 잦은 PR을 날릴 것이다.

 

PR이 왜 중요해?

개인적으로 생각하는 PR이 중요한 이유는 다음과 같다.

1. 기능을 합치는 단위이다.
2. 다른 사람들이 내가 작성한 코드의 완성본을 볼 수 있다.
3. 좋은 리뷰를 받을 수 있는 절호의 기회다.

특히 Production 환경에서 협업을 하고 있는 상황이라면, PR의 중요성을 깊게 깨달을 수 있다.

만약 배포한 기능이 서버에서 큰 에러를 뿜고 있다면 PR 커밋이 되돌릴 기준이 되기도 한다.

 

즉, PR은 단순히 '나' 뿐 아니라, 작게는 팀, 크게는 유저에게까지 영향을 미칠 수 있다.

따라서 PR에 관한 신중한 검토가 필요하다.

 

그러나...

PR을 관리하는 것은 쉽지 않은 일이다.

우리가 맞닥뜨릴 수 있는 문제는 여러 가지가 있다.

1. PR을 날려도 코드 리뷰를 해줄 좋은 동료가 없다.
2. Code Review를 해줄 수 있는 좋은 동료가 있더라도, 동료가 문제를 찾기 어려울 수 있다.
3. 동료는 본인이 작성한 코드가 아니고 무슨 내용인지 명확히 모르기 때문에, 시간을 많이 소비하게 될 수 있다.
4. 따라서, 내 코드에 대한 리뷰는 동료의 우선순위에서 종종 밀려버리기도 한다.
5. 심지어 배포했는데 동료가 찾지 못한 문제가 터져버렸다!

안타깝게도 이 글에서 1번에 대해서는 해결 방법을 제시할 수 없다...
(원피스의 루피도 동료를 찾으러 열심히 돌아다니지 않는가..)

해적왕이 될 루피도, 동료를 열심히 찾으러 다닌다..

그렇지만, 적어도 2번부터 5번까지는

간단한 방법을 통해 비약적인 향상을 할 수 있는 방법에 대해서 이야기하고자 한다.

 

본론

방안 1. PR의 단위를 줄여서 보내자

현대인은 본인이 쓴 글도 길면 잘 안 읽는 일이 빈번하다.

하물며 내용조차 파악하기 어려운 남의 코드는 어떻겠는가?

코드가 길면 길수록 가독성은 떨어지고, 동료는 집중력을 잃게 된다.

동료가 집중력을 잃게 되면 어떤 일이 생길까??

1. 더 많은 에러와 이슈를 잡아낼 수 있던 효율이 감소하게 된다.
2. 소요하는 시간이 기하급수적으로 증가하여 코드 리뷰의 우선순위가 밀리게 된다.
3. 따라서 기능을 배포하기까지 오랜 시간이 걸리게 된다.

세상에! 많은 코드를 동료에게 전달했더니 이런 Side Effect가 생긴다!!

적절한 라인 수라는 건 없지만,

개인적으로는 20개 이상의 파일을 건드리지 않는 선에서, 1000줄을 초과하지 않으려고 노력한다.

 

방안 2. PR 메시지를 명확하게 쓰고자 노력하자.

PR 메시지를 명확하게 쓰고자 노력한다.

보통 템플릿을 하나 만들어서 쓰고 있는 중인데,

 

- Summary (내가 뭘 했는지)

 

- Needs more than 10 min for review? (리뷰하는데 10분 이상 걸리는가? 걸린다면, 얼마나 걸릴지

 

- Before i request PR review,
(내가 PR 리뷰 부탁하기 전에 한 일.

예를 들면 개인 테스팅 환경에서 케이스들을 확인해봤다거나 test code를 run 했을 때 모두 통과했는지)

 

- After this PR reviewed,

(PR 리뷰가 끝난다면 뭘 해야 하는가? Merge 전 필요한 Process들.

예를 들면 DB 컬럼을 추가한다거나 Table을 만들어야 한다거나의 일들)

 

이런 간단한 템플릿을 이용해서 PR 메시지를 명확하게 쓰고자 노력한다.

 

메시지를 몇 가지 일부러 가리긴 했지만, 실제로 이런 PR 메시지를 작성해서 사용하고 있다.

 

방안 3) Github Action을 활용하자.(CI 툴도 환영!)

Github에는 Action이라는 아주 좋은 CI 툴이 존재한다.

특정 브랜치에 커밋하거나 PR을 날리거나 등등의 여러 조건에 해당하는 이벤트가 발생하면

특정 행동을 실행시켜주는 기능이다.

참고로 Travis CI로도 같은 일을 할 수 있지만, Github Action을 만들고 연결하는 게 엄청 엄청 쉽기 때문에

사용하는 것을 추천한다.

 

다만 아주아주 빈번하게 PR을 날리는 환경에서는 Pricing 정책을 잘 확인해서

사용하는 것이 좋다.

 

또한 템플릿이 잘 준비되어 있기 때문에, Node를 사용한다면 Node 템플릿을 쓰는 등 쉽게 적용할 수 있다.

도움이 될지는 모르겠으나, Node.js + TS + ESLint 환경에서 사용할 법한 Github Action 설정 파일(. yml)을 가져왔다.

참고하시기 바란다.

Node.js + TS + ESLint 환경 Github Action

Github Action이 잘 진행됐으면 PR에서 확인할 수 있다. 

 

결론

만약 이 방법들이 다 적용되어 있다면, 좋은 PR을 날리는데 얼마만큼의 시간이 필요할까?

정말로 3분 카레보다 빠르다!!

기존 템플릿을 가져와서,

본인이 아는만큼 내용을 적기만 하면 끝난다!!

 

고작 2분 59초지만, 동료에게는 소중한 30분을 아낄 수 있는 좋은 PR일 수 있다.

또한 동료가 본인에게 물어보는 일도 줄어들게 되니,

Communication에 사용하는 Resource도 감소하게 된다.

 

만약 2명 이상의 동료에게 PR Review를 요청했다면?

1시간 이상을 아낄 수도 있는 것이다!

 

ROI(Return Of Investment)가 엄청나지 않은가?

이 간단한 방법들을 지금 도입해서 본인과 동료의 Resource를 더 알차게 써보자!

 

좋은 PR을 쓰기 위해 참고했던 링크들

https://medium.com/hayanmind-tech-blog-kr/%EC%A2%8B%EC%9D%80-pr%EC%97%90-%EB%8C%80%ED%95%9C-%EB%8B%A8%EC%83%81-6586c3f757ac

좋은 PR에 대한 단상🤔

huns.me/posts/2019-12-17-34

GitHub Actions로 간단히 CI 서버 대신하기