Four ways to a Practical Code Review 번역

야심차게 시작했던, 팀 블로그가 더 이상 성장을 멈추고 있다. 안타까운 일이다... 고로... 팀블로그가 없어지기 전에 내 글이라도 하나씩 옮겨야 겠다. ㅋㅋ

실용적인 리뷰에 관한 어떤 기고문을 번역해 보았다. 공식의 리뷰를 통해 얻을 수 있는 효과를 실용적인 방식으로 적용한 사례로 참고해 보자.

Four ways to a Practical Code Review
 
Jason Cohen, Smart Bear Software, http://www.smartbearsoftware.com/

번역: TB

어떻게 대부분의 미팅을 없앨 것인가?

2년전에 나는 10억 달러 규모의 소프트웨어 개발 업체의 CTO와의 초대받지 않은 미팅에 참여했었다. 하지만, 그 방에 들어가기 전에는 그 사실을 몰랐었다. 나는 소프트웨어 프로세스와 메트릭의 총괄 책임자로부터 우리가 성공적으로 하고 있던 새로운 유형의 경량화된 코드 리뷰(a new type of lightweight code review)에 대해 얘기해주러 오라는 요청으로 갔었다.

하지만 그 CTO는 내 존재를 그다지 반가와하지 않음이 분명했다.

"당신도 알다시피", 그가 말했다. "우리는 이미 코드 인스펙션을 하고 있고, 마이클 페이건이 1976년에 개발한 인스펙션과 그의 회사가 어떻게 하는 것인지 우리를 가르치고 있어요." 그의 얼굴은 다음과 같은 결론을 확신하고 있음이 분명했다. "죄송한데 당신은 마이클 페이건이 아니잖아요."

"현재 우리 코드 중 1%가 인스펙트되었어요." (이 미팅을) 요청했던 프로세스/메트릭의 책임자가 주장했다. "우리는 올해 말까지 7%까지 올릴 수 있다고 믿어요." 여기서 미스터 메트릭은 멈추었고, 미스터 CTO를 한 번 쳐다보았다. 그는 얼굴을 떨구었다. 이 이후의 일들이 무엇이던 간에, 그들은 분명히 이런 이야기를 이전에도 한 적이 있었다.

"문제는 우리가 인스펙션을 그것보다 더 할 수 없다는 겁니다. 페이건 인스펙션을 완료하기 위해 주어지는 시간으로는, 우리가 작성한 새로운 코드의 7% 이상을 인스펙션 할만한 시간이 안 된다는 점입니다."

나의 다음 질문은 명확했다. "나머지 93%에 대해서는 어떻게 하실 겁니까?" 그들의 시선은 명백하게 동일했다. 즉, 여기서 나의 역할은 우리가 가지고 있던 답을 그 CTO가 확신하도록 하는 것이었다.

이 이야기는 해피 엔딩으로 끝난다. 하지만, 우리가 그 이야기를 알아보기 전에 나는 대부분의 개발자, 관리자, 프로세스 엔지니어들이 "코드 리뷰" 라는 말을 들었을 때, 인스펙트를 생각하기 때문에, 코드를 "인스펙트" 한다는 것의 의미를 설명하겠다. 이 회사가 자신들의 코드 중 93%의 코드를 리뷰할 수 없었고, 이 아이디어를 왜 개발자들이 싫어하는지에 대한 이유가 이것이다. "리뷰의 관례화"의 의미로 이 개념을 변경시키면 개발자들을 해방시켜서 개발자들이 무겁고 공식적인 인스펙션 프로세스 없이 코드 리뷰의 효과를 볼 수 있게 된다.

마이클 페이건 - 구시대의 아버지

만일 당신이 동료 코드 리뷰(peer code review)에 대해서 아무것이나 읽어 본 적이 있다면, 첫 출간때부터 공식적인 코드 리뷰 시스템으로 명성을 얻은 마이클 페이건을 알 것이다. 그의 기법은 1970년대 중반에 IBM에서 개발되었는데, OS/370 어셈블리 코드의 디자인 스펙과 관련된 여러 종류의 문서에서 결함이 제거되었음을 증명하였다. 오늘날까지 그의 업적과 유사한 기법들은 "코드 인스펙션"이라는 이름으로 불린다.

