TDD의 아버지, 켄트백이 생각하는 코드리뷰

켄트백은 TDD 및 CI라는 개념을 만들어낸 소프트웨어 엔지니어의 대부라고 할 수 있는 분입니다. 이번에 켄트백이 본인이 생각하는 코드리뷰에 대한 생각을 공유했는데요. 그 생각을 한번 같이 보시죠! ✅ 코드 리뷰가 해주는 일 - 행동에 대한 오류를 줄입니다. - 구조적 오류를 줄입니다. - 팀의 이해도를 높입니다. - 학습을 가속화할 수 있습니다. - 팀의 위험을 줄입니다. ✅ 원칙(Principles) 리뷰의 원칙은 어떻게 되야 할까요? - Flow : 작게 자주 하는 것이, 크걸 적은 빈도로 하는 것보다 가치가 있습니다. - Rowing : 누가 빨리 노를 젓느냐가 아니라 함께 얼마나 빨리 노를 젓느냐가 중요합니다. - Overhead : 비용의 증가를 최소화 해야합니다. - Alignment : 권한과 책임을 적절히 조정해야합니다. - Integration : Divide & Conquer가 아니라, Divide & Conquer & Integration입니다. 통합 비용을 항상 고려하세요. ✅ 인센티브(Incentive) 많은 사람들이 코드 리뷰에서 무시하고 있는데 "인센티브"입니다. PR Size -> Time -> Delay -> PR Size ... PR(Pull Request)가 클수록 지연시간이 길어지고, 변경에 더 많은 시간이 소요되어 PR이 계속 커집니다. 이는 나쁜 인센티브에 속합니다. 반면에, 코드 리뷰를 지연 없이 하게 되면, 개발을 기다리는 여분의 시간도 줄어들고, 집중할 수 있고, 이를 통해 전체적인 PR에 대한 지연이 점점 줄어들게 됩니다. 이런 인센티브 루프를 잘 활용하여 팀의 워크플로우를 만들어야합니다. ✅ 가변성 팀의 워크플로우에서 충분히 고려해야하는 또다른 주제는 "가변성"입니다. 두가지의 가변성이 있습니다. - 블로킹 (Blocking) - 동기식 (Synchronous) 하나는 코드 리뷰가 반드시 수행되어야 하는 블로킹 형태인지, 그렇지 않아도 되는 Non-블로킹 형식인지에 대한 이야기입니다. 다른 하나는 코드 리뷰가 즉각적으로 Pair 프로그래밍처럼 동기적으로 발생하는지, 아니면 비동기적으로 발생하는지에 대한 이야기입니다. 이를 표로 표현하면 | - Blocking Non-Blocking | | ------- ---------- -------------- | | Sync Pairing ? | | Async PR Review | 즉, 비동기적이면서 블로킹형태가 Review고, 비동기적이면서 이 코드가 들어가는 게 블로킹형태인게 PR입니다. 만약에 동기적이면서 블로킹형태라면 Pair 프로그래밍이 될것입니다. 이렇듯, 코드 리뷰에는 다양한 타입이 있고, 팀에 맞는 부분이 있습니다. 각자에 맞는 형태의 팀플로우를 만들거나, 발명하는게 중요합니다. 너무 오픈소스나 모범사항을 복사하지 마십시요.