한달정도 전부터 서버팀에서 코드 리뷰를 시작했다.
아무래도 서버쪽이 클라이언트보다 코드의 질이 중요하다 보니 일단 서버팀만 해보기로 했는데, 다들 코드 리뷰는 처음이라 아직까진 시행 착오가 많은 편이다. 진행도 좀 어리숙하고...OTL
뭐 하다보면 익숙해 지겠지. 아무쪼록 잘 진행되어 서버팀에 한 문화로 정착되었으면 하는 바램이다.
아래는 코드 리뷰 준비하면서 정리했던 내용들...
○ 코드 리뷰 방법
1. 발표자는 리뷰할 코드의 샘플을 선택한다. 코드의 샘플은 복잡한 알고리즘을 구현한 부분이라던가 복잡한 API, 오브젝트 인터페이스를 사용한 부분, 새로운 기술을 응용한 부분 등의 핵심적인 부분을 잘 골라야 한다.
2. 리뷰를 준비하기 위해서 발표자는 리뷰할 코드의 블럭을 라인 넘버와 함께 프린트하여 각 프로젝트 구성원들(검토자)에게 배포한다. 검토자들은 코드 사본을 전달받고 미리 분석하여 질의 사항과 코멘트를 미리 작성한다.
3. 각자 준비가 끝나면 코드 리뷰 미팅을 개최한다.
4. 팀 구성원들은 코드 블럭에서 발견한 “결점”에 대해 논의하도록 한다.
5. 코드 리뷰 미팅이 끝나고 나면 리더는 리뷰 로그를 모두에게 보내고 그 수정 작업을 필요한 사람에게 할당하도록 한다. 수정 작업이 끝나고 나면 수정 사항이 제대로 코드에 반영되었는지 리드가 확인하도록 한다.
1. 발표자는 리뷰할 코드의 샘플을 선택한다. 코드의 샘플은 복잡한 알고리즘을 구현한 부분이라던가 복잡한 API, 오브젝트 인터페이스를 사용한 부분, 새로운 기술을 응용한 부분 등의 핵심적인 부분을 잘 골라야 한다.
2. 리뷰를 준비하기 위해서 발표자는 리뷰할 코드의 블럭을 라인 넘버와 함께 프린트하여 각 프로젝트 구성원들(검토자)에게 배포한다. 검토자들은 코드 사본을 전달받고 미리 분석하여 질의 사항과 코멘트를 미리 작성한다.
3. 각자 준비가 끝나면 코드 리뷰 미팅을 개최한다.
4. 팀 구성원들은 코드 블럭에서 발견한 “결점”에 대해 논의하도록 한다.
5. 코드 리뷰 미팅이 끝나고 나면 리더는 리뷰 로그를 모두에게 보내고 그 수정 작업을 필요한 사람에게 할당하도록 한다. 수정 작업이 끝나고 나면 수정 사항이 제대로 코드에 반영되었는지 리드가 확인하도록 한다.
○ 코드 리뷰시 고려해야 할 사항
- 리뷰 회의에 대해 충분한 준비 시간을 갖는다.
- 참가자 수는 3~5명 정도가 적당하다.
- 참가자들은 리뷰할 항목에 대한 충분한 도메인 지식을 갖고 회의에 참가해야 한다.
- 발표자는 준비에 대한 자료를 만들 때 새로운 코드와 변경된 코드, 주변(Surround) 코드에 대해 구분할 수 있도록 하이라이트를 표시한다. 최소한 주석과 공백을 포함한 각각의 실제 라인 넘버는 꼭 함께 출력한다.
- 코드 리뷰를 하는 동안에는 해결점에 대한 토론 시간을 자주 갖지 않는다.
- 코드의 스타일에 대해서는 토론하지 않도록 한다.
- 코드 작성과 리뷰 사이의 시간을 최소화 하도록 한다.
- 발표자는 검토자가 이미 코드에 대해 많은 부분을 이해하고 있다고 생각하지 말고, 최대한 꼼꼼하게 리뷰하도록 한다.
- 리뷰 회의에 대해 충분한 준비 시간을 갖는다.
- 참가자 수는 3~5명 정도가 적당하다.
- 참가자들은 리뷰할 항목에 대한 충분한 도메인 지식을 갖고 회의에 참가해야 한다.
- 발표자는 준비에 대한 자료를 만들 때 새로운 코드와 변경된 코드, 주변(Surround) 코드에 대해 구분할 수 있도록 하이라이트를 표시한다. 최소한 주석과 공백을 포함한 각각의 실제 라인 넘버는 꼭 함께 출력한다.
- 코드 리뷰를 하는 동안에는 해결점에 대한 토론 시간을 자주 갖지 않는다.
- 코드의 스타일에 대해서는 토론하지 않도록 한다.
- 코드 작성과 리뷰 사이의 시간을 최소화 하도록 한다.
- 발표자는 검토자가 이미 코드에 대해 많은 부분을 이해하고 있다고 생각하지 말고, 최대한 꼼꼼하게 리뷰하도록 한다.
○ 코드 리뷰시 검토해야 할 사항
- 인터페이스 에러
- 구문 에러 (Syntax Error)
- 논리적 에러 (Logic Error)
- 경계 조건 (Boundary Condition)
- 불완전하거나 잘못된 초기화
- 컴파일러 지시문
- 데이터 / 레지스터 / 카운터 에러
- 잘못된 호출 / 매개변수
- 타이밍 문제
- 성능 문제
- 인터페이스 에러
- 구문 에러 (Syntax Error)
- 논리적 에러 (Logic Error)
- 경계 조건 (Boundary Condition)
- 불완전하거나 잘못된 초기화
- 컴파일러 지시문
- 데이터 / 레지스터 / 카운터 에러
- 잘못된 호출 / 매개변수
- 타이밍 문제
- 성능 문제
○ 참고할만한 글
- Quick-Kill 프로젝트 관리법
- SW개발에서 'Peer Review'의 중요성(김익환)
- 위키피디아의 Code review
- Peer Review Process Description(PDF)
- 소프트웨어 테스팅(정보문화사) - 6장 코드검토
- CODE COMPLETE(정보문화사) - 21.4 협력적인 구현/다른 종류의 협력적인 개발 방법
- Quick-Kill 프로젝트 관리법
- SW개발에서 'Peer Review'의 중요성(김익환)
- 위키피디아의 Code review
- Peer Review Process Description(PDF)
- 소프트웨어 테스팅(정보문화사) - 6장 코드검토
- CODE COMPLETE(정보문화사) - 21.4 협력적인 구현/다른 종류의 협력적인 개발 방법

::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::
경험을 공유해주셔서 잘 봤습니다.
"코드 리뷰를 하는 동안에는 해결점에 대한 토론 시간을 자주 갖지 않는다." 이 뜻은 해결점에 대한 토론 보다는 각종 에러에 대해 검토하는데 집중한다는 것인가요? 아님 토론에 지나치게 많은 시간을 할당하지 않는다는 뜻인가요?