마음의 준비를 하고...

나는 이제 "코드 인스펙션"을 간략하게 설명할 것이다. 하지만, 마음의 준비를 단단히 하라. 이것은 무거운 프로세스로는 최고이다. 따라서, 나를 용서하기 바란다. 곧 끝날 것을 약속할 수 있다. 코드 인스펙션은 7가지 단계로 구성된다. 계획 단계에서 저자는 산출물들을 모으고, 그것들이 사전에 정의된 진입 기준(pre-defined Entry Criteria)에 부합하는지 확인한다. 그리고, 누가 인스펙션에 참여할 것인지 결정한다. 4가지의 서로 다른 역할을 가진 4명의 참여자가 있다.

저자(Author), 중재자(Moderator), 리뷰어(Reviewer) 그리고 독자(Reader)이다. 종종 관찰자(Observer)도 존재한다. 모든 참여자들은 여러 회의에 우선적으로 초대되어야 한다. 그리고 이러한 회의는 다양한 참석자들과 함께 일정을 수립해야 한다. 첫번째 회의는 저자가 리뷰의 배경, 동기 그리고 목표를 설명하는 소개 단계(Introduction Phase)에서 시작된다. 모든 참여자는 산출물의 인쇄된 복사본을 가진다. (이것이 중요하다. 출력물이 없다면 페이건 인스펙션이 아니다.) 그 참석자들은 다음번 회의의 일정을 수립하고 자리를 떠난다.

산출물들을 각자 개인들이 읽으면서 읽기 단계(Reading Phase)가 시작된다. 하지만, 각각의 역할을 맡은 사람들은 서로 다른 목적으로 읽으며(이것이 중요하다), 아무도 결함을 찾지 않는다. 다음번 회의가 열릴 때 인스펙션 단계(Inspection Phase)가 시작된다. 중재자는 이 회의의 속도를 조절하며 모든 사람들이 자신의 역할을 하고 있는지, 개인적인 공격으로 진행되지 않는지 확인한다. 독자는 산출물을 발표한다. 이는 종종 어느 누군가의 잘못된 이해가 산출물 안에 결함을 가리키기 때문이며, 그의 임무는 "이해를 위해 읽는" 것이기 때문이다.

회의가 진행되면서 저자가 어떤 수정이 필요한지를 알 수 있도록 하기 위해서 결함 로그(Defect Log)가 작성된다. 회의가 끝나기 전에, 참석자들은 이후 프로세스 개선에 도움이 될 수 있는 주의사항들을 정리한다. 만일 결함이 발견되었다면, 그 인스펙션은 저자가 문제들을 수정하는 재작업 단계(Rework Phase)에 진입하고, 이후 수정사항들이 적절하며, 새로운 결함을 야기시키지 않았는지 확인하는 검증 단계(Verification Phase)가 열리게 된다. 최종적으로 그 인스펙션은 완료 단계(Completed Phase)로 진입한다.

그림1: "공식적인" 인스펙션에 대한 전형적인 작업흐름이다. 리뷰에서 생성된 산출물인 결함 로그, 회의 노트, 메트릭 로그 등은 표시하지 않았다. 또 어떤 인스펙션은 이후 후속 회의에 사용하기 위해 마치면서 앙케트 질문서를 제출하기도 한다.

당신은 이제 (몇가지를) 제외시킬 수 있다

좋은 소식은 이것이 잘 작동한다는 점이다. 인스펙션은 결함을 발견하고, 신규 인력의 훈련에 도움이 되고, 프로세스에 대한 식견과 개선을 위해 전체 프로세스는 측정될 수 있다. 만일 당신의 예산이 차고 넘친다면, 심지어 미스터 페이건 그 자신이 당신에게 어떻게 하는 것인지 보여줄 수 있을 것이다. 나쁜 소식은 오늘날의 애자일 방법론에서 명백히 드러난다. 연구 결과는 평균적인 인스펙션에 200 라인 코드당 9명이 1시간동안의 리소스를 투입해야 함을 보여준다. 따라서, 물론 미스터 CTO는 회사에서 변경된 모든 코드에 대해서 이렇게 할 수 없을 것이다.

