코드 리뷰 살펴보기

코드리뷰?

 

                                                                            2013.02.25  오상문

 

1.       코드리뷰 종류  

코드리뷰(Code Review)를 수행하는 몇 가지 기법이 있는데, 우리 연구소 개발팀에서 진행한 리뷰는 ‘팀 리뷰’ 기반으로 ‘피어 리뷰’를 접목한 것에 가깝다.

코드리뷰의 시초는 패건(Fagan)에 의해서 소개된 코드 인스펙션(Code Inspection)이다. 소프트웨어 개발이 끝난 후에, 전문 인스펙션(조사) 팀이 미리 정해진 프로세스와 패턴에 따라서 코드를 검증하고 결함(Defect)를 찾는 것이 코드 인스펙션이다.

 

코드리뷰란

“코드를 실행하지 않고, 사람이 검토하는 과정을 통하여 코드에 숨은 잠재 결함(Defect)을 찾아내고 개선하는 일련의 과정”이다.

코드리뷰는 ‘결함 개선’ 이외에 여러 관점에서 바라보는 아이디어 회의 및 지식 전달이나 교육의 부가적인 목적도 수행한다. 몇 가지 코드리뷰 방식이 있지만, 회사, 업무, 조직 등에 따라 활용 방법은 달라질 수 있다.

 

Formal vs. Lightweight

코드 인스펙션은 가장 정형화된(Formal) 패턴과 프로세스를 사용하여 코드를 분석한다. 팀 리뷰는 코드 인스펙션에 비해 덜 정형화되긴 했지만, 일정한 계획과 프로세스는 있다.

반면, 워크쓰루는 비정형화된 자유로운(Lightweight) 코드리뷰에 속한다.

 

1)  팀 리뷰(Team Review)  *****

 

팀 리뷰는 개발 단위(Unit)의 리뷰에 좋다.
일주일에 한번 정도, 한 시간 정도 정기적인 리뷰를 진행한다.
해당 프로젝트의 리더 즉, PL(Project Leader) 주도로 수행할 수 있다.
PL 또는 시니어 개발자가 리뷰 대상 모듈을 선정하고 해당 개발자는 리뷰를 준비한다.
리뷰는 발표자가 소스를 보여주고, 팀원이 리뷰어에 참여하므로 팀 단위로 활용하기 좋다.
위키 등의 문서 공유 시스템을 이용하여 리뷰 결과를 기록한다.
리뷰 결과는 일감 관리(Task Management)의 일감(Task)으로 연결하여 관리한다.
리뷰에서 나온 의견은 액션 아이템(Action Item)으로 잡고, PL이 발표자 스케줄 조정에 이용한다.
리뷰 후에 반영된 내용은 재 테스트를 통해서 검증해야 한다.
일반적으로 팀 리뷰의 효과가 가장 크다.

[요점]

선정 – 발표 - 리뷰 – 기록 - 공유 – 관리 – 재 테스트

 

2)  피어 리뷰(Peer Review)  *****

 

주로 2명(또는 3명)이 진행한다.
개발 프로세스보다는 “버그 사례 회의”와 같은 정보 공유 성격의 리뷰에 유리하다.
신입 교육, 서비스, 제품, 기술에 전문 지식이 부족할 때 유용하다.
실력 격차가 큰 팀에서 유용하다.
지식 공유(Knowledge Transfer)와 품질 유지를 목적으로 진행할 수 있다.
유일하게 발표자만 리뷰를 주관하고 발표하고, 다른 참여자는 자유롭게 의견을 나눈다.
코드 작성자가 모니터를 보면서 설명하고 다른 사람이 아이디어를 제안하거나 결함을 찾는다.
필요할 때마다 사용한다.
주로 시니어 개발자(사수)가 주니어 개발자(부사수)를 멘토링 할 때 사용한다.
주니어 개발자 교육과 함께, 주니어 개발자의 코드 품질을 관리할 수 있다.
리뷰어의 일감(Task) 부담이 크므로 스케줄 배려가 필요하다.

 

