read

코드리뷰를 대하는 마음가짐에 이어서, 코드 리뷰를 하는 방식에는 어떤 것들이 있는지 알아보려고 한다.

IMAG0297

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 을 제외하면, 코드리뷰 자체가 그리 정형화된 프로세스가 아님을 알 수 있다. 개발 팀의 상황에 맞게 적절한 것들을 가져다 쓰는 지혜가 필요한데, 여기에는 다른 사람이 코드를 봐주는 것이 버그를 찾는 데 도움이 된다 라는 믿음이 필요하다. 즉 내가 못 보는 것을 다른 누군가가 봐 줄 수 있다라는 전제가 되어야 한다.

코드리뷰에 대한 현실성 있는 예를 들기 위해, 마이크로소프트에서 겪었던 코드리뷰에 대한 단상들과 학계에서 밝혀낸 코드리뷰에 대한 이야기들을 다음에 이어서 적어보려고 한다.

References

Blog Logo

Ki Sung Bae


Published

Image

Gsong's Blog

Developer + Entrepreneur = Entreveloper

Back to Overview