시간이 지나면서 이 주제에 관한 실험, 케이스 연구, 책이 나왔다. 거의 항상 기본으로 "코드 인스펙션"의 형태가 사용되었다. 지난 20년간의 출판된 실험과 케이스 연구에 대한 우리의 조사에서 그들중 95%는 작은 파일럿 그룹에서만 인스펙션을 시도했으며, 그들의 모든 소프트웨어 개발 프로젝트에 그 기법을 적용한 경우는 없다는 사실을 발견했다.

만일 "애자일"이 할 수 있다면, 왜 우리는 할 수 없는가?

확실히 또 다른 방법이 있다. 페이건 인스펙션은 비즈니스 로직이 어셈블리 언어로 작성되고, "컴퓨터 공학"이 주류가 아니었으며, 공룡들이 지구상을 활보하던 시절에 디자인되었다.

우리가 그 이후로 배운것은 없는가? 3티어 어플리케이션에 있는 객체지향 코드를 읽을 때 또 다른 기법이 필요치 않을까? 해외 주문 개발은 새로운 프로세스가 필요한 도전과제는 아닌가? 애자일 방법론의 득세는 모든 개발자들이 동시에 만족하는 개선, 측정, 메트릭, 프로세스를 가져야 함을 보여주는 것은 아닐까?

따라서 이야기는 이미 끝났다!

이제 당신은 그 이야기의 결말이 어떤지 추측할 수 있을 것이다. 위에 언급된 것과 다르지 않은 논쟁을 사용해서 미스터 메트릭스와 나는 미스터 CTO가 최소한 이미 절망적으로 페이건 인스펙션의 반대에 있는 한 개발 그룹의 파일럿 프로그램에 우리의 경량화된 코드 리뷰 기법을 시도해 보리라는 것을 확신했다. 그 그룹으로부터 도출된 메트릭은 경량화된 시스템의 효율성을 증명했고, 18개월 안에 Code Collaborator가(역자주: 글쓴이의 회사에서 만드는 코드 리뷰를 지원하는 상용툴 이름) 전체 조직들 사이에 배치되었다.

"경량화(lightweight)"가 무엇을 의미하는가?

당신이 코드 리뷰가 좋은 것이지만 무거운(heavyweight) 인스펙션 프로세스는 실용적이지 않다는 논쟁에 참여했다고 가정하면, 다음 질문은 "어떻게 리뷰를 실용적으로 만들 것인가?" 일 것이다.

우리는 4가지 경량화 기법들을 살펴볼 것이다.

1. 어깨 너머 리뷰(Over-the-shoulder): 저자가 코드 사이를 왔다 갔다 할 때 저자의 어깨 너머로 한 개발자가 살펴보는 리뷰.

2. 이메일 회신(Email pass-around): 저자(또는 SCM 시스템)이 리뷰어들에게 코드를 이메일 전송하는 리뷰.

3. 짝 프로그래밍(Pair Programming): 2명의 저자들이 한 대의 머신에서 함께 코드를 개발.

4. 툴 지원(Tool-assisted): 저자와 리뷰어들이 동료 코드 리뷰에 맞게 특별히 고안된 도구를 사용함.

어깨 너머 리뷰

이것은 가장 일반적이고 가장 비공식적인(그리고 가장 쉽다!) 코드 리뷰이다. "어깨 너머" 리뷰는 리뷰어가 코드 변경 내용을 알 수 있도록 저자가 작업하면서 저자의 머신에 서 있는 것이다.

일반적으로, 저자가 키보드와 마우스에 앉아서 리뷰를 "진행"하며, 다양한 파일을 열어, 그가 한 작업을 설명하면서 변경된 부분을 지적해서 보여주는 것이다. 저자는 프로젝트 내의 다른 파일들과 변경 내용들을 왔다 갔다 하면서, 다양한 도구를 사용해 변경한 내용을 보여준다. 만일 리뷰어가 어떤 잘못된 것을 보았다면, 그들은 리뷰어가 이리 저리 살펴보는 동안에 저자가 수정을 하는 "일시적인 짝 프로그래밍"에 몰두한다. 리뷰어가 참여할 필요가 없는 더 큰 변경들은 오프라인의 형태를 취한다.