3)  워크쓰루 (Walkthrough)

 

일종의 아이디어 회의이다.
비정기적으로 언제나 개최할 수 있다.
PL이나 시니어 개발자가 중재하지 않는다.
구성원의 의욕과 참여도가 중요하다.
QA나 운영 팀에서 정보 교환 목적으로 사용하면 좋다(장애 사례나 버그 수정 사례 등).

 

4)  코드 인스펙션(Code Inspection)

 

전문성을 가진 인스펙션 팀이 일정 프로세스와 패턴에 따라서 개선안을 찾는다.
개발 완료(Release) 단계의 시스템이나 서비스를 대상으로 한다.
고도로 훈련된 팀이 필요하다.
인스펙션은 개발 초기(설계 분석)에 1차, 개발 후에 2차(안정, 성능, 확장)로 나누어 할 수도 있다.
명확한 테스트 시나리오 정의가 필요하다.
전문 SI업체의 인스펙션 팀을 이용하거나, 자체 QA 조직에서 인스펙션 팀을 운영한다.
외부 인력이나 여러 팀이 함께 인스펙션에 참여해야 하므로 일정 조정이 필요하다.
인스펙션 결과를 반영을 위해서 프로젝트 관리 조직에서 접근해야 한다.

 

5)  패스어라운드(Pass Arround)

 

앞의 네 가지(코드리뷰 스펙트럼)에는 포함되지 않지만 사용하는 경우가 있다.
패스어라운드(돌려보기)는 오프라인 위주로 진행되는 리뷰에 적합하다.
작성자가 리뷰할 부분을 메일이나 시스템을 통해서 등록한다.
참석자들이 메일이나 답변을 통해서 의견을 전달한다.
책임감이 없고 참여의식이 떨어지면 진행 자체가 어렵다는 단점이 있다.
실시간이 아니므로 커뮤니케이션 속도가 매우 느린 단점이 있다.
이슈 트래킹 시스템을 잘 활용하면 좋다.

 

 

 

2.       코드리뷰 잘 활용하기

 

리뷰의 주요 목적은 결함을 발견하고 개선하는 방안을 찾는 것이다.
코드리뷰만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 거의 없다.
팀 리뷰, 코드 인스펙션에서는 리뷰를 중재하는 사람의 통제를 잘 따라야 한다.
리뷰어는 아이디어나 결함에 대한 의견을 자유롭게 나눠야 한다.
발표자가 인신 공격을 받아서는 안 된다.
리뷰에 대한 후속 처리를 위해 하나의 프로젝트처럼 시간과 리소스를 배려한다.
리뷰가 자리잡기 위해서는 최소한 1~2달 이상의 기간이 필요하다.

 

 

 

코드리뷰 결과 표

 

리뷰 과정에서 나온 의견은 팀 프로젝트 (위키 등)에 “코드리뷰”로 만들어서 관리한다.

 

각 의견은 일감(TASK)으로 생성하여 스케줄에 포함한다. 다음은 팀 리뷰 보고서 형식이다.

 

-------------------------------------------------------------------------
날짜: 2013년 2월 22일(금)   ß 코드리뷰 날짜

 

발표자: 홍길동   ß 코드리뷰 발표자

 

대상: 로그인 프레임웍 코드리뷰    ß 코드리뷰 목적과 대상

 

참고:                        ß 참고 링크

 

액션 아이템:     ß 코드리뷰 결과, 발견된 개선사항

 

AI 1. 사용자 가입 정보에 대한 유효성 검증 추가 (T100_1)   ß

액션 아이템과 일감 번호
AI 2. 쿼리에서 escape 처리를 통한 보안 개선 (T100_2)
…

 

제안사항:

 

…

 

------------------------------------------------------------------------------- 

 

<이상>