티스토리 뷰
멋진 코드 리뷰에 대하여 (GOTO 2019 - Amazing Code Reviews: Creating a Superhero Collective 정리)
Brilliant Bennett 2020. 9. 29. 00:41나는 운이 좋게도 개발을 제대로 시작한 프로젝트가 꽤 큰 규모의 프로젝트였다. 기간도 길었던 프로젝트인 만큼 배운 점이 많다. 코드 리뷰는 바로 그중 하나다.
그동안 쌓인 프로젝트 경험과 지금 일하면서 배운 것들을 토대로 다음 영상 내용과 나의 생각을 정리해보려고 한다. 영상은 GOTO 컨퍼런스에서 Alejandro Lujan 가 발표한 '좋은 코드 리뷰'에 대한 발표다.
링크: https://www.youtube.com/watch?v=ly86Wq_E18o&ab_channel=GOTOConferences
Great code reviews: symptom and contributing cause of highly effective teams
발표자는 소프트웨어를 만들 때 고려해야 할 4가지를 바탕으로 발표하며 다음과 같다.
- Build the right thing
- Build the thing right
- Build it fast
- Build it together
Build the right thing!
규모가 크고 복잡한 소프트웨어일수록 개발 비용이 크고 시간도 오래 걸린다. 그렇기 때문에 요구사항에 맞는 제품을 만들고 있는지 확인해야 한다. 이를 위해 개발을 시작한 후, 개발에 대한 방향성을 먼저 보여야 한다. 올바른 방향으로 이해하고 개발하는지를 확인해야 한다.
빠른 PR을 통해 피드백을 받자. 빠른 PR이란 개발을 빨리 끝내고 올리라는 뜻이 아니다. 나의 생각, 나의 의도, 나의 이해가 과연 맞는지를 리뷰를 통해 확인해보는 것이다. 예를 들어, 인터페이스나 빈 메소드를 먼저 올려보는 것이다. 이를 통해 요구사항을 만족할 설계와 구현이 나올지를 점검해보는 거이다. 이 작업을 통해 다시 일하는 것을 줄일 수 있다.
그리고 다른 사람들에게 배울 수 있도록 오픈 마인드를 가져야 한다. 구현에 치중한 나머지 구조적인 면에서 신경을 못쓰거나 반대로 구현에서 발생할 수 있는 문제점들이 리뷰를 통해 나올 수 있다. 또, 리뷰어들이 개선하면 좋을 만한 점들을 피드백해주며 best practice에 가까워질 수 있다. 자만하지 말고 겸손한 자세를 갖자. 그리고 리뷰는 각자의 시간을 나, 그리고 나의 코드에 할애하는 것이기에 리뷰어에게 감사한 마음을 갖자.
발표자는 Draft PR 이라는 기능을 소개했다. Draft PR은 앞에서 설명한 빠른 PR을 효과적으로 이용할 수 있도록 도와주는 GitHub의 기능이다. 이 PR은 merge할 수 없고 code owner에게 알림이 가지 않는 특징이 있다. 부담 없이 PR을 작성할 수 있으므로 빠른 PR 작성을 돕는다.
실제로 나는 지금까지 Skel, WIP 등의 접두사를 붙여 Draft PR과 비슷하게 PR을 작성해왔다. 작업이 구체화되면 접두사를 고쳐야 하는 번거로움과 PR 자체가 점점 더러워진다는 불편함이 있었는데 앞으로 Draft PR을 적극 사용해봐야겠다.
Build the thing right!
또 하나 생각해야 할 점은 '올바른 방식으로 개발하고 있는가?'이다. 좋은 제품, 좋은 코드가 나오려면 그것을 만들기 위한 방법에 대해서도 고민해야 한다. 발표자는 발표에서 KISS(?!)를 말한다. Keep It Small and Simple 이라는 뜻이다.
Small 하고 Simple하기 위해서 발표자는 가이드라인을 제시했다. 200~300줄 사이의 PR이 가장 적당하다는 것이다. 코드가 짧으면 리뷰하기 쉽다. 리뷰를 시작하기도 쉽고 좀 더 깊고 꼼꼼하게 볼 수 있다. 실제로 1000~2000줄 이상의 코드를 올리게 되면 리뷰어는 숨이 막힌다. 코드를 다 보는 것도 굉장한 시간과 에너지를 소모하게 되며 기억하거나 비교해야 할 내용도 많아 꼼꼼하게 확인할 수 없게 된다. 오히려 눈에 띄는 오타, 변수명, 함수명 등 작고 자세한 것에 대한 코멘트만 달리며 approve를 받을 수도 있다. 이는 리뷰어의 리뷰 포기라고도 생각할 수 있을 것 같다.
만약, 작업 단위가 매우 크다면 여러 개의 PR로 나누자. 데이터 모델링, 알고리즘 구현, API 설계 등과 같이 PR을 나누어 올리며 전체적인 큰 그림을 잃지 않도록 해야 한다. 그렇다고 너무 작게 나누면 오히려 큰 그림을 보기 힘들기 때문에 적당한 길이의 PR로 잘라 올리도록 하자.
그리고 커밋을 잘 정리해야 한다. 커밋이 단순히 '작업 내용을 저장' 한다는 의미를 가져서는 안 된다. 어떤 기능이나 문제를 해결했다는 명확한 의미로 나뉘어야 한다. GitHub 잔디 욕심이 솟구치지만 커밋에 잔디 그 이상의 의미를 부여해보자. 그렇다 보면 1개의 PR은 1~2개의 커밋으로 구성될 것이다. 이는 나중에 커밋 히스토리를 트래킹 하거나 roll back 하기에 용이할 것이다.
리뷰를 받고 코드를 수정해야 한다면 rebase 기능을 추천한다. 리뷰받은 코드가 작성된 커밋으로 돌아가 코드를 수정한 후 올리는 것이다. 이러면 커밋이 매우 깔끔해진다. 다만, 커밋이 많은 상황이라면 리뷰 반영한 내용을 하나의 새로운 커밋으로 모두 모으는 것도 방법일 수 있다.
여러 개의 PR이 서로 의존성을 가지게 된다면 Git 브랜치의 여러 기능들을 활용하자. A PR 이후에 작업할 수 있다면, B 브랜치를 A 브랜치에서 생성하여 작업을 이어나가자. 그렇게 B PR이 작성되면 A PR의 커밋들도 포함되어 커밋이 많아지지만 A PR이 merge 되면 GitHub에 자동적으로 반영되어 B PR에는 B 브랜치에서 작업한 내용만 남게 된다.
리뷰어 역시 좋은 리뷰를 위해 고민해야 한다. 리뷰어는 '어떻게 당신이 코드를 향상할 수 있을까'가 아닌 '어떻게 우리가 코드를 향상할 수 있을까'를 고민해야 한다. 모두가 ownership을 가지고 생각하자. 그리고 리뷰어는 Actionable Feedback을 해야 한다. 즉, 코드 작성자가 무엇을 해야 하는지 구체적인 액션을 피드백해야 한다. 그렇다면 코드 작성자도 더 빠르게 받아들이고 코드를 수정할 것이다. GitHub의 코드 제안 기능은 내가 자주 사용하는 기능 중 하나다.
코드 작성자와 리뷰어 모두 자신의 의도가 올바르게 전달될 수 있도록 최대한 노력하자. 온라인으로 혹은 비동기적으로 이루어지는 경우가 많기 때문에 상대를 충분히 고려하여 자신의 의도를 제대로 전달하자. 이는 곧 좋은 커뮤니케이션으로 가는 첫걸음이기도 하다.
많은 리뷰어들이 놓치고 있는 점 중 하나는 바로 긍정적인 피드백이다! 칭찬은 고래도 춤추게 만든다. 그렇다면 칭찬받은 PR 작성자는 얼마나 격하고 화려한 춤을 추겠는가(?) 특히 경력이나 실력이 비교적 낮은 사람일수록 말이다! 이때, 구체적인 피드백을 통해 어떤 점이 좋았는지를 제대로 전달하여 좋은 점이 계속 이어질 수 있도록 하자.
Exercise: Review the review
영상 20분 13초부터 실제 코드 리뷰를 리뷰해보는 시간이다. 꽤 재밌는 시간이니 넘기지 말고 같이 코드 리뷰를 리뷰해보면 좋을 것 같다. 다양한 코드 리뷰 문화를 경험해보지 못했다면 더더욱 추천한다.
Build fast!
코드 리뷰는 개발 속도를 늦추곤 한다. 리뷰어에게 디펜던시가 걸리게 되어 진행이 불가능해지기 때문이다. 이렇기 때문에 모든 리뷰어들은 리뷰에 높은 우선순위를 부여해야 한다. 자신 때문에 다른 사람의 진행 속도가 느려지지 않도록 말이다. '올라온 PR은 2일 이내에 리뷰해야 한다'와 같은 정책을 통해 다른 사람의 개발을 막지 않도록 하자.
PR이 너무 많이 쌓여있으면 리뷰어는 컨텍스트 스위칭에 많은 에너지를 소모하게 된다. 이는 리뷰에 대한 집중력을 흐리게 만들기도 하기 때문에 결과적으로 리뷰어에게도 안 좋은 영향을 끼칠 수 있다. 되도록 빠르게 리뷰하도록 하자.
또, 어떤 논의 사항이 생겼거나 많은 사람들이 다양한 생각을 이야기하며 리뷰가 길어진다면 컨콜 등을 이용하여 코드 리뷰 밖에서 즉각적으로 이야기할 수 있도록 하자. 이는 코드 리뷰가 정체되는 일을 막아줄 것이다.
Build together!
그럼 코드 리뷰는 과연 누구에게 맡겨야 할까? 발표자는 다음과 같은 사람이 적합하다고 말한다.
- who has context
- who has skills
- who cares deeply
- who should learn this
나는 회사에서 거의 모든 PR 리뷰에 참여하고 있다. 절대 내가 많이 알고 잘해서가 아니다. 비록 시간과 노력이 많이 드는 작업이지만 나는 다음과 같은 이유로 참여한다.
- 코드 작성자가 미처 챙기지 못한 디테일을 보완하기 위해
- 작성자가 생각하지 못한 예외 케이스를 같이 고민하기 위해
- 작성자의 작업 내용을 이해하기 위해
- 나중에 내가 해당 코드를 이용하거나 고칠 수 있도록 이해하기 위해
- 작성자의 고민과 그 결과물을 얕지만 빠르게 습득하기 위해
Summary
영상에서는 다음과 같이 정리하며 발표를 마무리한다.
- Keep PRs small
- Share drafts early
- Focus on the work, not the person
- Offer actionable Feedback
- Pick the right people
이런 발표 자리에서는 기술적인 내용이 주로 이야기되는데 이런 주제의 내용도 신선하고 재밌는 것 같다.
혼자 가면 빨리 갈 수 있지만, 같이 가면 멀리 갈 수 있다.
나를 비롯한 우리 팀원들이 제일 좋아하는 문장이다. 개발은 혼자보다 같이 할 때 진정한 가치와 의미를 가지는 것 같다. 좋은 문화를 통해 협업이 더 재밌고 유익하기를 바란다.
- Total
- Today
- Yesterday