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

2007.11.09 20:32개발

다른 사람이 작성한 소스 코드를 여러 사람이 함께 분석하는 과정을 일컫는 말로 코드 인스펙션(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 이 날만한 행동을 하지 않는 코드
  • 다른 클래스와 직접적인 종속성이 최소화된 코드
  • 인터페이스가 잘 정의된 코드
  • 오버하지 않는 코드
  • 더 이상 뺄게 없는 코드
  • 리팩토링이 잘 되어 있는 코드
  • 졸리지 않는 코드
  • ……

 

끝도 없이 많겠지요?.

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

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

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

 

 

 

  • 프로필사진
    BlogIcon DyNast2007.11.09 21:54 신고

    좋은책인거같내용 ㅎ

    나중에 기회만되면 사봐야겠어요 ㅎ

    • 프로필사진
      BlogIcon esstory2007.11.10 07:09 신고

      이쪽 공부하시는 분들이라면 이 책 대부분 가지고 있는 걸로 압니다 ^^; 사서 볼만한 가치가 있어요~

  • 프로필사진
    BlogIcon NeoPJS2007.11.10 00:20 신고

    혹시 영어로 쓰인 책인가요?

    • 프로필사진
      BlogIcon esstory2007.11.10 07:10 신고

      위에 링크
      http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200504110013 를 따라 가보시면 아시겠지만 한글 책입니다 ^^

  • 프로필사진
    BlogIcon 겐도2007.11.10 01:37 신고

    기본적으로 서비스에 적용되기 전에 변화된 모든 소스들은 리뷰과정을 거칩니다. 아직 자동테스트는 못하지만 티켓관리를 하므로 정확히 해당 버그가 수정되었는지 확인은 물론 변화된 코드를 검토합니다.
    특히 새로운 기능이 추가되어 함수가 삽입되는 경우는 타인에게 특별(!)리뷰를 부탁하기도 하죠. 나중에 터져서 쩔쩔맬 것을 미리 잡아주니 성낼 사람은 없습니다.

    위의 리스트를 보니 개인 취향을 적으셨는데 리뷰에서 이런 관점은 매우 위험합니다. 조언이나 학습이 아닌 리뷰기 때문이죠. 스파게티 곱배기가 들어 있어도 있는 그대로 문제점을 확인해야 합니다. 가령 Switch와 if를 예로 든다면 Readablity와 Perfomance에 대한 장단점이 있습니다. 이런 부분이 지적되면 서로 논쟁에 빠져 버리죠. 그건 둘째 치고 리뷰어가 그런 부분에 신경을 쓰게 되면서 정작 버그를 놓칠 수 있습니다. 조건문에서 상수의 위치 같은 경우 IDE에서 왠만하면 다 잡아 줍니다.(혹은 코딩 가이드에서 처리할 문제죠)

    일반적으로 타인의 코드를 수정할때도 포함하여 코딩스타일에 대해선 절대 손대지 말아야 한다는 원칙을 세우고 있습니다. 들여쓰기나 시작 괄호가 같은 라인이냐 다음 라인이냐 등등에 대해선 지적하지 않도록 합니다. 물론 심각한 코드들은 어느순간 리팩토링의 이름으로 갈아껴지겠죠.

    • 프로필사진
      BlogIcon esstory2007.11.10 07:24 신고

      겐도님 자세하게 알려주셔서 감사합니다
      사실 저희 회사가 SI 업체가 아니다 보니 회사 내부의 개발 방법론이 철저하게 지켜지지 못하고, 문서화나 지침이 그때 그때 업데이트 되지 못하는 단점이 있긴 합니다.

      그나 저나 변경되는 모든 소스를 리뷰한다니 대단합니다. 상대적으로 시간이 꽤 많이 들테지만, 개발 후 그만큼 오류가 줄어 들테니 훨씬 현명한 방법이라고 생각됩니다. (저희는 리뷰하지 않고 배포하는 경우가 더 많습니다. 매일 수백kb ~ 수십mb 크기의 변경분을 프로덕트로 배포하고 있는데, 시간적으로 참 난감한 부분입니다.)

      코딩스타일에 대해서는 회사마다, 코딩 지침으로 괄호나 들여쓰기까지 지침으로 두는 회사가 있는 것으로 압니다. 물론 저도 개인적인 성향으로 보고 크게 신경쓰지는 않는 부분이구요.

      말씀하신대로 위에 적힌 내용들은 다분히 개인적인 취향들이 많기 때문에 리뷰를 하면서 강요하거나 하지는 않습니다. 위에 적은 것처럼 서로 공감하는 부분에 대해서, 코드를 읽기 편하고, 그래서 나중에 유지 보수 하는 데 문제가 없지 않겠냐는 데 동의를 할 경우 코드를 수정하고 있습니다.
      개인적인 성향이긴 하나, 코드 리뷰라는게 결국은 코드를 읽는 사람의 역량에 기댈 수 밖에 없지 않을 까요.. 딱 보면 그냥 아는 사람들도 많으니까요 ^^;

      겐도님의 회사가 궁금하네요. FM 대로 멋지게 잘 해 나가고 계신거 같아 부럽습니다.
      댓글 감사합니다.

    • 프로필사진
      BlogIcon 겐도2007.11.12 02:48 신고

      저 내용들은 Tistory의 개발에 사용되었습니다 :)

  • 프로필사진
    BlogIcon 이병준2007.11.11 22:56

    잘 읽었습니다. 저는 제 코드는 보는데 남의 코드는 잘 안 보는 편입니다.
    남의 코드를 보아야 한다면 그냥 처음부터 다시 짠다는 안좋은 습관도 가지고 있습니다.
    최근에는 그런 문제를 극복하기 위해 애를 많이 쓰고 있습니다만...
    CODE COMPLETE 2판이 나왔다니 한번 읽어보아야겠네요. 최근에 사놓은 책이 많아서
    좀 부담이 되긴 합니다만...

    • 프로필사진
      BlogIcon esstory2007.11.11 23:46 신고

      저도 남의 코드를 보기도 싫어하고, 제 고집대로 하는 편인데요 관리자가 되고 보니 제가 코드 짤일이 없어지고, 후배가 제대로 작성하지 못하는 일때문에 맨날 장애보고서나 써야하는 신세라서요.. 제가 살기 위해서는 열심히 다른 사람들의 코드를 봐야 하는 게 제 일아닌 일입니다 :)
      책은 작년 6월에 산 거니까, 한참 됐습니다 ^^; 코드 읽기를 처음 본 책이 그 책이라 언급했는데 의외로 이 책에 세상에 나온걸 모르시는 분들이 많네요. 단연코 실용주의 프로그래머와 함께 꼭 봐야 할 책 중에 한 권입니다. 책이 너무 뚜꺼워 전체를 다 읽기는 힘들구요. 역사책처럼 어느 날 갑자기 고구려의 낙랑공주가 얘기가 궁금할 때 고구려 편을 펼쳐보듯 관심있는 곳 부터 먼저 읽어 보는 것도 좋을 것 같습니다.
      주말 잘 마무리 하세요 ;)

  • 프로필사진
    BlogIcon 김형준2008.03.18 17:07

    더 이상 뺄게 없는 코드에 강하게 도장찍습니다..

    • 프로필사진
      BlogIcon esstory2008.03.19 19:55 신고

      저도 군더더기 없는 깔끔한 코드를 좋아합니다.
      너무 심오하게 짧아서 이해할 수 없는 정도가 아니라면, 기능에 충실한 기능 그 자체만 있는 코드가 가장 현명한 코드 인거 같습니다.
      리플 감사합니다. :)

  • 프로필사진
    BlogIcon ohyecloudy2009.10.01 08:47 신고

    잘 읽었습니다.

    저런 방식을 어깨너머 리뷰라고 하더라구요. 몇 번 코드리뷰를 했는데, 다 이 방식이었습니다.
    시간 대비 효율때문에 코드 리뷰툴을 사용하는게 더 낫지 않을까 생각하고 있습니다.