C/C++: Code Review 하는 방법

많은 사람들이 코드리뷰는 매우 중요하다고 생각하고 필요하다고 말한다.

 

코드 리뷰는 상당히 귀찮으면서, 동시에 필요하다고 느끼는 부분일겁니다.

다른사람의 코드를 읽는다는 것이 상당한 시간과 노력이 필요한 부분이기 때문에 그만한 열정이 없다면 힘들겠죠.

 

만약 당신이 엄청난 열정의 소유자이고 팀원을 위해서 희생을 할 용의가 있다면, 코드리뷰를 시작해봅시다.

 

그런데 무작정 다른사람의 코드를 처음부터 끝까지 보는 것은 엄두가 안나죠.

 

정작 코드리뷰를 어떻게 해야 할지 모르는 경우가 많습니다. 어떻게 하는 것이 좋을까?

 

일단 가장 좋은 방법은 툴을 활용하는 방법이 있습니다.

그러나 Prevent 같은 툴을 돌려서 확인할 수 있는 환경이라면 코드리뷰상 고민거리가 없겠지만, 실제 그런 환경에서 개발하고 있는 개발자는 많지 않다. 때문에 개발자가 눈으로 코드리뷰 하는 방법도 알아둘 필요가 있습니다.

 

 

쉽게 코드리뷰를 시작하는 방법은 형상관리 툴(git.. 등)을 이용하는 방법입니다.

모든 코드를 한번에 확인하기는 어렵습니다. 그러나 commit 단위로 는 작성된 코드를 쉽게 볼수 있습니다. 또 수정 전후 코드를 비교해 볼 수 있기 때문에 더더욱 리뷰를 하기 편합니다.

이럴때, 해당 코드 외에 다른 부분에 대해 수정했으면 하는 사항이 보인다면 그것도 같이 comment 해주면 좋겠죠.!!

그럼 다음으로 코드리뷰는 어떻게 해야 할까요?

여기에는 코드 리뷰어의 역량에 따라 달라지는 부분이기는 합니다.

만약 처음 코드리뷰를 해보겠다고 생각하셨다면 제가 추천해드릴 수 있는 방법이 몇가지 있습니다.

1. 프로그래밍 상 기본적으로 지켜야 하는 사항( 문법적인 요소)을 지켰는지 확인한다.

[참조] http://reiot.springnote.com/pages/115620    

 

• 상속 관계의 베이스 클래스에 virtual destructor 를 선언했는가?
• 배열 포인터를 delete[] 로 삭제하는가?
  • delete:Wh*[]으로 정규식 검색을 하면 편하다.
• 배열이 아닌 포인터를 delete[] 로 삭제하는가?
• memcpy(), memset(), memmove(), strcpy() 메모리 관련 함수들의 BoundCheck가 잘 되어 있는가?
• 배열을 인덱싱할 때 파라미터의 BoundCheck 가 잘 되어 있는가?
• 다른 네트워크에서 넘어온 모든 정수형 파라미터에 대한 BoundCheck가 잘 되어 있는가? (특히 문자열 길이에 유의)
• STL string 을 사용한다면, %s 포맷팅할 때 c_str() 을 사용하는가?
• Singleton 이나 STL 컨테이너에 대해서 2개 이상의 쓰레드가 동시에 읽기/쓰기 모드로 접근하는 경우 lock 을 걸고 있는가?
• 사용하지 않는 copy constructor, assignment operator 가 private 로 선언되어 있는가?
• 포인터 멤버를 가진 객체를 복사할 때 assignment operator 를 재정의했는가?
• Warning Level 을 4 로 높인 다음 컴파일해봤는가?
  • 초기화하지 않고 사용하는 변수(또는 클래스 데이터 멤버)가 가장 위험하다.
• try ~ catch( … )는 주의 해서 사용하자. SEH Exception 까지도 캐치해버린다.버그를 숨겨서 더 큰 버그를 만들 뿐이다.
  • 시스템에서 던지는 throw 의 경우에는 에러 시나리오를 작성해서 예외 처리 할 수 있겠지만, 이 경우에도 리소스 해제와 관련된 문제가 발생할 가능성도 있다. 때문에 try catch를 사용함에 있어서 주의가 필요하다.
  •  우리가 만드는 코드에서 throw를 하는 경우는 없도록 설계하는 것이 중요하다. (함수에 nothrow 시그니처를 추가하자!! )
• set_se_translator() 를 쓰지 마라. 쓰레드 로컬이라, 매 쓰레드마다 해줘야 한다. SetUnhandledExceptionFilter()는 프로세스 글로벌이다.
• Visual Studio .net 2005 에서 지원하는 [코드 분석] - [C/C++에 코드 분석 사용] (/analyze) 을 사용해서 주기적으로컴파일러를 이용한 코드분석을 시행하라.

2. 도메인 지식을 기반으로 리뷰를 해야한다.

도메인 별로 중요하게 생각하는 부분들이 있기 마련이고, 그때문에 도메인 만의 독특한 형태의 코드 구성이 있을 수 있다.

도메인 내의 개발자는 이런 포인트들을 미리 정리해서 가이드를 만들어 둔다면 , 이 가이드 기반으로 코드리뷰를 진행할 수 있다.

• naming을 잘 지켰는가?
• allocation된 메모리나 생성된 객체에 대한 소유 정책이 정책이 있는가? 또 이를 잘 지켰는가?
• 즉, 생성한쪽에서 소멸하는 정책인가 ?
• 객체나 메모리를 위임할 수 있는 정책인가?
• System의 처리방식과 잘 조화가 이뤄졌는가?

이런 문제들을 먼저 채크해 봐야 할듯싶습니다.

 

위와같이 체크리스트를 만들고 공유하며, 주기적으로 업데이트하여 체크리스트 를 보완해 나간다면 좋은 리뷰를 할수 있고 서로에게 도움이 되는 방향으로 개발 문화를 정착 시켜 나갈 수 있을 겁니다.