현대의 데스크톱 공유 소프트웨어가 있으면, 이른바 "어깨 너머 리뷰"는 장거리 간에도 작업이 가능하다. 하지만, 전화를 통해 의사소통하거나 이러한 공유 미팅의 일정계획을 세워야하기 때문에 프로세스가 복잡하게 된다.

 

그림 2: 전형적인 어깨 너머 코드 웍쓰루 프로세스이다. 일반적으로 아무런 리뷰 산출물이 생성되지 않는다.

어깨 너머 리뷰의 가장 명확한 장점은 실행의 단순성이다. 누구나, 언제나, 훈련없이 수행할 수 있다. 또한 특별히 복잡한 변경 내용이나 "안정" 코드 브랜치의 변경 같은, 당신이 (리뷰를) 가장 필요로 할 때마다 적용할 수 있다.

내가 장점과 단점을 언급하기 전에, 이런 종류의 리뷰에서만 드러나는 어떤 효과에 대해서 고려해 보기를 권장한다. 저자가 리뷰의 속도를 조절하기 때문에, 종종 리뷰어가 기여할 기회를 놓치게 된다. 리뷰어에게 코드의 복잡한 부분을 심사숙고할 시간이 충분하게 주어지지 않는 것이다. 리뷰어는 API가 올바르게 사용되었는지 확인하거나 사이드 이펙트의 체크를 위해 다른 소스 파일들을 이리 저리 검토할 기회를 갖지 못한다.

저자는 리뷰어가 코드를 이해하게 하기 위해 설명을 보충할 수 있다. 하지만, 그 코드를 읽는 다음 개발자는 코드 내에 코멘트가 붙어있지 않은 경우 그 설명의 장점을 취하지 못하게 된다. 또한, 리뷰어가 자신을 쳐다보고 있는 동료 개발자와 함께 코드를 이동해 가면서 이러한 이슈들을 인식하고 객관적이 되기는 어렵다.

그래서

* 장점: 실행하기 용이

* 장점: 완료가 빠름

* 장점: 데스크톱 공유나 컨퍼런스 콜을 통해 원격지에서 작업할 수 있음

* 단점: 리뷰어의 리뷰 진행이 저자에 의해 좌우됨

* 단점: 일반적으로 실제 결함이 수정되었는지에 대한 검증이 없음

* 단점: 변경된 파일을 (리뷰하지 않고) 실수로 건너뛰기 쉬움

* 단점: 이 프로세스를 강제하기 불가능함

* 단점: 아무런 메트릭이나 측정, 개선이 없음

이메일 회신 리뷰

이것은 경량화된 코드 리뷰 형태 중에서 두 번째로 가장 일반적인 것이며, 이 기법은 오픈 소스 프로젝트들에서 선호된다. 여기서 전체 파일이나 변경된 파일이 저자에 의해 묶여져서, 리뷰어에게 이메일로 전송된다. 리뷰어는 파일을 검사하고, 저자나 다른 개발자들과 토의하고 질문하며, 변경을 제안한다.

 

그림 3: 이미 버전 제어 시스템에 체크인 된 코드의 이메일 회신 리뷰의 전형적인 프로세스. 이러한 단계들은 현실에서는 명백하지 않은데, 이유는 실제적인 "리뷰" 대상이 없기 때문이다.

이메일 회신 리뷰의 가장 어려운 부분은 리뷰중인 파일을 수집하고 찾는 것이다. 저자의 입장에서는 어떻게 파일들이 모이는지 알아야 한다. 예를 들어, 버전 제어 시스템에 체크인 되기 위해 제안해야 하는 변경 사항의 리뷰가 있다면, 유저는 추가된, 삭제된, 변경된 모든 파일을 식별해서 어딘가에 복사해야 한다. 그런다음, 그 파일들의 이전 버전들을 다운로드 한다(따라서 리뷰어들은 무엇이 변경되었는지 알게 된다). 그리고, 파일들을 정리하면 리뷰어들이 어떤 파일을 어떤 파일과 비교해야 하는지 알게된다. 리뷰어의 입장에서는 리뷰어들이 이메일에서 그러한 파일을 뽑아내야 하고, 서로 간에 차이점을 만들어내야 한다.

