코드 리뷰, 그 냉정과 열정 사이 (3) - 코드 리뷰의 목적

   앞선 코드 리뷰 글에서처럼 코드 리뷰의 목적에 대해서 요즘 생각해 보았다. 하기는 개인적으로 내가 코드 리뷰를 받으면서 얻고자 기대하는 사항이다.

1) 내가 작성한 코드의 잠재적인 결함에 대한 발견
2) 내가 작성한 코드보다 더 좋은 방법이 있는지에 대한 조언 (구조, 성능, 재사용성, 가독성 등)

  그런데 사실 코드 리뷰를 받으면서 혹은 하면서, SW 품질의 가시적인 가치와 직결되는 1번 사항에 대한 조언을 받기나 하기가 쉽지가 않다. 그 이유는 변경된 코드의 잠재적인 결함을 코드 리뷰를 통해 발견하려면 코드 리뷰를 하기 전에 리뷰어가

1) 변경된 코드를 포함하는 해당 기능 코드에 대해서 파악이 잘되어 있어야 하며
2) 해당 코드가 나오게 된 이유인, 즉 변경된 스펙의 내용과 목적에 대해서 잘 파악하고 있어야 하기 때문이다.

  사실 나에게 주어진 업무 개발하기도 바뻐 죽겠는데, 코드 리뷰 해주기 전에 위의 2가지를 준비하고 들어가는 사람이 어디있겠는가....  코드 인스펙션 만큼은 아니더라도 그에 버금가는 시간과 노력이 들어갈텐데 말이다. 그래서 코드 리뷰를 할 때 내가 원하는 바를 얻기 위해서 하기 원칙을 정하고 그에 맞춰서 코드 리뷰를 하기로 정했다.

1) 내가 코드 리뷰 받을 때, 잠재적인 결함 발견에 1차적인 목적을 둔다면 반드시 아키텍쳐+기능 리더들을 리뷰어로 초대한다.

2) 내가 리뷰어로 초대 된다면 major change의 경우 아키텍쳐를 같이 리뷰어로 초대해달라고 요구한다.

3) 내가 코드 리뷰 받을 때, 변경된 스펙의 내용과 왜 바뀌었는지에 대한 이유를 리뷰어에게 상세히 설명한다.

4) 내가 리뷰어로 코드 리뷰에 초대 된다면 해당 내용을 자세히 설명해 달라고 요청한다.

  사실 나는 코드 리뷰의 1차 목적은 가시적인 SW 품질의 향상, 즉 잠재적인 버그의 발견이라고 생각한다. 하지만 코드 리뷰의 목적을 오직 그것 뿐이라고 생각하고 코드 리뷰를 수행하게 되면 현실에서는 어려움에 봉착 할 수 도 있는데....

  왜냐하면 사람들은 보통 자신의 잘못이 드러나는 것을 꺼려하고 두려워하기 때문에, 코드 리뷰에서 자신이 작성한 코드에 잠재적인 결함이 있다는 것이 발견되는 순간....사실 기분이 썩 그렇게 좋지는 않기 때문이다 ㅋㅋ.  우리 회사 과장중 한분은 코드 리뷰 받으면 벌거벗겨진 느낌이 든다고했다 ㅋㅋ 그 느낌이 뭔지 잘 알거같다 ㅋㅋ

  내가 작성한 코드를 리뷰 받을 때 정말 받고 싶은 피드백이 "내가 미처 생각하지 못한 버그"를 발견하는 것이지만, 또 실제 그러한 피드백을 받으면 기분이 썩 그렇게 좋지 많은 않다는 사실 ㅋㅋ, 나 너무 이중적인거니? ㅋㅋ

<이건 뭐 골룸도 아니고... 코드 리뷰에서, 내 코드의 버그가 발견됐을 때의 이중적인 나의 마음 ㅋㅋ>

  그래서 코드 리뷰의 목적을 결함 발견으로만 한정지어 접근한다면, 결국 현실에서 코드 리뷰를 향한 사람들의 저항과 반감이 클 것이다 (감정적인 이유로 인하여). 코드 리뷰를 이제 막 조직에 도입하려고 한다면 결함의 발견만을 강조하여 도입하려는 것은 독이 될 수도 있겠다는 생각이 든다.
  코드 리뷰의 목적과 이점에 대해서 검색을 통해서 여러 가지 좋은 글들을 많이 보았는데 (지식 전달과 공유, 협업 등). 결국 그것들을 종합해보면 (그리고 '임베디드 C를 위한 TDD' 책에 나온 말을 빌리자면) 하기가 코드 리뷰의 진정한 목적이 아닐까 싶다.

내가 생각하는 코드 리뷰의 목적 - " SW 코드의 가시적/비가시적인 품질 향상"
(1) SW의 가시적인 품질 - 의도한 바대로 잘 동작하는가?
(2) SW의 비가시적인 품질 - 유지 보수 용이성, 재사용성, 구조

마지막으로 하기는 코드 리뷰에 대한 좋은 가이드 라인을 소개한 글이 있어 첨부한다.

http://flyburi.com/576