Peer Review를 성공하기 위한 요소들
2009/03/27 22:27 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다.
이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발 관련된 산출물들을 다 리뷰를 합니다. 그리고 동료들간에 검토를 해 준다는 것이 중요한 요소입니다.
그럼 Peer Review를 성공하기 위해서는 어떻게 해야 하는지 한번 보죠.
첫째, 개발자들끼리 으쌰으쌰 해서는 성공하기 힘듭니다. 회사에서 정책적으로 Peer Review를 추진해야 합니다. 개발잘들끼리 한번 해보려고 하는 것은 Peer Review를 너무 우습게 본 겁니다. 그냥 시간 좀 내서 서로 리뷰해주면 되지 뭐 그렇게 어려울게 있어? 라고 생각하면 오산이죠. 일단 많은 시간을 빼앗기는 것이 가장 큰 장애물입니다. 처음에는 의욕적으로 시작했다가, 금방 시들해지게 됩니다. 아직 Peer Review가 정착되지 않은 회사에서 개발자들끼리 한번 시도해보는 것은 거의 대부분 실패합니다. 따라서 회사에서는 Peer Review 담당자도 지정을 해주고, 제도와 자원을 지원해야 합니다.
둘째, 개발일정에 Peer Review를 포함해야 합니다. 그러면 더 시간이 오래 걸린다구요? Peer Review가 조금만 정착이되어도 결국은 이것이 훨씬 시간을 더 절약해준다는 것을 알아야 합니다. 테스트 시간이 절약되고, 유지보수 비용이 절약되고, 후배들이 빨리 성장하고 여기저기서 중복된 코드를 만드느라고 헛되이 보낸 시간이 절약됩니다. 이는 너무 뻔한 것이기 때문에 Peer Review가 개발 시간과 비용을 얼마나 절약하는지 증명하라고 하면 허탈하죠.
셋째, Peer Review는 동료와 하는 겁니다. 강사가 학생들을 가르치는 것도 아니고, 고객에게 설명을 하기 위한 것도 아니고, 서로 리뷰를 하면서 결함을 찾는 겁니다. 여기에 집중해야 합니다.
넷째, 자주해야 합니다. 프로세스에 따라서 빡빡하게 진행하기보다는 수시로 동료들과 리뷰를 하는 것이 좋습니다. 언제든지 "이것 좀 봐줘"하면서 부탁을 할 수 있고, 짧은 시간을 내서 흔쾌히 봐주면서 차츰 적응해 가야 합니다. 많은 양을 몰아서 리뷰를 하게 되면, 쉽게 질려서 포기하게 되고, 모든 코드와 문서를 모든 개발자가 다 리뷰를 해야 하는 것은 아니니 수시로 적당한 동료와 리뷰를 하면 좋습니다.
적어도 이 네가지만 지켜도 Peer Review를 지속하는데 약간의 도움은 될 겁니다.
그런데, 왜 Tool에 대한 설명은 없냐구요? Tool이 리뷰를 대신해주지는 않기 때문에 Tool을 그렇게 심각한 요소는 아닙니다. Tool이 도움이 될 수는 있지만, Tool이 없다고 리뷰를 못하지는 않습니다.
위 조건을 보면 일단 첫번째에서 막힐 수 있습니다. 설령 회사차원에서 Peer Review를 시행하더라도, 촉박한 일정에 쫓겨서 쉽게 포기해버리기 일쑤입니다. 이런 상황이라면 Peer Review가 정착하기는 어렵습니다. 회사도 단단한 의지가 없다면 Peer Review를 정착시키는 대단히 어렵습니다.
이렇게 만만한 일이 아니기 때문에 회사의 개발 성숙도에 따라서 적절한 계획이 필요합니다. 처음부터 욕심부리면 금방 포기하게 됩니다.
이미지출처 : Microsoft Office Online
'개발문화' 카테고리의 다른 글
| Peer Review의 방해꾼들 (4) | 2009/04/02 |
|---|---|
| Peer Review의 치명적인 유혹 (4) | 2009/04/01 |
| Peer Review를 성공하기 위한 요소들 (6) | 2009/03/27 |
| 코드리뷰 정착이 어려운 이유 (10) | 2009/03/24 |
| 2009년 새해가 밝았습니다. - 개발자에게도 희망의 한해가 됐으면... (12) | 2009/01/02 |
| 공든 탑을 쌓는 것은 수년, 무너지는 것은 한 순간 (2) | 2008/12/26 |
Trackback Address: http://allofsoftware.net/trackback/101
팀원들의 마인드가 제일 중요하다고 생각됩니다. 서로서로 '내 코드좀 한번 같이 봐줘'라고 할 수있는 마음, 그걸 넘어서 '내가 혼자 만든 코드는 반드시 결함이 있으니 옆사람에게 봐달라고 해야겠다'라는 마음을 가지는 것이 가장 중요하다고 생각됩니다.
헝그리맨님 안녕하세요.
코드리뷰는 잘되고 계신가요? 팀원들이 마인드도 중요하고 회사의 실시 의지도 매우 중요합니다. 회사에서 많이 지원해주시나요?
말씀 하신 부분이 정말 중요하다고 생각합니다.
전 테스터로 일하고 있는데 큰 결함들이 대부분
같은 팀원들끼리도 의사소통이 제대로 이루어지지 않아
공통적인 결함인데도 수정이 일부분에서만 이루어지는 경우가 대부분이고
새로 개발된 부분이 일부분만 적용되는 문제..
그리고 한 모듈, 또는 페이지를 개발하는 개발자가 변경 되는 경우
소스가 초기화 되거나 인수인계가 제대로 안되기도 하는 경우도 봤구요;;;
저도 개발자로 꽤 일했는데
그런것들은 정말 이해가 안된다는;;;
정말 필요하단 생각!
하늘다래님 안녕하세요. 한가지 문제가 아니고 총체적인 문제입니다.
좋은 지식을 공유해 주시는 것에 정말 감사드립니다. 리뷰라는 개발 방식이 어렵게 느껴지는 그 뿌리에는 의사소통이 잘 되지 않는다라는 문제가 있네요. 여하튼 이번 프로젝트에 Code Review를 개발 절차에 포함하여 정착시킬 것 입니다. 저도 시행착오를 겪으면서 일어나는 일들을 공유하겠습니다. 감사합니다.
codeart님 안녕하세요.
첫술에 배부를 수는 없는 법이니 차근 차근 하지만 꾸준히 해나가야 할 것 같습니다. 진행상황 계속 공유해주시면 최대한 도움이 되어 드리고 싶습니다.