Agile pull requests (feat. PR관리방법)

Q. 상황

팀원과 프로젝트를 진행하며 PR을 2주만에 코드리뷰를 하고 PR단위가 1000이 넘어가면서 Github를 잘 못 사용하고 있고 코드리뷰를 제대로 하고 있지 않다고 생각하였습니다.  

 

PR의 단위를 작게하려고 노력하고, 즉각적인 리뷰를 통해 따른 코드리뷰를 해야한다는 것을 알고 1개의 커밋에는 1개의 행위만, 1개의 PR에는 1개의 작업만 해야하는 것을 알지만 그렇게 실행하고 있지 못하였습니다. 

 

---

Q. 질문

문제점을 개선하기 위해 앞으로 PR작업을 어떻게 해야 할까?

 

---

PR관리 방법 7가지

PR관리 방법은 따로 정리하지 않을 생각입니다. 헤이딜러 개발 블로그에 PR곤리방법에 대해 자세히 설명해 주고 있으니 PR관리 방법에 대해 알고 싶으신 분들은 링크를 참고해 주세요!

https://medium.com/prnd/%ED%97%A4%EC%9D%B4%EB%94%9C%EB%9F%AC-%EA%B0%9C%EB%B0%9C%ED%8C%80-%EB%AA%A8%EB%91%90%EA%B0%80-%ED%96%89%EB%B3%B5%ED%95%9C-%EA%B0%9C%EB%B0%9C-pr%EA%B4%80%EB%A6%AC-%EB%B0%A9%EB%B2%95-7%EA%B0%80%EC%A7%80-1d4cd5d091f0

헤이딜러 개발팀 모두가 행복한 개발/PR관리 방법 7가지

 

---

Agile Pull Requests

애자일 소프트웨어 개발 운동은 소프트웨어 개발의 방법을 찾는 데 중요한 역할을 했습니다. 또한 테스트 주도 개발, 지속적 전달, 변화에 대한 대응 등과 같은 획기적인 아이디어를 제공하였습니다. 그러나 애자일 소프트웨어 개발을 하는 대부분의 조직은 여전히 애자일 풀 리퀘스트를 사용하는데 어려움을 겪고 있습니다.

 

즉, 간단하게 요약한다면 애자일 풀 리퀘스트를 사용하는 방법이 잘 못되어 오히려 협업 능률을 떨어트린다는 것입니다. 지금부터 올바른 Agile Pull Requests를 사용하기 위한 간단한 팁을 설명하겠습니다.

 

# Pull Request 문제 및 솔루션

1. PR단위가 너무 크다 

PR단위가 너무 커서 관련 없는 것들을 함께 묶고 필요없는 작업을 유발합니다. 아래의 링크를 읽고 효율적인 PR방법을 알아가면 좋을것 같습니다.

https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/

10 tips for better Pull Requests

 

 

 

 

2. PR 코드리뷰 프로세스에 문제가 있다. 

PR에 대한 코드리뷰 시간이 너무 오래 걸린다는 것입니다. 

# 잘못된 PR과 코드리뷰 프로세스 그림입니다. 개발자가 검토를 위해 PR하고 코드리뷰가 수행되기까지 많은 시간이 걸린다는 것입니다.

 

# 올바른 PR과 코드리뷰 프로세스 그림입니다. 개발자가 검토를 위해 PR을 하고 바로 코드리뷰가 수행되기까지 대기 시간이 작다는 것입니다.

 

즉, PR단위를 작게하고 빠른 코드리뷰를 통해서 효율적인 협업을 해야한다는 것을 알 수 있었습니다.

---

PR과 페어프로그래밍에 대해서

You can make the pull request process work, but should you? Isn't pair (or ensemble) programming better?

Pair programming can also be effective. I discuss that too in my new book. What works best, I believe, is a question of trade-offs. What's more important to you? Latency or throughput?

In other words, while I have a personality-based preference for the contemplative, asynchronous pull request process, I readily admit that pair or ensemble programming may be better in many situations.

I suspect, however, that many proponents of pair programming are as driven by their personality-based preference as I am, but that since they might be extroverts, they favour close personal interaction over contemplation.

In any case, use what works for you, but be wary of unequivocal claims that one way is clearly better than the other. We have scant scientific knowledge about software development. Most of what I write, and what industry luminaries write, is based on anecdotal evidence. This also applies to this discussion of pull requests versus pair programming.

저는 2인 프로젝트를 페어 프로그래밍을 통해 하고 있습니다. 매일 아침 스터디 시간을 가지고 있기 때문에 코드리뷰를 올바르게 하지 않았던 것 같습니다. 페어 프로그래밍이 가지는 장점이 있지만 단점도 많이 있는것 같습니다. 하지만 페어 프로그래밍 때문에 코드리뷰를 제대로 하지 않는 것은 잘못된 방법이라고 생각합니다.  

 

---

결론

링크를 작성한 저자는 "한 팀은 팀 구성원의 절반 이상이 원격에서 작업했기 때문에 지속적인 배포를 구현하고 pull 요청을 사용했습니다. pull 요청은 작았고 검토는 일반적으로 5-10분 안에 완료될 수 있었습니다. 이를 알고 리뷰는 신속하고 빈번했습니다. 턴어라운드 시간이 좋았습니다." 라고 말하였습니다. 

 

지금은 2인 프로젝트이기 때문에 문제가 크게 발생하지 않았지만 추후 현재 방식은 매우 좋지 않다고 생각합니다. 저도 앞으로는 PR의 단위를 작게 줄이고 코드리뷰를 즉각적으로 함으로써 올바른 협업 문화를 만들어 볼 생각입니다.

 

---

추가적으로..

"의사소통의 계층 구조"

1. API에 고유한 유형을 제공하여 독자를 안내합니다.
2. 메소드에 유용한 이름을 지정하여 독자를 안내합니다.
3. 좋은 코멘트를 작성하여 독자를 안내합니다.
4. 자동화된 테스트로 예시적인 예를 제공하여 독자를 안내합니다.
5. Git에서 유용한 커밋 메시지를 작성하여 독자를 안내합니다.
6. 좋은 문서를 작성하여 독자를 안내하십시오

 

 

Reference

https://medium.com/prnd/%ED%97%A4%EC%9D%B4%EB%94%9C%EB%9F%AC-%EA%B0%9C%EB%B0%9C%ED%8C%80-%EB%AA%A8%EB%91%90%EA%B0%80-%ED%96%89%EB%B3%B5%ED%95%9C-%EA%B0%9C%EB%B0%9C-pr%EA%B4%80%EB%A6%AC-%EB%B0%A9%EB%B2%95-7%EA%B0%80%EC%A7%80-1d4cd5d091f0 (헤이딜러 개발 블로그 / PR작업 7가지 팁)

https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/ (Agile Pull Request)

https://blog.ploeh.dk/2021/06/21/agile-pull-requests/#7c5640fbc0a8418799e4b7a6266a01b2 (PR작업 10가지 팁)