사내 테크톡에서 발표한 내용을 블로그에 정리하여 올립니다.
(이전 코드리뷰 포스팅에서 내용을 몇가지 보강하였습니다)
들어가기에 앞서
- 얘기하고자하는 내용은 정답이 아니라 세미나, 블로그와 같은 여러 외부 정보와 개인적인 경험과 여러 토대로 빚어진 의견과 관점이고,
팀마다 상황이 다르고 조직마다 지향하는 바가 다르기에 상황에 맞게 적절한 전략으로 코드리뷰를 진행하는 것이 좋다고 생각합니다 :) - "너는 이거 다 잘 따르고있냐?"면 아니지만 적어도 모르고 안 행하기보다는 알지만 못 행하는게 낫다는 생각에 이번 발표를 준비하였습니다.
왜 코드리뷰를 하는걸까?
피쳐 쳐내느라고 바빠 죽겠는데 왜 코드리뷰를 하는걸까요?
코드 품질
- 코드의 성능, 가독성을 증가시키기 위해서
- 팀 코드 스타일의 일관성 유지시키기 위해서
- 버그가 될 수 있는 부분을 사전에 파악하기 위해서
- 코드리뷰를 통해서 리뷰어가 리뷰이가 알지 못하는 도메인 히스토리를 공유해주거나,
반대로 리뷰이가 리뷰어들에게 도메인 히스토리를 공유해줄 수 있음 - 히스토리 공유를 통해 직/간접적으로 연관된 도메인으로 인해 버그가 될 수 있는 부분을 사전에 파악할 수도 있다.
- 코드리뷰를 통해서 리뷰어가 리뷰이가 알지 못하는 도메인 히스토리를 공유해주거나,
공유
- 새로운 feature 코드와 아키텍처를 다른 개발자들도 알기위해서
- 작업한 사람을 탓하지 않기 위해서 (책임을 분배하기 위해서)
- ⭐️ 서로의 코드를 통해 배우기 위해서 (*개인적으로 코드리뷰라는 프로세스에서 가장 이득인 부분이라고 생각합니다)
- 기술적인 지식과 노하우 공유
- 다른 해결 방법 제시
⭐️ 서로의 코드를 통해 배우기 : 리뷰어를 통해 배우기
- 리뷰어가 리뷰이에게 더 좋은 방식이나 새로운 지식을 전해줄 수 있다.
⭐️ 서로의 코드를 통해 배우기 : 리뷰이를 통해 배우기
- 반대로 리뷰어가 리뷰이의 코드를 보고 새로운 지식을 배울 수 있다.
코드리뷰가 단순히 작업한 코드를 체크하는 업무의 과정 중 하나가 아니라
더 좋은 소프트웨어를 개발하기 위한 서로의 노력과 소통의 과정이라고 생각하면 좋을 것 같습니다 :)
코드리뷰, 어떻게 하면 좋을까?
똑같은 일이라도 하는 방법에 따라 그 효용성이 증대되기도하고, 오히려 안하느니만 못하기도 합니다.
어떻게 하면 코드리뷰의 효율성이 늘어날까요?
리뷰이의 입장에서
리뷰어의 허들을 낮춰줘야한다: 리뷰를 하는 입장에서 "리뷰"라는 행위가 힘든 일이 되면 안된다.
리뷰가 힘들다는건 그만큼 리뷰의 퀄리티가 높아지기 힘들다는 얘기가 되기도 합니다.
- 어떤(What) 작업을 왜(Why) 하였고, 어떻게(How) 하였는지에
대해 충분히 context를 전달해준다.- context를 알면 코드를 이해하고 리뷰를 해주기가 편해진다.
- Github Template, PR Label, Jira issue card 등을 활용한다.
- 필요하다면 코드에 대한 의사결정 과정이나 설명의 코멘트를 단다.
- 특히 어쩔 수 없이 복잡한 코드나 성능을 포기한 코드를
작성하였을 때 도움이 된다.
- 특히 어쩔 수 없이 복잡한 코드나 성능을 포기한 코드를
같이 보면 좋은 글
코드 리뷰 in 뱅크샐러드 개발 문화 - 저 문맥(Low Context) 커뮤니케이션을 지향하는 문화
- 변화를 너무 크게 하지 않는다 (e.g. 뱅크샐러드 모든 PR은 200~300줄 이내)
- 거대한 코드를 리뷰하게 되면 리뷰할 코드를 처음보는 리뷰어의 인지부하가 높아지게되고
그로인해 리뷰어가 리뷰하는 시간이 길어지며 집중도도 떨어진다.- 이로인해 리뷰 퀄리티가 낮아지게된다.
- 더 안좋은 케이스로는 버그의 가능성을 놓치기 쉬워진다.
- 빠른 리뷰가 가능해진다.
- 리뷰 대기로 인한 업무 병목이 해소될 수 있다.
- 리뷰어는 쉽게 리뷰할 수 있어서 편하고, 리뷰이는 빨리 피드백을 들을 수 있어서 서로 편하다.
- 부득이하게 코드 변경이 큰 경우 따로 미팅을 통해 해당 작업에 대한 충분한 context를 설명한다.
- 코드 작업을 하기 전에 아키텍처 리뷰를 하거나 ADR을 남겨놓으면 도움이 된다.
- 거대한 코드를 리뷰하게 되면 리뷰할 코드를 처음보는 리뷰어의 인지부하가 높아지게되고
같이 보면 좋은 글
Google Engineering Practices Documentation - Small CLs (*이 주제에 대해 심도있고 다양한 내용이 있으니 꼭 보시길 추천합니다)
Smartbear - Best Practices for Code Review
코드 리뷰 in 뱅크샐러드 개발 문화 - 작은 PR 규칙
- commit 의 단위를 잘 나누고 message를 잘 작성하도록 한다.
- 리뷰어가 결과적으로 변경된 코드 결과물만 보면 어떤 식으로 작업했는지 파악하기가 힘들다.
- commit의 단위를 잘 나눴으면 commit history를 통해 어떤 식으로 작업을 했는지
진행 과정을 살펴보고 코드를 이해하기가 편해진다.- 1 PR - 1 commit 지양
같이 보면 좋은 글
리뷰어의 입장에서
리뷰는 쌍방향으로 이뤄지는 소통의 과정입니다. 리뷰이 뿐만 아니라 리뷰어 역시 더 좋은 코드리뷰 프로세스를 위해 노력해야합니다.
의견에 대한 논거가 충분해야한다.
- 객관적인 사실이 개인의 선호도보다 우선시 되어야한다.
- 단순히 변경을 원한다는 코멘트보다는, 정당한 논거를 기반으로 변경에 대한 제안을 해야한다.
리뷰는 최대한 빨리 해주는 것이 좋다 (가능하다면 늦어도 당일 내에)
- 리뷰를 기다리는 동안 해당 작업은 blocked 상태가 되기 때문에 빠르게 피드백을 준다.
- 그렇다고 하는 일에 손을 놓고 바로 리뷰를 하는 것도 항상 좋은 것은 아니다 (컨텍스트 스위칭 비용 고려)
- 사정 상 리뷰가 늦는 경우 언제 리뷰가 가능한지에 대한 피드백을 주어야한다.
- 혹은 도저히 리뷰해줄 수 있는 상황이 아니라면 구두로 작업에 대해 듣고 approve라도 한다.
- 단, 팀/조직이 코드 리뷰로 인한 리소스 사용을 충분히 이해하고 인지해야한다.
- 리뷰가 지속적으로 늦어진다면 개발 조직적으로 병목을 확인하고 개선 할수 있는 여지를 확인해야한다.
같이 보면 좋은 글
Google Engineering Practices Documentation - Speed of Code Reviews
리뷰 시 해당 코멘트의 강조 여부를 알려주는 것이 좋다.
- 리뷰이 입장에서는 이 코멘트가 중요한 건지 그냥 지나가다가 하는 말인지 잘 모를 수도 있다.
- 리뷰이가 코멘트를 보면서 더 집중할 코멘트를 알려주면 피드백을 반영하는 것도 빨라진다.
더 좋은 코드리뷰 프로세스를 위해서
왜 하면 좋고 어떻게 하면 좋을지는 알겠는데 실제로는 코드리뷰를 하는게 쉽지가 않은 것 같습니다…
코드리뷰 프로세스를 좀 더 개선시킬 수 있는 방법은 없을까요?
Do
코드 리뷰 역시 communication이다
- 코드 리뷰 이전에 대화에 있어 기본적인 에티켓을 지켜야한다.
- 코드 리뷰 자체가 부담이 되고 하기 싫은 일이 되는건 최대한 지양해야할 상황이다.
- 동료로서 Reviewer의 좋은 코드에 대해서 칭찬을 해주는 것도 중요하다.
- 서로 생각과 지식의 차이를 인정하고 이에 대해 건강한 피드백과 좋은 타협점을 내도록 해야한다.
같이 보면 좋은 글
CSS Tricks - Code Review Etiquette
Microsoft devblog - How We Do Code Review # Watch your tone
Google Engineering Practices Documentation - How to write code review comments
기술 업계의 독성 말투 문제, 고칩시다!
IDE 통합 기능을 활용한다.
- IntelliJ, VSCode와 같은 IDE에서는 Pull Request 관련 통합 기능/플러그인을 제공한다.
- Pull Request가 올라온 IDE를 통해 로컬에서 코드를 직접 실행하면서, 버그가 날 수 있는 부분이나 동작 방식이 애매한 부분을 확인할 수 있다.
Pull Request 알림을 설정한다.
- Github을 가입한 메일로 PR 관련 메일이 오긴하지만 메일을 오매불망 확인할 수도 없는 노릇…
- Slack과 같은 메신저에 통합하면 PR 관련 알림을 메세지로 바로바로 받을 수 있다.
- https://github.com/integrations/slack
- Slack에서 Github을 연동하면, Github PR에서의 유저 mention을 포함하여 코멘트를 달면
Slack에 메세지에는 Slack 유저 mention으로 변경된 코멘트가 보인다.
Pull Request Reminder
- Pull Request 알림을 설정했어도 리뷰를 못 확인해줄 때… 주기적으로 PR 확인을 요청할 수 있다.
Test Code
- Test code를 통해 기능을 수행했을 때 이에 대한 기대값을 보여주면 해당 코드에 대한 사용법을 알기 편하다.
- 테스트 코드를 기능에 대한 명세서라고 생각할 수 있다.
- 그렇기 때문에 테스트 코드의 가독성 또한 중요하다.
Don't
Coding convention, style, test 코드 정상 작동 여부를 리뷰한다 (Nit-Picking)
- 자동화 할 수 있는 것들은 되도록이면 git hooks, github actions, linter, static analysis tool을 통해 자동화한다.
- linter가 too much한 상황인 경우, IDE에서 코드 저장 시 자동 formatting 설정을 해주는 것도 좋다.
- 다만 내가 작업한 코드 외에 코드 변경이 적용되지 않게 하는 것도 중요하다.
늘어지는 코드리뷰
- 하나의 리뷰에 대해 코멘트 핑퐁이 길어지는 경우
- 설계에 대한 합의나 context 전달이 덜 된채로 코멘트가 계속 오가면 차라리 오프라인으로 관련 리뷰 시간을 갖는 편이 좋다.
- 그렇기 때문에 context 공유 및 합의가 명확히 이뤄지지 않은 부분에 대한 Pull Request는 지양하는 편이 좋다.
- 코드 작업 전에 Architecture Review나 planning 공유를 미리 진행한다.
교착상태
- 리뷰이는 피드백을 반영하지 않고, 리뷰어는 PR을 approve 하지 않는 상태이다.
- 반드시 피해야하는 상황이며 매니저의 중재가 필요할 수 있다.
같이 보면 좋은 글
Oracle Java Magazine - Five Code Review Antipatterns
Dzone - Manual Code Review Anti-Patterns
아무리 좋은 이론과 방법론이어도 자기 자신과 조직에 잘 안착되지 않으면 큰 의미가 없습니다.
다 같이 노력하면서 개선시키면서 우리만의 문화를 나가면 좋겠습니다!
'ETC' 카테고리의 다른 글
| [Tips] 내가 쓰는 툴 (Mac) (3) | 2023.12.08 |
|---|---|
| [Github] 텍스트를 링크로 변경하기 - Autolink references (0) | 2023.09.10 |
| [Tools] Video CC Translator - 영상 자막 번역 Chrome 확장프로그램 (0) | 2022.12.26 |
| [Bash] &&를 쓰는 이유 (3) | 2022.11.28 |
| [Refactoring] 여러 역할을 갖는 엔티티 리팩터링하기 (2) | 2022.11.16 |
댓글