Kent Beck, 코드 리뷰에 대한 생각

들어가기에 앞서

Kent Beck의 Thinking About Code Review를 번역한 포스팅임을 밝힙니다. 번역에 오류가 있는 경우 댓글로 알려주시면 감사하겠습니다. 

 

---

 

팀 워크플로우에 대해 생각해 보세요. 그런 다음 여러분의 상황에 맞는 방법을 시도해 보세요. 그런 다음 조정하세요. 엔지니어링에서 가장 흥미로운 말은 “알고 보니...”입니다.

 

 

 

최근 트위터에서 pull request에 대한 팀 워크플로우로 한바탕 떠들썩했을 때 제가 언급되었습니다. 코드 리뷰에 대한 또 한 번의 소모적인 논쟁에 참여하고 싶지 않았지만, 결국 이렇게 글을 쓰게 되었네요. 

 

논의를 더 진행하기 전에, 제가 여기서 영업하려는 건 아무것도 없다는 점을 짚고 넘어가고 싶습니다. 여러분이 리뷰를 하든 안하든, 특정 git 명령어를 특정 순서로 실행하든 안 하든, 실제로는 아닌데 여러분의 플로우를 지적 통합(CI)이라고 부르든 안 부르든 제게는 어떤 이득도 손해도 없습니다. 여러분이 '긱(geek)들이 세상에서 안전하다고 느끼도록 돕는다'라는 목표에 따라, 여러분이 각자의 필요에 맞는 방식으로 작업하기만을 바랄 뿐입니다. 

 

해야 할 일들

코드 리뷰는 팀 소프트웨어 개발에 어떤 영향을 미쳐야 할까요? 

• 동작 오류 감소 
• 구조적 결함 감소 
• 팀 이해도 향상
• 학습 촉진 
• 팀 리스크 감소 

 

원칙

동일한 시스템을 여러 사람이 변경하고 있습니다. 어떠한 순서로, 어떤 단위로 작업을 분리해서 작업한 다음 통합해야 할까요? 

 

• 흐름(flow): 다른 모든 조건이 동일하다면, 작은 가치를 더 자주 전달하는 것이 큰 가치를 더 드물게 전달하는 것보다 더 가치 있습니다. 
• 조정(rowing): 우리는 모두 같은 배에 타고 있기 때문에 한 사람이 얼마나 빨리 노를 젓는지가 아니라, 우리가 함께 얼마나 빨리 노를 젓는지가 중요합니다. 
• 오버헤드(overhead): 모든 변경 단위에는 비용이 들기 때문에 가능한 적은 수의 변경 단위를 갖는 게 좋습니다. (네, 이것은 흐름의 원칙과 모순됩니다. 복잡한 문제이기 때문에 우리는 이에 대한 논쟁을 보게 됩니다.)
• 얼라인(alignment): 권한(행동을 취할 수 있는 능력)과 책임(결과가 권력을 향해 흐르는 것)을 일치시킵니다. 
• 통합(intergration): 이 문제는 단순히 '분할 정복'이 아닙니다. '분할하고 정복하고 통합하는 것'입니다. 실수를 포함한 통합의 비용을 고려하세요. 

 

인센티브 

코드 리뷰와 관련해 사람들이 간과하는 점 중 하나는 다양한 스타일에 내재된 인센티브입니다. 예를 들어 PR 모델이 영향을 미치는 역학 관계는 다음과 같습니다. 

 

 

더 큰 PR은 더 긴 시간 지연으로 이어지고, 이는 변경을 만들어내는 더 많은 시간으로 이어지며, 이는 또 다시 더 큰 PR로 이어집니다. (PR을 작게 만드는 억제 루프도 있지만, 이 강화 루프는 여전히 존재합니다.) 

 

모든 강화 루프와 마찬가지로 영향을 미칠 수 있는 지점을 찾아내 이 루프를 역전시킬 수 있습니다. 예를 들어, 리뷰 지연을 줄임으로써 개발에 필요한 '추가' 시간이 줄어들어 더 작은 PR이 생성되고, 이로 인해 지연이 감소합니다. 

 

제가 말하고자 하는 바는 우리가 선택하는 모든 팀 플로우가 하나의 시스템 내에서 작동하며, 그 시스템이 인센티브를 만든다는 것입니다. 원하는 인센티브를 만들고, 잘못된 인센티브를 피할 수 있는 팀 플로우를 선택하세요. 

 

 

변동성 차원 

팀 플로우 측면에서 충분히 다루지 않은 부분은 변동성의 차원입니다. 다음의 두 가지 측면이 있습니다.

- 차단 (blocking)
- 동기식 (synchronous)

하나의 차원은 차단 대 비차단입니다. 리뷰 없이 변경사항이 프로덕션에 적용될 수 있을까요?

이 질문에 대한 답변의 일부는 변경의 가역성입니다. 대부분의 구조 변경과 같이 변경이 가역적이라면 차단의 가치는 줄어듭니다. 마찬가지로 부정적인 동작 변화(또는 '버그')의 가능성이 충분히 낮다면 차단의 가치는 줄어듭니다.

제가 생각하는 두 번째 중요한 차원은 리뷰가 동기식인지 비동기식인지입니다. 변경을 '완료'한 후, 리뷰는 즉시 이루어지나요, 나중에 이루어지나요, 아니면 (페어 프로그래밍과 같은 협업 개발에서처럼) 변경 중에 이루어지나요?

 

저는 오른쪽 하단에 탐색할 가치가 있는 영역이 있다고 생각합니다. 뉴스피드와 비슷하지만, 시스템의 모든 변경사항을 위한 것이 있다면 어떨까요? 당신이 별로 관심이 없는 시스템 부분에 변경이 일어났다면 변경에 대한 높은 수준의 요약을 받을 수 있을 것입니다. 만약 그 변경이 당신이 작업하고 있는 변경과 간섭할 가능성이 있다면, 상세하고 즉각적인 알림을 받게 될 것입니다. (궁금하시다면 이를 구현하기 위한 계획이 있습니다.)

 

결론

여러분의 상황에 맞는 리뷰 스타일을 선택하세요. 필요하다면 새로운 스타일을 만드세요. 오픈소스 PR 모델을 무조건 따라하지 마세요. 생각하세요. 실험해 보세요. 공유하세요.