버전 제어 시스템은 자동적으로 이메일을 전송해서 이 프로세스를 지원할 수 있다. 자동화는 도움이 되지만, 많은 리뷰 프로세스에서 당신은 체크인 이후가 아닌, 이전에 리뷰를 하기 원할 것이다. 어깨 너머 리뷰와 마찬가지로, 이메일 회신 리뷰는 정말 실행하기 쉽다. 또한 바다 건너 또는 복도를 건너서 작업을 가능하게 한다.

이메일 기반 리뷰의 독특한 장점은 전문가 조언을 받던지 또는 연기된 리뷰를 다시 진행한다던지해서 다른 사람을 대화에 참여시키기 쉽다는 것이다. 어깨 너머 리뷰와 다른 점은, 이메일은 개발자들이 일하는 "지역"에 구애받지 않는다. 리뷰어가 기회가 있을 때마다 리뷰가 진행된다.

이메일 회신 리뷰의 가장 큰 단점은 매우 빨리 읽을 수 없는 거대한 코멘트, 답변, 코드 조각이 되어 버린다는 점이며, 특히 여러 사람들이 코드의 서로 다른 영역의 토론에 와서 서로 이야기하라고 요청받은 경우에 그렇다. 또한 동시에 다중 리뷰를 관리하기도 어렵다. 하이데라바드(Hyderabad)에 있는 한 개발자가 아웃룩을 열었을 때 지난 며칠동안 작업한 서로 다른 3곳의 코드 변경에 대해서 여러 명의 토의가 담긴 25개의 이메일을 받았다고 상상해 보자. 실제로 일을 시작하기 전이더라도 그것을 검토하기 위해 시간이 소요될 것이다.

또 다른 문제는 리뷰가 "완료"되었다는 지표가 없다는 것이다. 이메일은 여러 시간 동안 돌아다닐 수 있다. 모든 사람들의 이야기가 끝나면 리뷰는 완료된다.

그래서

* 장점: 실행하기 쉽다

* 장점: 원격지의 개발자와 일할 수 있다

* 장점: SCM 시스템이 자동적으로 리뷰를 시작할 수 있다

* 장점: 다른 사람의 참여를 요구하기 쉽다

* 장점: 리뷰어에게 방해되지 않는다

* 단점: 일반적으로 실제 결함이 수정되었는지에 대한 검증이 없다

* 단점: 리뷰가 "완료된" 시점을 우리가 어떻게 알 수 있나?

* 단점: 리뷰어가 단순히 그 이메일을 삭제한 경우가 있는지 알기가 불가능하다

* 단점: 아무런 메트릭이나 측정, 개선이 없음

짝 프로그래밍 (리뷰)

대부분의 사람들은 짝 프로그래밍을 XP나 일반적으로 애자일 개발과 관련지어 생각한다. 무엇보다도 먼저, 짝 프로그래밍은 지속적인 코드 리뷰가 통합된 개발 프로세스이다. 짝 프로그래밍은 2명의 개발자가 한 대의 머신에서 한번에 한명씩 코드를 작성하며, 지속적으로 자유 형식의 토론과 리뷰가 이루어지는 것이다.

짝 프로그래밍에 대한 연구 결과는 지식을 서로 공유하고 버그를 발견해내는 데에 매우 효과적임을 보여주었다. 또 어떤 개발자들은 그것을 진정으로 즐기기도 한다. (당신의 개발자들이 행복해 지도록 하는 것이 중요하다는 점을 잊었나?)

