들어가기에 앞서서.
소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다.
코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다.
코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정”을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드리뷰 기법일 수 록, Defect의 발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 Defect의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 주니어 개발자에게로의 지식 전달등의 부가적인 목적들도 함께 가지고 있다.
코드 리뷰 스펙트럼
코드 리뷰의 기법을
나누는 방법은 크게, 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수
있고, Offline에서 직접 커뮤니케이션을 하느냐? 또는
메신져,Email 이나 기타 자동화된 코드리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로
나눌 수 있다.
먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다.
주) 코드리뷰 기법중에는 Pair Programming이 종종 언급되고는 하지만, 본인의 사견상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용한다는 것은 매우 어렵다고 판단하기 때문에, 코드 리뷰 스펙트럼에서는 제외한다.
코드 인스펙션
코드리뷰 기법중에서 가장 정형화된 패턴의 기법이다.전문화된 코드리뷰팀이 시스템이 어느정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다.인스펙션팀은 크게 4가지 역할을 가지고 구성이 된다.
1. Moderator
는 인스펙션팀의 실제적인 메니져로 생각하면 된다. 인스펙션팀과 그 대상이 되는 코드를 작성한
개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다.
또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다.
예를 들면, 인스펙션팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게
짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청하여 담당 개발자를 섭외하거나 소프트웨어
설계 문서등을 받아다가 인스펙션팀에 전달한다.
또는 인스펙션된 결과에 대해서 테스트가 필요할 때, 테스팅 환경을 확보하고 인원 (DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션
미팅을 주선하고 주최하는 역할도 갖는다.
가장 중요한 역할중의 하나는 인스펙션이 언제 끝날 것인지 (Exit Criteria)를 정의하는
역할을 갖는다.
2. Reader
Reader는 각종 산출물들을 읽고, 인터뷰등을 통해서 전체 시스템을 이해하여 인스펙션팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해서 팀내에서 가장 많은 도메인 지식을 갖는 사람이다.
Reader는 시스템의 큰 흐름과 구조를 잘 이해하고
있어야 하고, 상황에 따라서 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라서 인스펙션을 진행하게
된다.
3. Designer/Coder
Designer나 Coder는 Reader가 지시한 방향에 따라서 코드를 검증하고 잠재적인 Defect의 발견 및 권장 수정 방안을 만들어 낸다.
4. Tester
Tester는 인스펙션이 진행중인 모듈에 대해서 테스트를 수행하고 Defect를 찾아내는 역할을 수행하며, 이외에 Designer나 Coder가 권장한 수정 코드안에 대한 검증과, 실제 업무 개발자가 수정해온 코드에 대한 검증 작업을 수행한다.
4가지 역할을 가지고 인스펙션은 다음 6단계로 진행된다.
1. Planning
전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건 (금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건, 등등). 그리고 인스펙션 팀이 이때 SET UP이 된다.
2. Overview
이 단계에서는 인스펙션 팀에 시스템과 구성 제품등에 대한 교육이 이루어지고, 팀원간의 역할이
정의된다.
3. Preparation
Inspection을 하기 위한 사전
준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는
필요에 따라서 Tool (테스팅 툴이나, profiler,
Application Performance Monitoring 도구..)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축한다.)
4. Meeting
(Inspection)
각자의 역할에 따라서 Inspection을 수행한다.
Inspection을 통해서 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실업무 개발자에게 전달되어 FIX되도록 하고, 필요에 따라서는 권장 수정안을 전달하기도 한다.
5. Rework
보고된 Defect를 수정한다.
6. Follow-up
보고된 모든 Defect가 수정되었는지 확인한다.
팀리뷰는 코드 인스펙션보다
좀 덜 정형화 되었지만 그래도 일정한 계획과 프로세스를 따른다.
코드 인스펙션 프로세스의 단계 (Planning ,Overview ,Preparation등의 사전 준비 단계는 생략된다.) 역할은 중복되거나 생략될 수 있는데, 발표자(Author)와 Moderator는 필수적으로 구성된다.
리뷰시간에는 발표자(코드를 만든 사람)가 코드에 대한 설명을 하고, 팀원은 결함이나 개선안을 찾는다.
Moderator는 리뷰의 주제를 선정하여 리뷰를 진행하고, 리뷰에서
나온 의견을 정리해서 Action Item으로 기록한다. 이 Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로
관리해야 한다. (일정에 반영되어야 한다.)
Moderator는 프로젝트 관리자 (PM이나 PL)이 될 수도 있으나, 팀내에서 기술적인 실력이 가장 좋은 Senior 개발자가 그 역할을 맏는 것을 권장한다.
일주일에 한번정도 팀리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점 (Short Release) 시점에 수행을 하거나, 테스트 결과를 가지고 리뷰를 하는것도 좋은 방법이 된다.
필자의 경우 프로젝트를
수행할 때, 일주일에 한번 정도 팀리뷰를 진행하였으며, Short
Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해서
팀리뷰를 진행하도록 개발자에게 지시 하였다.
리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 “코드 리뷰 결과” 라는 분류를 따로 만들어서 관리하였고, 각 의견은 TASK로 생성되어 스케쥴에 포함되었다.
<그림. 팀리뷰
리포트>
웍쓰루 (Walkthrough)
웍쓰루는 단체로 하는
코드 리뷰 기법중에서 가장 비정형적인 방법중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를
하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.
주로 사례에 대한
정보 공유나, 아이디어 수집을 위해서 사용될 수 있다.
개발을 위한 프로세스에서
보다는 “Bug 사례에 대한 회의”와 같은 정보 공유성격에
유리하다.
유일하게 발표자만이
리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게
의견을 개진한다.
웍쓰루는 정기적으로 (주일에 한번) 진행할 수 도 있으며, 또는 정보공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다. (정기적으로 진행하는 것이 참여율이나 집중도가 더 높다.)
Peer Review or Over
the shoulder review
피어리뷰나 Over the shoulder Review는 2~3명 (주로 2명)이 진행하는
코드 리뷰의 형태이다.
코드의 작성자가 모니터를
보면서 코드를 설명하고 다른 한사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.
사전 준비등이 거의
필요없고, 필요할때 마다 자주 사용할 수 있는 리뷰 방법이다.
주로 Senior 개발자(사수)가 Junior 개발자를 멘토링할 때 사용할 수 있으며, Junior 개발자에
대한 교육과 함께, Junior 개발자가 양산한 코드에 대한 품질을 관리할 수 있다.
그러나 이 기법은 Senior 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, Senior 개발자의 시간 투여량이 많은 만큼. Senior 개발자의 참여도가 떨어질 수 있다. (형식적으로 될 수 있다. )그래서 프로젝트 관리 관점에서 Peer Review 에 대해서도 프로젝트 스케쥴상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다.
실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 시켜야할 상황이 있었고, 그때 이 Peer Review를 진행하도록 하였다. 결과적으로 만족할만한 품질을 얻었지만, Senior 개발자에게 Review에 대해서 Task를 지정하고 스케쥴링을 하였음에도 불구하고, Senior 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있기 때문에, 팀원간의 실력 편차와 난이도에 따른 시간 배분과 함께, 경험적 (3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다. )인 작업량 측정이 필요하다.
Passaround
코드리뷰 스펙트럼에는
포함시키지 않았지만 사용되는 경우가 있어서 소개한다.
Passaround는 번역하자면 돌려보기이다. 온라인
보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정
장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애를 받지 않는 방식으로, 리모트에서
작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 Ownership이 애매하여 원하는 결과가 나오지
않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해서 커뮤니케이션 속도가 매우 느리다는
단점도 가지고 있다.
이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다.
필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품의 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맏는 개발자가 개발팀에 속해 있었기 때문에 원할한 Passaround 리뷰가 가능했고, 이슈(버그) 트랙킹 시스템 (Atlassian社 JIRA와 같은)과 소스 코드 Viewing system (Atlassian社 의 Fisheye)이 많은 도움이 되었다.
지금까지 간단하게나마 코드 리뷰의 기법에 대해서 살펴보았다. Formal한 리뷰 (코드 인스펙션..)등에 대한 설명이 많은 것은, 꼭 Formal한 리뷰가 좋아서라기 보다는 정형화 되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다.
회사의 성격 (SI,게임,임베디드,인하우스개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어
적용되어야 한다.
이올린에 북마크하기
이올린에 추천하기
