path---posts-code-review-guide-f086e83c602f8766a7cb.js

webpackJsonp([0xe22934ba247a],{381:function(e,i){e.exports={data:{site:{siteMetadata:{title:"May-B",subtitle:"the force be with you ✨",copyright:"© All rights reserved.",author:{name:"May"},url:"https://eunjung-seo.github.io/"}},markdownRemark:{id:"/Users/may/Git/mei/my-blog/src/pages/articles/2018-16-04---code-review-guide/index.md absPath of file >>> MarkdownRemark",html:'<p>좋은 엔지니어링 팀의 문화로 손꼽히는 것 중 하나가 code review(또는 peer review)이다. 코드 리뷰를 통해 실수를 미리 방지하고 팀원들은 리뷰를 통해 서로의 성장에 도움이 될 수 있다. 꽤 많은 팀들이 코드 리뷰를 도입하고 있고 그와 관련한 아티클들도 많이 찾아볼 수 있다.</p>\n<p>내가 속해 있던 팀도 코드 리뷰를 했었다. 처음 팀에 합류했을 땐 신입이었기에 코드 리뷰를 하며 많이 성장했고 다양한 생각의 관점을 배울 수 있었다. 특히 가독성을 높이면서도 간결하게 구현하는 법을 배울 수 있었다. (멤버들에게 감사를🙏)</p>\n<p>하지만 신입의 기간이 지나면서 코드 리뷰가 감정적으로 힘들어지기 시작했다. 리뷰어가 남긴 코멘트가 명령조처럼 느껴지기도 하고 코드 작성자에 대한 지나친 간섭처럼 느껴졌다. 코드 리뷰는 좋은 문화고 이건 다 날 위한 조언이란 생각에 꾸역꾸역 코드를 수정해 승인을 받았지만, 리뷰 과정에서 받는 스트레스는 날로 커져만 갔다.</p>\n<p>코드 리뷰의 목표는 무엇일까? 우리는 무엇을 리뷰하는 것일까? 코드일까 아니면 사람일까? 리뷰 과정에서 내가 취할 수 있는 자세는 무엇일까?  다른 팀들은 어떻게 코드 리뷰를 하고 있을까? 나 같은 생각을 하는 사람들이 있을까?</p>\n<p><img src="/hmm-dec436cac8460409deccc5dfe3718466.gif" alt="hmm"></p>\n<p>원칙 없이 실행되고 있는 팀의 코드 리뷰 문화에 환기를 주고자 우리 팀을 위한 코드 리뷰 가이드를 작성해보기로 했다. 우선 다른 팀들은 코드 리뷰를 어떻게 진행하고 있는지 찾아봤는데 리뷰 도구나 리뷰 요청법 등 방법론에 관한 글들이 대부분이었다. 가뭄에 콩 나듯 리뷰 가이드가 있었지만, 코드 리뷰의 의미를 기술한 글은 찾기 어려웠다.\n결국 당시 팀의 core value와 문화, 1년간 내가 겪은 코드 리뷰의 경험에서 그 의미를 찾아 코드 리뷰 가이드를 작성했고 이 또한 팀의 리뷰를 거쳐 배포되었다.</p>\n<p>아래는 내가 작성한 코드 리뷰 가이드이다. 리뷰어와 리뷰이가 지켜야 할 행동 가이드라 할 수 있다. 기존 작성안을 약간 수정해 올려본다.</p>\n<hr>\n<p>코딩은 개인의 작업이지만 코드 리뷰를 통해  협업과 소통의 장이 됩니다. (coding is a social process).  우리는 서로의 코드를 보며 함께 성장하는 문화를 추구합니다.  그 과정에서 생기는 논쟁들은 당연하며 성장을 위한 발판이라고 생각합니다.  원활한 커뮤니케이션과 효과적인 리뷰를 위해 우리는 다음의 기준들을 지키려 노력합니다.</p>\n<h3>Reviewers &#x26; Reviewee</h3>\n<ul>\n<li>의견을 숨김없이 명확히 전달합니다 - 상대방이 의도를 잘 이해할 수 있도록 전달합니다</li>\n<li>코드는 우리 모두의 것입니다 - ‘당신이 작성한 코드’ 혹은 ‘내가 작성한 코드’라는 언급을 피합니다</li>\n<li>의견을 강요하는 대신 질문하거나 제안합니다 - ‘~에 대해 어떻게 생각하나요?’</li>\n<li>다른 의견도 열린 자세로 받아들입니다</li>\n<li>과장법(‘항상’, ‘절대’, ‘하찮은’ 등)을 사용하지 않습니다</li>\n</ul>\n<h3>Reviewers</h3>\n<ul>\n<li>작성자가 아닌 코드를 리뷰합니다</li>\n<li>작성자의 관점을 이해하려고 노력합니다</li>\n<li>코드를 단순화하는 방향으로 리뷰합니다</li>\n<li>무엇이 왜 문제가 되는지 잘 설명하고 해결책도 함께 제시합니다</li>\n<li>대안을 제시할 때 작성자가 이미 그것을 고려했을 것으로 가정합니다</li>\n<li>작성자의 코드가 정 맘에 들지 않는다면 다음 기회에 본인이 수정할 수 있습니다</li>\n</ul>\n<h3>Reviewee</h3>\n<ul>\n<li>첫 번째 리뷰어는 나 자신입니다 - 스스로 찾아낼 수 있는 실수들을 미리 고치고 리뷰 요청을 합니다</li>\n<li>적절한 크기의 PR을 만듭니다</li>\n<li>어떤 문제를 해결하고자 했는지 잘 설명합니다</li>\n<li>리뷰어의 의견에 감사하며 되도록 모든 코멘트에 응답하도록 노력합니다</li>\n<li>개인에 대한 리뷰로 받아들이지 않습니다</li>\n<li>리뷰어의 의견을 잘 청취하되 결정은 본인의 몫입니다</li>\n</ul>\n<hr>\n<p>이 가이드는 잘 지켜졌을까? 나만큼 이 문제에 관심이 있는 팀원이 없어서인지 가이드 제시로만 그치고 만 것 같다. 나름 가이드의 도입 부분에 심적 울림을 주려 노력했는데 내 마음만 울었나 보다. 😂</p>\n<p>코드 리뷰에 관심이 있다면, <a href="http://codelegance.com/effective-code-review-with-two-simple-rules/">Effective code review with two simple rules</a> 👈 이 글을 추천한다. 나도 가이드를 작성하며 많이 참고했다.</p>',fields:{tagSlugs:["/tags/code-review/"]},frontmatter:{title:"코드 리뷰 어떻게 하고 있나요?",tags:["code review"],date:"2018-04-15T16:55:03.632Z",description:"좋은 엔지니어링 팀의 문화로 손꼽히는 것 중 하나가 code review(또는 peer review)이다. 코드 리뷰를 통해 실수를 미리 방지하고 팀원들은 리뷰를 통해 서로의 성장에 도움이 될 수 있다. 꽤 많은 팀들이 코드 리뷰를 도입하고 있고 그와 관련한 아티클들도 많이 찾아볼 수 있다."}}},pathContext:{slug:"/posts/code-review-guide/"}}}});
//# sourceMappingURL=path---posts-code-review-guide-f086e83c602f8766a7cb.js.map