짝 프로그래밍이 좋은지 나쁜지 또는 표준적인 리뷰의 보충 성격인지에 대해서는 논쟁의 여지가 있다. 리뷰하는 개발자는 코드에 깊게 관여해서, 깊은 통찰력을 제공하며, 결과적으로 또 다른 구현 방법을 찾아낸다. 한편, 이것은 리뷰어에게 많은 인스펙션 시간을 제공하며, 즉시로 문제에 대한 깊은 통찰을 제공한다. 따라서 이것은 그 리뷰가 더욱 효과적이라는 의미이다. 반면에 이러한 밀접성은 당신이 리뷰어로서 정확하게 원하는 것이 아닐 것이다. 어떤 저자도 자신의 저작에서 모든 오타를 찾아내지는 못한다. 리뷰어가 코드에 가까우면 가까울 수록 한발 물러나서 왜곡되지 않고 참신한 시각에서 비평하지 못하게 된다. 어떤 사람들은 2가지 기법 모두를 제안한다. 즉, 깊은 리뷰를 위해 짝 프로그래밍을 도입하고, 참신한 시각을 위해 후속 표준 리뷰를 도입하는 것이 그것이다. 비록 이것이 실행하는데 개발자의 시간을 많이 소모하지만, 이 기법은 가장 많은 수의 결함을 발견하는 것으로 인식된다. 우리는 현업에서 누구도 이렇게 하는 것을 본 적이 없다.

짝 프로그래밍에 대한 가장 크고 많은 불평은 시간이 너무나 많이 걸린다는 것이다. 대개 한명의 개발자가 며칠 동안의 작업한 변경 내용에 대해서 한 명의 리뷰어가 15-30분 정도의 시간이 걸리는 반면, 짝 프로그래밍에서는 전체 작업 시간을 2명의 개발자가 모두 함께해야 한다.

물론 짝 프로그래밍이 다른 장점도 가지고 있지만, 이것에 대한 완전한 논의는 이 기고의 범위를 벗어난다.

그래서

* 장점: 버그 발견과 지식을 서로 공유하는게 효과적임이 증명됨

* 장점: 리뷰어가 코드에 "바짝 다가서기" 때문에, 상세 리뷰가 가능함

* 장점: 어떤 개발자들은 좋아함

* 단점: 어떤 개발자들은 좋아하지 않음

* 단점: 리뷰어가 한 발 물러나서 문제를 보기에는 코드에 너무 "바짝 다가서" 있다

* 단점: 많은 선행 투자시간이 든다

* 단점: 원격지의 개발자와 작업하지 못한다

* 단점: 아무런 메트릭이나 측정, 개선이 없음

툴에 의해 지원받는 리뷰

이것은 리뷰의 모든 측면에 특화된 도구가 사용되는 어떤 프로세스를 지칭한다. 이러한 측면에는 파일 수집, 파일과 설명의 전송 및 출력, 모든 참여자들 사이에서 발생한 결함, 메트릭 수집, 프로덕트 관리자에 전달, 관리자의 작업흐름의 조절이 해당된다.

"툴 지원"은 오픈 소스 프로젝트, 상용 소프트웨어나 스스로 만든 스크립트를 의미할 수 있다. 어느쪽이든 돈을 의미한다. 당신이 도구를 구입하거나, 주변 사람들에게 만들고 유지보수를 시키면서 보수를 지급하는 것이다. 또한 당신은 도구가 당신이 의도한 작업흐름에 맞는지 확인해야 한다. 다른 방법은 없다.

그러므로, 그 도구의 도입이 가치가 있다면 도입해서 이점을 누리는 것이 좋다. 특히 앞의 여러 리뷰 유형에서 발생한 여러 주요 문제를 해결해야 할 필요가 있는 경우에 그렇다.

자동화된 파일 수집: 우리가 이메일 회신 리뷰에서 논의했듯이, 개발자들은 "내가 변경한 파일"이나 모든 변경된 파일을 수집하는데 걸리는 시간을 기다려서는 안 된다. 이상적으로 그 도구는 버전 제어 시스템에 체크인 되기 전의 변경이나 이후의 변경에 대해서 수집할 수 있어야 한다.

통합 출력: 차이, 코멘트, 결함: 어떤 종류의 리뷰라도 가장 시간이 많이 소모되는 것중 하나가 리뷰어와 개발자들이 특정 파일이나 라인 번호에서의 각각의 대화 내용과 연결되어야 하는 점이다. 도구는 파일과 파일 변경 이전이후의 차이, 대화 내용을 댓글 방식으로 모두 출력해주어야 한다. 누구도 코멘트, 결함, 소스 코드 간의 상호참조에 시간을 허비해서는 안 된다.

