칼박 안무 같은 코드리뷰 GOAL

• 코드 리뷰란
• pull request를 하는 이유
• pull request의 flow 이해하기
• 코드 리뷰문화를 정착하기 위해 필요한것들 알아보기

코드리뷰

• 개발자가 작성한 코드를 다른 사람들이 검토하고 피드백을 전달하며, 다시 작성자가 반영하는 과정을 말한다. 이과정을 통해 서비스의 기술적인 구현 부분에 대해 공유 및 습득 할 수 있으며, 일괄된 아키텍처를 유지하고, 문제를 해결 할 수 있는 새로운 관점을 발견할 수도 있다.
• 더 나아가 잠재적인 장애 및 버그를 배포전에 발견하여 전반적인 서비스 운영 비용을 절약 할 수 있다.
• 가장 중요한 핵심은 단순히 코딩 스타일을 일괄되게 유지하거나, 예상되는 문제를 일찍 파악하는데 끝나지 않고 코드에 대한, 역할에 대한 책임이 개인에 있지 않고 우리 모두에게 우리 모두의 개발자에게 있다는 문화를 만드는데 있다고 할 수 있다.
  코드 리뷰 in 뱅크셀러드

  “소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.” - 코드 컴플릿, 스티브 맥코넬

pull request를 하는 이유

• 자연스러운 코드 리뷰를 위해
• Push 권한이 없는 오픈 소스 프로젝트에 기여할 때
• 콜라보레이터에 소속되어있는 경우에는, 그 저장소에서 브런치를 따고 푸쉬하면 풀리퀘가 가능하다. + 에서 branch가 보이는 경우는 그 저장소만의 기능이다
• Push로 협업했을때, 다른 사람의 commit을 볼 일이 많지 않고, master branch와 merge할 때서야 보게되는데, Pull Request는 당장 merge하지 않는다는 규칙이 Pull Request를 보고, 코드에 신경쓰게되고 어떤 작업이 언제 적용되었는지 알 수 있다. 오히려 당황스러운 코드충돌을 줄일 수 있다.

pull request flow

PR FLOW 다이어 그램

• 내가 작성한 code가 완료가 되면 (이전에 이미 feature라는 브랜치가 있다고 가정하에) develop에 merge를 검토를 요청하기 위한 PR(Pull Request)를 요청한다.
• PR(Pull Request)요청이 들어 오면 팀내 리뷰어에 의해서 코드리뷰를 진행하게 된다. 만약 리뷰에 의해서 승인되지 않으면 다시 수정하여 요청하고 리뷰어에 의해서 승인이 되면 develop에 merge가 승인된다.

GitFlow기준으로 바라본 PR 다이어그램

• 해당 다이어그램은 git-flow를 기준으로 branch전략을 도입했을때 PR(Pull request)하는 방법이다.
• develop에서 feature라는 branch를 가지치기 했을때 해당 feature를 기능을 완료하고 develop에 merge하도록 요청하는것을 PR(Pull Request) 이고 리뷰어에 의해서 승인이 되면 자연스럽게 develop에 merge가 된다.

그렇다면 PR을하기 위해서 필요한 것이 뭐가 있을까?

코드 리뷰문화를 정착하기 위해 필요한것들 알아보기

코드리뷰 Rule 정의

코드리뷰에 임하는 자세

가장 강요하고 싶은 내용이다. 코드리뷰는 험담이나 서로간에 험담을 하는 자리가 절대적으로 아니다. 궁긍적으로 공통된 목표를 달성하기 위해 코드리뷰를 하는 것이지 개인의 개발자의 자존심을 세우기 위한 자리는 아니다. 만약 한명이라도 개인의 자존심을 세우는 개발자가 있다면 제대로 된 코드리뷰를 정착 시킬수 없다.
(이것은 실제로 겪은 경험담이다.)

• 일괄된 아키텍처를 유지하는지 확인
• 리뷰를 통하여 버그 발생 가능성 제시
• 기술적인 노하우, 지식 공유, 히스토리 전달
• 코드리뷰를 하는 사람 당하는 사람의 마음가짐(서로간에 존중, 마음상하지 않도록)

PR 크기에 대한 정의

• PR 요청 후 리뷰어가 검토 해야 할 코드가 많으면 빠른 리뷰가 불가능
• 또한 리뷰어도 업무가 있다보니 부담 스럽운 양이다.
• 가장 중요한건 PR크기를 쪼개야 merge시 충돌이 일어날 확률을 최소화 할 수 있다.

Commit message 정의

• commit message를 세분화 하여 메세지만 보면 어떤 기능에 대해서 추가 하였는지 확인이 가능하도록 한다.
• 그만큼 파악이 빠르면 리뷰어가 리뷰를 진행할때 빠른 리뷰를 할 수 있도록 도음이 될 것이다.

PR에 대한 횟수

• 하루 1번 PR을 검토 할지 또는 격일로 PR을 검토 할지에 대해서 팀 내부끼리 정하여 룰을 정한다.
• 수시로 PR이 날라오면 미사일로 아니고 리뷰어는 수시로 PR을 처리하느라 엄청난 고통에 시달릴 것이다.

Pn Rule

리뷰어가 코멘트를 강조하는 정도를 표현하는 Rule를 정하는 것이다. 어느정도 해당 룰을 정해야 의도치 않게 코드리뷰시 상대방을 맘 상하지 않게 할 수 있다. 만약 정해진 규칙 없이 리뷰를 하게 된다면 상대방에게 상처를 줄 것이다.

• P1 : 꼭 반영해주세요 (Request changes)
• P2 : 적극적으로 고려해주세요 (Request changes)
• P3 : 웬만하면 반영해주세요 (Comment)
• P4 : 반영해도 좋고 넘어가도 좋습니다 (Approve)
• P5 : 그냥 사소한 의견입니다. (Approve)

D-N Rule

보통 PR에 대해서 리뷰를 하는 리뷰어는 소수 일것이다. PR을 리뷰하는 리뷰어가 쉽게 PR순서를 확일 할 수 있도록 순서를 정의하여 빠른 리뷰를 할 수 있도록 도와 준다.
D-0 : ASAP
D-N : Within N days
ex) D-1 : 하루안에
ex) D-2 : 2일 안에

결론

이것으로 코드리뷰 도입을 위한 최소한의 규칙을 정해보았다.
사실 정말 예전부터 코드리뷰나 프로젝트 리뷰를 해보고 싶었지만 코드리뷰, 프로젝트 리뷰는 "문화"에 가깝기 때문에 개인이 혼자 하기에는 굉장히 어렵다.
또한 팀내 리더로 이러한 문화를 정착하기 위한 많은 노력을 하더라도 팀 구성원들이 따라 주지 않으면 개발 문화는 정착 할 수가 없는것 같다.
지금 현 상황은 코드리뷰를 도입하기 위한 가장 좋은 찬스 이며 코드리뷰를 정착하기 위해 많은 노력을 해야 할 것이다.
하지만 더 중요 한것은 팀 구성원과의 협업?, 호흡?, 티키타가? 통해야 하는것이다. 서로 존중하며 험담 하지 않는 것이 가장 먼저이며 가장 중요한것 같다.
다음은 코드리뷰를 도입하며 어려웠던점이나 코드리뷰를 성숙하게 발전하기 위한 노력들에 대한 경험담이 공유 될 것이다.
부디!!!! 코드리뷰 도입에 성공하길!!!!