코드리뷰를 대하는 마음가짐에 이어서, 코드 리뷰를 하는 방식에는 어떤 것들이 있는지 알아보려고 한다.
Peer Reviews in Software 에 나와 있던 도표다. 왼쪽 끝은 제대로 형식을 갖춘 코드 리뷰를 뜻하고, 오른쪽 끝은 그 반대이다. 왼쪽부터 순서대로 적어보면,
- Inspection
- Team review
- Walkthrough
- Pair programming
- Peer deskcheck, passaround
- Ad-hoc review
이다. 사실 이 여러 종류의 코드 리뷰가 이렇게 일렬로 줄 세울 수 있는 성질의 것은 아니다. Inspection 이 formality 의 측면에서 한 쪽 극단에 있는 것은 맞지만, 오른쪽 편의 것들은 무엇을 기준으로 보느냐에 따라 순서가 조금씩 바뀔 수도 있다.
Inspection
코드 검사로 번역이 되는 것 같은데, 아주 엄격한 코드 리뷰를 말한다. 그 단계가 나눠져 있고, 리뷰는 미팅을 소집하여 진행한다. 미팅 진행을 위한 역할들이 정해져 있다. 예를 들어 코드를 쓴 사람, 즉 Author 는 자리에 참석하여 듣기만 하거나, 여러 리뷰어들의 질문을 받는다. 그리고 Moderator 는 리뷰 미팅을 진행하는 역할을 하며, 회의의 결과로 무엇을 얻어야 하는지 이해하는 사람이다. Reader 는 코드를 대표하여 읽는 사람이다. 모든 참가자들이 코드를 읽고 들어오되, 리뷰미팅에 참가한 사람들은 Reader 가 읽는 생각의 흐름을 따라간다. 그리고 Recorder 는 회의에서 나온 이슈들을 기록하여 추적한다.
Team review
팀리뷰는 Inspection 의 경량화 버전이다. 리뷰할 것을 미리 받은 다음, 팀원 각자가 리뷰를 한다. Inspection 의 순서를 따르기는 하는데, 많은 것들이 생략되거나 합쳐져서 진행하게 된다. Author 가 팀 리뷰 미팅을 진행하고, reader 가 없는 대신 참가자들한테 작은 코드 chunk 들을 각각 설명하게 한다. moderator 가 각 리뷰어들에게 이슈가 있는지 확인하고 추적한다.
Walkthrough
코드를 쓴 사람이 동료들을 모아서 코드 흐름을 설명하는 informal 한 리뷰의 종류다. Author 가 리뷰 미팅을 좌우한다는 점에서 Inspection 과 다르다. 그리고 inspection 에서 정의된 프로세스를 따르지도 않는다. Author 가 자신이 만든 코드의 흐름, 구조, 어떤 작업을 하는지, input 과 output 은 무엇인지 등을 설명한다. Walkthrough 의 주 목표는 문제점을 찾는 것이 첫째고, 둘째는 코드에 대한 공통적인 이해를 하는 것이다. 그래서 Walkthrough 는 코드에 대해 다른 사람을 이해시키고자 할 때 적절하다.
Pair programming
페어프로그래밍은 엄밀하게 말하면 코드리뷰의 한 종류가 아니라, 개발방법의 하나에 속한다. 굳이 코드리뷰로 본다치면, 미리 준비할 것이 없고, 리뷰를 위한 프로세스가 존재하지 않으니 informal review 라고 봐도 될 것이다. 페어프로그래밍은 협동과 코드에 대한 공유를 통한 주인 의식 등을 키우는 데 효과적이다. 그러나 페어프로그래밍은 개발 문화의 상당히 큰 변화를 필요로 하므로, 이미 있던 코드리뷰 방식을 단순히 대체할 수 있는 성질의 것은 아니라고 본다.
Peer deskcheck, passaround
Deskcheck 이라는 말은 IT 의 초창기 시절에, 컴퓨터에 실행해보기 전, hard copy 된 프로그램 소스를 책상에서 다시 한번 체크해 보는 데서 비롯된 말이라고 한다. 그러니까 이것은 동료들과 하는 것이 아니라, 혼자서 하는 것이다. 하드카피를 보는 게 무슨 효과가 있으랴 하겠지만, 꼼꼼히 수행하는 deskcheck 은 직접 모니터에서 코드를 열고 보는 것보다 더 많은 버그를 찾아 낼 수 있다. Peer deskcheck 은 Author 외에 한번에 한 사람만 리뷰를 한다. 그래서, 리뷰어의 개인 기량에 의존하게 되는 면이 없잖아 있다. 이것을 한 사람씩 돌아가면서 회람하면 passaround 가 된다.
Ad-hoc review
프로그래머가 원할 때 부탁해서 진행되는 리뷰를 이야기한다. 어떤 형식도 프로세스도 없다. 다른 프로그래머의 호의에 의해 진행되면, 버그를 보는 새로운 시각을 제공해줘서 Author 로 하여금 에러들을 찾을 수 있게 해준다.
In Reality
여기까지 쓴 내용은 언급한 책에 나왔던 것을 요약한 것이고, 현실에서는 어떨까? Inspection 을 제외하고 나머지 방식은 수시로 상황에 맞춰 일어난다. 마이크로소프트에서 일할 때 겪었던 코드 리뷰는 e-mail 을 기반으로 해서 이뤄지며, peer deskcheck 과 Team review 의 성향을 동시에 지니고 있었다. 때로 코드 체인지가 클 때면 walkthrough 자리를 마련해야 하는 경우도 있었다.
Conclusion
Inspection 처럼 엄격한 프로세스를 지키는 경우는 소프트웨어 버그가 고객에게 치명적이 결과를 가져올 경우이다. 그 외에 소프트웨어 품질을 높이고자 하는 목적이라면, Team review 나 Peer deskcheck 정도로도 충분하다. Pair programming 또한 좋은 방법이지만, 이것을 실행하기 위해서는 개발 문화를 바꾸려는 노력이 필요하며, 여기에는 CEO 등의 결정권자의 의지가 따른다.
Inspection 을 제외하면, 코드리뷰 자체가 그리 정형화된 프로세스가 아님을 알 수 있다. 개발 팀의 상황에 맞게 적절한 것들을 가져다 쓰는 지혜가 필요한데, 여기에는 다른 사람이 코드를 봐주는 것이 버그를 찾는 데 도움이 된다 라는 믿음이 필요하다. 즉 내가 못 보는 것을 다른 누군가가 봐 줄 수 있다라는 전제가 되어야 한다.
코드리뷰에 대한 현실성 있는 예를 들기 위해, 마이크로소프트에서 겪었던 코드리뷰에 대한 단상들과 학계에서 밝혀낸 코드리뷰에 대한 이야기들을 다음에 이어서 적어보려고 한다.