본문 바로가기
개발

프로그래밍 이야기- 코드 리뷰

by esstory 2007. 11. 9.

다른 사람이 작성한 소스 코드를 여러 사람이 함께 분석하는 과정을 일컫는 말로 코드 인스펙션(Inspection), 코드 리뷰, 코드 읽기 등 다양한 이름으로 불리어지는데(이름마다 조금씩 방식이 틀리더군요) 개인적으로는 CODE COMPLETE 2 에 나오는 “코드 읽기” 가 저에게 가장 잘 맞는 것 같습니다.

처음에는 저희 회사에 도입된 개발 방법론에 따라 코드 인스펙션을 진행했습니다.

코드 인스펙션은 레코더(회의기록을 남기는 사람) 과 한 명 이상의 인스펙터(소스를 읽고 지적을 해 주는 사람), 코더(소스를 짠 사람) 등 여러 사람들이 한자리에 모여 회의를 진행하는 방식입니다.  

회의도 한번만 하는 게 아니라 사전에 코드를 전달해 주기 위해 한번 모이고, 각자 소스를 보고 문제점을 A4 용지에 중요도에 따라 표시하고, 다시 회의실에 모여 Inspector 가 코더에게 잘못을 지적하고 레코드는 열심히 받아 적는 방식입니다.

그냥 보면 거의 인민재판 수준이지요. (물론 인신공격으로 여겨지지 않도록 조심조심했지만요)이 방식은 얼마 가지 않아 포기했습니다.  

여러 사람이 모일려니 시간도 잘 안 나고, 사전 문서와 결과 문서 작성하느라 시간도 많이 소요되고, 형식적으로 치우치다 보니 자연스럽게 자리를 잡지 못하고 사라졌습니다.

그러다가 CODE COMPLETE 2 를 읽으면서 “코드 읽기”를 알게 되었습니다.

코드 읽기는 코드 검수자와 코드 작성자 이렇게 두 사람이 아무렇게나 만나서 형식에 구애 받지 않고, 코드에 대한 얘기를 주고 받으면 되었습니다. 사전에 또는 사후에 특별히 문서를 작성할 것도 없고, 그냥 코드에 대한 느낌을 코더에게 전달하기만 하면 되는 방식이더군요.

코드 읽기 한 후에 실제로 코드를 고치든 않든 별 상관없습니다.

코더가 문제를 느꼈다면 당연히 수정했을 테니까요.

코드 인스펙션에 비해 다분히 개인적인 성향이 강하고, 강제성도 약하지만, 개발자간에는 이렇게 형식에 얽매이지 않는 방법이 좋더라고요.

한번 코드 읽기를 할 때 저는 보통 적게는 1,000 라인에서 많게는 3,000 라인 정도 코드를 읽습니다.

여러 번 반복하다 보니 점점 남의 코드 읽는 속도가 빨라지는 부수입도 있더군요.

코더를 괴롭히지 않기 위해 특별히 설명 같은 건 듣지 않고 무작정 CPP 의 첫 줄부터 끝까지 순서대로 읽어 내려갑니다.

이해가 안되면 꾸벅꾸벅 졸기도 하구요.

다시 꿈나라에서 돌아오면 희한하게 코드가 더 잘 읽혀지더군요 :-)  

제가 좋아하는 코드는 이렇습니다.

  • 읽기 쉬운 코드
  • 코더의 설명을 듣지 않아도 그냥 이해가 잘 되는 코드
  • 정리가 잘 되어 있는 코드
  • 주석이 잘 달린 코드
  • if 문 depth 가 짧은 코드
  • 함수가 100 라인을 안 넘는 코드
  • if – else 보다 swith 문으로 정리된 코드
  • 포인트를 사용하지 않는 코드
  • 중복이 없는 코드
  • 리소스를 잘 반환하는 코드
  • 성능에 대해서도 고려가 된 코드
  • 빠르게 찾기 위해 map 을 적절히 사용한 코드
  • 함수 인자로 객체를 전달하지 않는 코드
  • 멤버 변수의 초기화가 잘 되어 있는 코드
  • 상수가 if 문의 왼쪽에 있는 코드  
  • memcpy, sprintf 대신 sprintf_s, memmcpy_s 를 사용하는 안전한 코드
  • 생성자에서 exception 이 날만한 행동을 하지 않는 코드
  • 다른 클래스와 직접적인 종속성이 최소화된 코드
  • 인터페이스가 잘 정의된 코드
  • 오버하지 않는 코드
  • 더 이상 뺄게 없는 코드
  • 리팩토링이 잘 되어 있는 코드
  • 졸리지 않는 코드

 

 끝도 없이 많겠지요?. 

다른 개발자 분들의 얘기도 궁금합니다. 

코드 읽기나 리뷰를 하시고 계신가요? 

주로 몇 명이 하시는지, 모든 코드를 다 훑어 보는지 감정은 안 상하는지, 
어느 부분을 중점적으로 보는지 공유해 주실래요? ^^;
 (암도 대답 안 해줄 것 같은 불안감)   

댓글