안녕하세요? 요즘 바빠서 글을 쓰지 못했습니다.
저희 회사에서는 최근 구글에서 만든 Gerrit이라는 코드리뷰 시스템을 적극 활용하고 있습니다.
GIT과 연동이 잘 되고, Android를 개발하면서 코드리뷰를 시스템화하여 로그를 남기고 메일도 자동발송하여 커뮤니케이션이 자연스럽게 활성화 되도록 유도합니다.
또한 구글이 만든 만큼 속도도 보장합니다.
하지만 이를 위해서는 형상관리를 위해서는 GIT사용이 필수가 되어야 하고 각 App. 파트에서 개별적으로 쓰고 있는 SVN사용자가 불편해 하여 코드리뷰 문화가 정착되지 않는 느낌이 있습니다.
결국 실장님이 적극(강제적으로 ㅎㅎ)쓰도록 유도하라는 지시가 내려가게 되었고, Commit사용량을 조사하여 보고하게 되자, 개발자들은 패치를 잘게 쪼개어 올리고 있습니다 @@;;
역시 개발자들이 쪼임을 피해나가는 방법을 강구하는 것은 막을 수 없습니다. ㅎㅎ
여튼 코드리뷰 문화는 활성화되어 정착되는게 좋겠죠? ^^
이와 관련하여 좋은 글이 있어 링크로 공유합니다.
함께
xper 메일링 리스트에 Min님이 번역하신 글도 같이 올립니다.
http://blogs.atlassian.com/2010/03/code_review_in_agile_teams_part_ii/
* 코드리뷰에 대한 오해
- 버그를 발견하는 것을 보장하진 않는다
- 코드의 결함을 찾는 것이 목적이 아니라, 서로 배우고 가르쳐 주고, 팀의 협업능력을 높여주는 것이어야 한다. (그렇지 않으면 팀이
깨어진다)
* 코드리뷰가 잘 되려면
- 너무 많은 절차와 규칙을 만들지 마라. 절차를 아주아주아주 간단하게 하라
- 강요하지 마라. 대신 Encourage 하라
- 모든 코드 commit 을 리뷰하도록 한다거나 하는 형태로 Micro - Manage 를 하지마라
- 개개인의 작업 흐름을 끊지마라
- 코드리뷰를 통해 발견한 것들을 널리 공유하라
- 코드리뷰를 늦게 하는것은 안하는 것보다 나쁠수 있다. Iteration 에 포함시켜라
- 한꺼번에 덜하기보다는 조금씩 자주하라
- 툴에 얽메이지 마라, 중요한것은 개발자들이 서로 대화를 하고 코드를 공유하는 것이다
- 너무 많은 리뷰어를 참여시키지 마라. 2-4 명이 적당하다
* 어떻게 잘 되고 있는지 알수 있는가
- 쉽진 않다, 사실 필요없을 수도/불가능 할수도 있다, metric 에 집착할 필요는 없다.
- 장기간의 이득은 측정할 수 없지만 많다
- Simple Metric 들이면 충분할 수 있다. (리뷰에 사용된 시간, 리뷰 comment 등).
