1 minute read

Surfing Cat

코드 리뷰를 하는 이유는 간단하다. 결함을 늦게 발견할수록 수정하는 비용이 증가하기 마련인데, 코드 인스펙션과 리뷰는 결함을 초기에 발견해서 수정하는 비용을 낮추기 때문이다.

Four ways to a Practical Code Review 번역’에서 4가지 코드 리뷰 방법을 잘 설명하고 있다. 이 글을 읽어보니 얼마 되지 않은 코드 리뷰 경험은 다 어깨너머 리뷰(Over-the-shoulder)였다. 확실히 문서에 있는 단점들을 그대로 다 느꼈는데, 가장 큰 단점은 실제 결함이 제대로 수정되었는지 검증하기 어렵고 리뷰 진행이 소스 코드를 짠 사람에 좌우된다는 거다. 짝 프로그래밍(Pair Programming)이 가장 확실한 코드 리뷰가 되겠지만, 너무 많은 선행투자 시간 때문에 엄두를 못 내고 있다. 물론 이런 걸 결정할 권한도 없다. 그래서 가장 현실적인 답은 코드 리뷰를 지원하는 툴을 사용하는 게 아닐까 싶다.

nil

웹 서핑 중에 찾은 SmartBear사 제품인 CodeCollaborator. 위 사진처럼 변경 점을 볼 수 있는 건 물론이고 실시간 채팅, 코멘트도 지원한다. 보통 코드 리뷰를 체크인하기 전에 하고 싶어하는데, 이 툴에서는 임시 저장소에 저장해서 다른 프로그래머가 코드 리뷰를 할 수 있도록 지원한다. 5분짜리 데모가 있는데, 이거 보면 어떤 것인지 단박에 이해할 수 있다.

nil

코드 리뷰 툴을 사용하지 않고 해결하려면 shelve/unshelve를 지원하는 revision control software와 diff 툴을 사용해도 될 것 같다. 이 기능은 바로 메인 저장소에 체크인하는 게 아니라 중간 임시 저장소에 저장하는 건데, 여기서 코드 리뷰를 하고 메인 저장소에 체크인하는 프로세스를 만들면 된다. 특히, Bazaar는 아예 코드가 체크인돼도 되는지 결정하는 gatekeeper를 소프트웨어에서 지원하고 있다.

“진짜 코드 리뷰를 제대로 해보자!”라면 코드 리뷰 툴을 도입하는 게 최선 아닐까? 에이 옆에서 일하는데, 가서 얼굴 보면서 코드 리뷰를 하면 되지 이런 툴까지 사용할 필요가 있을까라고 생각했다. 그런데 생각이 조금 바뀌었다고 할까나. 보통 한다면 어깨너머 리뷰를 할 건데, 시간 소모가 심하고 투자한 시간에 비해 얻는 이득이 별로 없어 보인다. 아니면 Bazaar같이 gatekeeper를 지원하는 툴을 사용하는 건데, GPLv2 라이선스라서 사용하는 데 무리가 없어 보인다. MySQL을 비롯한 Linux 진영에서 많이 사용하고 있다니 믿을만해 보인다. 그래도 너무 낯설어서 선뜻 사용하기는 망설여지는 툴이다.

PS : SmartBear에서 Best Kept Secrets of Peer Code Review란 책을 신청하면 공짜로 보내준다. 우리나라도 무료 배송 국가! 야호.