<div id="readability-page-1" class="page"><div><article><div><div><p id="2b25">Pull Request(PR)은 혁신이었고 현재 전세계적으로 많은 소프트웨어 팀이 자사의 소프트웨어 개발에 채택해서 사용하고있다. 하지만 <strong>PR 또한 문제점이 존재</strong>했다.</p><h2 id="a445">PR의 문제점</h2><p id="842b">- PR은 지체될 수 있다. → 기다리는 시간이 낭비된다. → 제품의 배포가 지연된다.</p><p id="ca06">- PR은 피로한 일이다. → 그냥 생각없이 승인하게될 수 있다. (LGTM)</p><h2 id="79c0">Ship Show Ask 전략</h2><h2 id="39d1">Ship</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*X0jBGSJTY5pIIZ0QPNdLVw.png" width="700" height="211" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><ul><li id="1c00">변경을 바로 머지한다.</li><li id="5408">코드 리뷰 요청을 따로 안하는 것</li><li id="d22b">어떤 상황에 적합할까?<br>- 일반적인 패턴을 따른 기능의 추가<br>- 사소한 버그 픽스<br>- 문서 갱신<br>- 피드백을 반영한 코드</li></ul><h2 id="267e">Show</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*4QkbI-QUGj3xZ85paRuD_A.png" width="700" height="249" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><ul><li id="0e2c">PR은 만들지만 머지를 바로 한다. (리뷰 생략)</li><li id="9f13">변경을 빠르게 적용하지만,</li><li id="72bf">의견을 나눌 수 있는 여지를 남기는 것</li><li id="2bfc">어떤 상황에 적합할까?<br>- 더 좋은 코드를 위해 동료의 의견을 받으면 좋겠다.<br>- 새로 사용한 패턴이나 접근법을 공유하고 싶은 경우<br>- 내용을 공유하고 싶은 경우</li></ul><h2 id="2f82">Ask</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*V7OScQTjc_UF7DtuPklW1Q.png" width="700" height="281" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><ul><li id="73ca">일반적인 PR 패턴</li><li id="2f40">PR을 요청하고 즉시 머지하지 않고 동료들의 승인을 기다린다.</li><li id="80ae">어떤 상황에 적합할까?<br>- 내 코드가 잘 동작할지 확인받고싶다.<br>- 새로운 접근법을 동료들은 어떻게 느끼는지 궁금하다.<br>- 내가 접근한 방법 이외에 더 나은 방법을 알고 싶다.</li></ul><blockquote><p id="d0a4">PR 승인 &amp;코드 리뷰가 <strong>단순히 PR을 머지하기 위한 조건이어서는 안된다.</strong></p></blockquote><ul><li id="2481">본인의 PR은 본인이 머지해야한다. → 변경에 대한 제어는 본인에게</li><li id="8bfd">브랜치는 길지 않게 유지하자. → 리베이스를 자주 하자.</li></ul><h2 id="58fd">대화의 중요성</h2><ul><li id="93bd">PR은 코드의 변경에 대해 논의할 수 있는 아주 유용한 방법 중 하나다.</li><li id="fa2c">하지만 이 때문에 <strong>PR이 대화를 대체할 수 있다고 생각한다면 그건 아주 큰 착각</strong>이다.</li><li id="c4f4">브랜칭 후 작업을 하고 PR을 요청하면 리뷰어들은 내가 선택한 그 솔루션에 매몰되기 쉽다.</li><li id="5db6"><strong>최선이 아닐수도 있는 그 솔루션을 보면서 리뷰하면 다른 솔루션을 생각해내기 쉽지않다.</strong></li><li id="2782">이는 PR의 사이즈가 커질수록 더 심해진다.</li><li id="9a1f">그래서 <strong>작업을 시작하기 전에 팀원과 대화를 먼저 해보자.</strong></li><li id="b67c">PR이 Show 혹은 Ask 를 하기 위한 유일한 수단인건 아니다. 우리는 대화라는 훌륭한 수단이 있다.</li><li id="5378"><strong>팀원들에게 내 작업을 일찍 그리고 자주 보여주자.</strong></li></ul><h2 id="3bac">세가지 방식 중 어떤걸 언제 쓰지?</h2><ul><li id="4e82">기능을 특정한 패턴에 따라 개발하거나, 팀 내에 높은 수준의 quality standard 가 존재하고 그걸 항상 따른다면 Shipping 을 자주 하게 될 것이다. → 높은 수준의 테스트 코드가 필요할 것 같다.</li><li id="58e3">아직 서로 알아가는 중이고, 새로운 시도를 많이 하게 된다면 Showing 이나 Asking 을 자주 하게 될 것이다.</li><li id="a069">주니어 엔지니어는 아무래도 Show, Ask 를 많이 요청할 것이고</li><li id="80f0">시니어 엔지니어는 Ship을 상대적으로 많이 할것이다. 물론 새로운 테크닉이나 리팩토링을 소개해야한다면 Show 하는 자리가 필요할 것이다.</li></ul></div><div><h2 id="529d">Ship / Show / Ask 가 주는 의미</h2><p id="3cb2">PR은 코드 배포를 위한 반드시 거쳐야하는 관문같은게 아니다. PR은 코드 퀄리티를 높이기 위한 수단이다.</p><p id="4cb9">PR을 잘못 사용하면 코드는 배포하는 과정이 굉장히 지루하고 불필요하게 느껴지고 배포 주기에도 안좋은 영향을 줄것이다. Ship / Show / Ask 전략은 PR을 조금 유연하게 바라볼 수 있게 해준다.</p><p id="726e">Ship / Show / Ask 전략은 코드를 배포하기 전에 항상 나에게 한번 더 생각하도록 강요한다. “Always Ship” 과 “Always Ask” 의 양 극단 사이에서 이번 배포는 어디쯤에 위치하는게 적절할지 고민할 수 있도록.</p><blockquote><p id="13bb">Should I Ship, Show or Ask?</p></blockquote></div></div></article></div></div>

Stories by allocProc on Medium

jaeyeong

PR을 유연하게 : Ship Show Ask 전략
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?

PR을 유연하게 : Ship Show Ask 전략

댓글