코드리뷰 2.- 언제 어떤 리뷰 기법을 사용할것인가?

언제 어떤 코드 리뷰 기법을 사용해야 하는가?

 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까?

 코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다.

즉, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다.

인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다.

 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다.

 1차 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍쳐의 큰 틀이 되며, 추후 개발에도 이 아키텍쳐는 크게 변경되지 않는다. (1차 Release 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다.)  그래서 1차 Release후에 정밀 Inspection을 해서 아키텍쳐의 안정성을 검증할 필요가 있다.

 개발 후반의 시스템 테스트는 주로 비기능적인 요건 (성능,안정성등..)에 대한 성능 테스트가 이루어지는 단계이기 때문에, 테스트 시나리오가 미리 잡혀져 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있기 때문에, 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

 인스펙션을 수행하는 주체는 전문 SI 社 Task Force를 운영하여 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체 (네이X)와 같은 업체는 QA 조직내에 자체적으로 인스펙션팀을 운영하는 것을 권장한다. 그외의 일반 업체 (갑)나 기업의 경우 인스펙션팀을 운영하기 보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

 인스펙션의 결정 주체는 주로 PMO(Project Management Office)와 AA (Application Architect) 되는 것이 바람직하다, 대체로 개발 주체 조직 외부에서 인력을 데리고 오고, 여러팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

 팀리뷰

팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다.

일주일에 한번정도, 한시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다.

리뷰는 발표자가 리드를 하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케쥴로 조정을 해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용하여 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management의 Task로 연결이 되어야 한다.

리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해서 반영 내용을 반드시 검증하도록 한다.

 웍쓰루 (WalkThrough)

일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다.

팀리뷰처럼 PL이나 시니어 개발자가 중재를 하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

 Peer Review

신입 개발자 교육이나, 해당 제품이나 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식공유)와 품질 유지를 위해서 유용하다.. 대신 리뷰어의 Task 부담이 가중되기 때문에 (예상하는 것 보다 많이. 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

 요약

	시기	효과	변경에 대한 비용	수행 비용	주체
인스펙션	1차 Release, 시스템 테스트	매우높음	매우 높음	높음	PMO,QA,AA
팀리뷰 ★	매주	높음	보통	보통	PL
웍쓰루	비정기적	낮음	보통	낮음	원하는 개발자
Peer Review	필요한 경우	경우에 따라 높음	낮음	보통	시니어 개발자

 본인의 경험상 팀리뷰가 가장 효과가 높다. Peer Review는 팀원간의 실력 편차가 클 때 탄력적으로 운영하였고, Enterprise System과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍쳐로 인해서 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸떼 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 “내가 만든 코드를 남이 잘못되었다고 이야기 한다.” 입니다.

리뷰의 주요 목적은 결함의 발견과 개선 방안입니다. 흔히 농담 삼아서 “창던지기”라고 이야기 하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하게 됩니다. 그래서 실제로 인스펙션을 해보게 되면 개발자는 인터뷰를 당하는 것에 대해 취조 당하는 느낌을 가지게 될 수 도 있고 방어적으로 행동할 수 도 있게 됩니다.

 팀리뷰의 경우 감정싸움까지 가는 경우가 허다하지요.

 팀리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신 공격을 받지 않도록 중재하는 기능도 필요합니다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 “사람 사이의 관계”에서 발생되는 일이기 때문에 “문화”의 변화가 필수적입니다.

 또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리가 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이루어져야 합니다.

 경험상으로 팀리뷰가 팀에 자리잡기 위해서는 좋은 리더가 있다하더라도 최소한 1달정도의 (통상 2달) 기간이 필요합니다. 급하게 할일은 아니라는 겁니다.