자동화된 메트릭 수집: 한편, 정확한 메트릭은 당신의 프로세스를 이해하고, 프로세스를 변경할 때 일어나는 변화들을 측정하게 하는 유일한 방법이다. 반면에, 어떤 개발자도 라인 수 계산 도구를 사용하고 스톱워치를 들고 있으면서 코드 리뷰하는 것을 원하지 않는다. 자동화된 도구가 주요 메트릭을 수집하는 것은 개발자들이 행복하게 되는 유일한 방법이며 (즉, 그들이 부가적인 작업을 하지 않아도 된다), 당신 프로세스에 의미있는 메트릭을 얻는 길이기도 하다. 리뷰 메트릭에 대한 전체적인 논의와 그 의미 (또는 무엇을 의미하지 않는지)는 또 다른 기고에서 언급할 것이다. 하지만, 당신의 도구는 다음 3가지를 최소한 수집해야 한다. kLOC/시간 (인스펙션률), 결함/hour(결함율), 결함/kLOC(결함 밀도).

작업흐름 강제: 거의 모든 유형의 리뷰는 개발자가 모든 코드 변경에 대해서 리뷰를 하는지 안 하는지, 리뷰어가 실제 수정된 결함과 이것이 새로운 결함을 유발하지 않는지 확인하는지 프로덕트 매니저가 모른다는 문제에 직면한다. 도구는 최소한 리포팅 레벨(수동적인 작업흐름 강제) 또는 최대로는 버전 제어 레벨(서버 쪽의 트리거를 가지고)에서 이 작업 흐름을 강제할 수 있어야 한다.

클라이언트와 통합: 어떤 개발자들은 커맨드 라인 도구를 좋아한다. 또 다른 사람들은 IDE나 버전 제어 GUI 클라이언트와 통합될 필요를 느낀다. 관리자들은 무설치 웹 클라이언트와 웹 서버 API를 좋아한다. 도구가 시스템 내에서 데이터를 읽고, 쓰는 여러 방법을 지원하는 것은 중요하다.

만일 당신의 도구가 이러한 요구사항을 만족한다면, 작업 흐름 강제의 문제, 메트릭이 없는 문제, 파일/차이점의 패키징, 전달, 인스펙션에 소모되는 시간의 문제 없이 이메일 회신 리뷰의 장점을 취할 수 있다. (다중의 작업자와 원격 개발자와도, 최소한의 방해로 작업할 수 있는)

툴 지원 리뷰의 장점과 단점을 나열하기는 불가능하다. 왜냐하면, 그런 것들은 도구의 기능에 의존적이기 때문이다. 하지만, 만일 도구가 위의 요구사항들을 만족한다면, 위에 언급된 모든 "단점"들과 싸우는 것이 가능할 것이다.

그래서 내가 무엇을 해야 하나?

위에 언급된 모든 기법들은 유용하며, 사용하지 않은 경우보다 더 나은 코드를 얻을 수 있을 것이다.

당신에게 맞는 것을 고르기 위해서, 리스트의 맨 윗부분에서 시작해서 아래로 내려가며 적용해 보라. 가장 먼저 나오는 것들은 가장 단순하다. 따라서, 당신이 낮은 수준의 적용을 원한다면, 그 곳에서 멈추면 된다. 툴 지원 리뷰는 낮은 수준을 제거할 수 있는 많은 잠재력을 가지고 있다. 하지만, 당신은 시험 기간, 경쟁 분석, 예산 할당 여부의 책임을 져야 할 것이다.

당신이 무엇을 선택하든 간에, 당신의 개발자들은 코드 리뷰가 버그를 찾고, 신규 인력을 교육하며, 정보를 공유하는 최고의 방법이라는 점을 발견하게 될 것이다. 단지 당신이 이러한 기법을 실행하는 것이 그들의 부담을 너무나 가중시켜서 그들이 반발하지 않도록 대책을 마련하라. {끝}