martinfowler.com 에 Rouan Wilsenach 라는 엔지니어가 기재한 Ship / Show / Ask 라는 글을 읽고 번역한 글입니다. 제 사견이 첨가되어 있으니 감안하고 봐주시면 좋겠습니다.
Pull Request(PR)은 혁신이었고 현재 전세계적으로 많은 소프트웨어 팀이 자사의 소프트웨어 개발에 채택해서 사용하고있다. 하지만 PR 또한 문제점이 존재했다.
PR의 문제점
- PR은 지체될 수 있다. → 기다리는 시간이 낭비된다. → 제품의 배포가 지연된다.
- PR은 피로한 일이다. → 그냥 생각없이 승인하게될 수 있다. (LGTM)
Ship Show Ask 전략
Ship
- 변경을 바로 머지한다.
- 코드 리뷰 요청을 따로 안하는 것
- 어떤 상황에 적합할까?
- 일반적인 패턴을 따른 기능의 추가
- 사소한 버그 픽스
- 문서 갱신
- 피드백을 반영한 코드
Show
- PR은 만들지만 머지를 바로 한다. (리뷰 생략)
- 변경을 빠르게 적용하지만,
- 의견을 나눌 수 있는 여지를 남기는 것
- 어떤 상황에 적합할까?
- 더 좋은 코드를 위해 동료의 의견을 받으면 좋겠다.
- 새로 사용한 패턴이나 접근법을 공유하고 싶은 경우
- 내용을 공유하고 싶은 경우
Ask
- 일반적인 PR 패턴
- PR을 요청하고 즉시 머지하지 않고 동료들의 승인을 기다린다.
- 어떤 상황에 적합할까?
- 내 코드가 잘 동작할지 확인받고싶다.
- 새로운 접근법을 동료들은 어떻게 느끼는지 궁금하다.
- 내가 접근한 방법 이외에 더 나은 방법을 알고 싶다.
PR 승인 &코드 리뷰가 단순히 PR을 머지하기 위한 조건이어서는 안된다.
- 본인의 PR은 본인이 머지해야한다. → 변경에 대한 제어는 본인에게
- 브랜치는 길지 않게 유지하자. → 리베이스를 자주 하자.
대화의 중요성
- PR은 코드의 변경에 대해 논의할 수 있는 아주 유용한 방법 중 하나다.
- 하지만 이 때문에 PR이 대화를 대체할 수 있다고 생각한다면 그건 아주 큰 착각이다.
- 브랜칭 후 작업을 하고 PR을 요청하면 리뷰어들은 내가 선택한 그 솔루션에 매몰되기 쉽다.
- 최선이 아닐수도 있는 그 솔루션을 보면서 리뷰하면 다른 솔루션을 생각해내기 쉽지않다.
- 이는 PR의 사이즈가 커질수록 더 심해진다.
- 그래서 작업을 시작하기 전에 팀원과 대화를 먼저 해보자.
- PR이 Show 혹은 Ask 를 하기 위한 유일한 수단인건 아니다. 우리는 대화라는 훌륭한 수단이 있다.
- 팀원들에게 내 작업을 일찍 그리고 자주 보여주자.
세가지 방식 중 어떤걸 언제 쓰지?
- 기능을 특정한 패턴에 따라 개발하거나, 팀 내에 높은 수준의 quality standard 가 존재하고 그걸 항상 따른다면 Shipping 을 자주 하게 될 것이다. → 높은 수준의 테스트 코드가 필요할 것 같다.
- 아직 서로 알아가는 중이고, 새로운 시도를 많이 하게 된다면 Showing 이나 Asking 을 자주 하게 될 것이다.
- 주니어 엔지니어는 아무래도 Show, Ask 를 많이 요청할 것이고
- 시니어 엔지니어는 Ship을 상대적으로 많이 할것이다. 물론 새로운 테크닉이나 리팩토링을 소개해야한다면 Show 하는 자리가 필요할 것이다.
Ship / Show / Ask 가 주는 의미
PR은 코드 배포를 위한 반드시 거쳐야하는 관문같은게 아니다. PR은 코드 퀄리티를 높이기 위한 수단이다.
PR을 잘못 사용하면 코드는 배포하는 과정이 굉장히 지루하고 불필요하게 느껴지고 배포 주기에도 안좋은 영향을 줄것이다. Ship / Show / Ask 전략은 PR을 조금 유연하게 바라볼 수 있게 해준다.
Ship / Show / Ask 전략은 코드를 배포하기 전에 항상 나에게 한번 더 생각하도록 강요한다. “Always Ship” 과 “Always Ask” 의 양 극단 사이에서 이번 배포는 어디쯤에 위치하는게 적절할지 고민할 수 있도록.
Should I Ship, Show or Ask?
