코드리뷰에 시간을 투자하라.

얼마전에 작년 4/4분기에 만든 코드를 리뷰 받느라 거의 3주의 시간을 쏟느라 고생을 좀 했는데, 이와 관련해서 정리를 해보고자 한다.
내일 물론 이 코드리뷰 과정에 대해서 팀 미팅 시간에 이야기를 할 기회가 있을거 같기도 하고 그렇다.

먼저 내 코드를 리뷰한다고 한다면 가장 먼저 드는 생각이, 뭔가 발가벋겨 진다는 생각일 것이다.. 아무리 코드를 잘 짠다고 하더라도 리뷰(검사)를 받는다는 것 자체가 그리 기분좋은 일은 아니다.
그렇지만 좀 쪽팔리더라도 정말 이 과정에서 배울게 너무도 많다는 것은 부정할 수 없다. .

내가 몸 담고 프로젝트의 코드 생산은 아래의 과정을 통하게 된다. .

1. 논문, 그리고 알고리즘을 리서치하고 이에 따른 다양한 시도를 한다.  그리고 이들을 평가하기 위한 퍼포먼스 테스트와 이들 결과가 좋다면 이들을 일주일에 한번정도 공유하는 자리를 가지게 된다.
2. 공유하는 자리에서 팀원들의 의견을 가미해 가면서 점점 퍼포먼스를 올리게 된다.
3. 이런 과정에서 꽤 좋은 퍼포먼스를 얻었다는 판단이 들면, 이를 코드 커밋을 하게 되는데, 이 전에 코드의 대부분의 핵심 알고리즘과 유닛테스트 코드가 이미 완성이 되어 있어야 한다. 나의 경우에는 거의 누더기 같은 코드로 결과만을 보기 위해 작성했다가 추후 고치는데 시간이 더 걸린 경험도 해봤다.  아마 능숙한 사람은 이미 이 단계에서 완성도 높은 코드를 가지고 있을 것이다.
4. 누구한테는 공포의 코드리뷰가 되는 단계다.
5. 그리고 영광의 코드 커밋..

대충 이런 개발단계를 거치게 되는데, 개인적으로 혹독한 코드리뷰를 통해 상당히 코드의 품질을 올릴 수 있었다고 나 자신이 느끼고 있다. 게다가, 다른 사람들의 조언을 듣게되면서 여러 코딩팁이나 핵심 노하우 등을 얻을 수 있었다.
조심성 있는 우리 팀분들은, 코드의 의미가 간단 명료하기를 원한다. 그리고 변수명에 이들의 역할과 의미가 함축되어 표현되기를 바라고 있다. 게다가 쓸데없는 코드를 더더욱이 싫어하며, 제일 싫어하는건 코드에 버그를 야기할 가능성이 있을 때 이다.
뭐 이정도를 지적받았다. ㅜㅜ

“C++ 코딩의 정석“에 나온 코드리뷰의 잇점을 좀더 써보자면….

1. 여러 동료들의 조언을 통해 코드의 질을 높일 수 있다.
2. 버그를 찾아내고, 적절하지 않은 부분이나 호환/확장성 문제를 찾아낼 수 있다.
3. 아이디어를 공유하는 과정에서 보다 나은 디자인을 찾아낼 수 있다.
4. 새로운 팀 동료나 아직 코드에 익숙하지 않은 사람은 보다 빨리 팀의 업무에 익숙해질 수 있다.
5. 팀의 커뮤니티에 도움을 주며, 일관된 목표를 향해 나아갈 수 있게끔 해준다.
6. 서로에 대한 신뢰, 동기 부여, 전문성 확보에 도움이 된다.

나의 입장에서 가장 공감이 가는 부분은 4번이다. 이처럼 대규모의 C++ 프로젝트를 처음 해보는 나로서는 이 코드리뷰를 통해서 무엇보다 소중하고 책에서 결코 얻을 수 없는 노하우를 얻고 있다. 그것도 C++ 베테랑들로부터 말이다.

어쩌면 이 코드리뷰 전 과정이 팀의 상향 평준화를 이루는 첨병역할을 하지 않나 싶다.

흥미로운 사실은, 코드리뷰를 받는 나에게만 이 시간 할당을 해주는게 아니라, 리뷰를 해주는 리뷰어들에게 까지 리뷰에 대한 시간 할당을 해준다는 사실이였다. 리뷰는 시간 날때 해주는것이 아닌, 프로젝트의 한과정으로 여기는 이런 개발문화를 배워야 할거란 생각이 든다. 이런 문화에서의 코드 한줄 한줄이 에플리케이션의 완성도와 안정성을 보장해 준다고 생각한다. 

요런 저런 개발 프로세스와 문화를 경험하다보니, 특정 개발 프로젝트를 바라보는 관점이 많이 변하게 되었다. 예전에는 그 프로젝트에 어떤 능력있는 사람이 있나 없나를 보고 에플리케이션의 미래를 첨쳤다고 한다면, 지금은 프로젝트의 개발 문화를 더 보게 되었다. 정말 잘 만들어진 에플리케이션은 특출난 몇명의 개발자들이 만드는게 아니라 아주 잘 다듬어진 개발문화를 갖춘 조직에서 나온다는 사실을 직접 몸소 경험하고 있는 중이다.