오래된 SW 엔지니어의 평생 공부

업무를 하면서, 코드 리뷰에 대해서는 지속적으로 이야기가 많았다. 하지만, 나는 상당히 오랫동안 코드 리뷰를 하지 않았다. 실무를 하고 있을 때에는 Pair-programming을 하거나 하면서 사람들과 자연스럽게 코드 리뷰를 하거나 코드를 함께 논의 하는 경우가 많았다. 하지만, Project Lead를 하기 시작하고 실무와 거리가 생기면서 여러명이 큰 코드 변경 사항에 대해서 Offline으로 코드 리뷰를 하거나 하는것 이외에는 기회가 없었다고 할 수 있다.

최근에는 그룹에서 일어나고 있는 코드 리뷰 한 것들에 대해서 전반적으로 리뷰를 하게 되면서 코드 리뷰의 리뷰를 하게 되었다. 회사에서 이러한 전반적인 방향성을 받으면서, 가이드를 정리하게 되어 새롭게 느끼고 배우게 되는 부분을 정리해 본다. 

1. Coding Style

Coding Style은 코드 리뷰의 가장 기본적인 사항이다. Baseline이라고 할수 있다. 이는 언어의 특징을 이해하고 Readability를 위한 가장 기본이 되는 룰이다. 이에 관한 것은 회사 마다 다를 수 있다.

- Google Coding Style (Language-dependent): Android를 개발 하는 사람들에게는 기본룰이라 할 수 있다.

  Google 코딩가이드(Java, C++ 등 언어별): http://google.github.io/styleguide/

  안드로이드 기여자를 위한 AOSP 자바 코드 스타일: https://source.android.com/setup/contribute/code-style

- 회사 마다 다른 룰이 있을 수 있다. 하지만 기본적으로 읽는 사람을 위주로 만들어져야 한다.

2. 문화 관점

코드 리뷰는 상호 존중 문화가 기본이 되어야 한다. 함께 좋은 코드를 작성한다는 기준으로 리뷰를 작성해야 한다.

- You나 I 대신에 This code나 We를 주어로 리뷰를 한다. 우리가 리뷰하는 대상은 동료가 아니가 코드이고, 같이 해결해야하는 것이이 때문이다.

- 마침표나 느낌표 대신에 물음표로 리뷰하자. 지시보다는 제안이나 질문의 형태가 좋다. 리뷰어도 사람이라 실수가 있을 수 있고, 리뷰이의 마음에 상처를 준다면 안된다.

- 리뷰 의견 작성 시 질문이나 제안 위주로 작성한다.

- Merge되어도 좋다고 판단되는 경우  “수고하셨습니다” 또는 LGTM(Looks Good To Me) 등 코멘트 작성한다.

3. Review Skills

이제 스킬을 이야기 하는 것은 위에 것들이 정말 중심이 되기 때문이다. 코드를 리뷰하는 사람(Reviewer) 입장에서 뿐만 아니라 리뷰를 요청하는 사람 입장(Reviewee)에서도 스킬이 필요하다는 것을 알게 되었다.

- Reviewee

  + 코드리뷰 Description에 이슈, 체크방법 등 상세 기술

    내가 중점적으로 확인했으면 하는 부분에 대해서는 더 자세히, 필요한 링크가 있다면 그 부분도 포함하여 설명하는 친절한 요청이 좋다.

  + 패치는 짧으면 짧을 수록 좋다. 리뷰 시간이 줄어들고, 품질도 올라간다. 브랜치 머지때 merge conflic도 줄어든다.

    1시간 내 리뷰를 고려하여 Patch Set(Commit) 고민. (50 LOC 이하 & 6개 파일 이하 권장 )

    하나에 한가지 수정에 집중하는 것이 리뷰에도 편하다.

- Reviewer

  + 상대방을 존중 한다.

  + 선/후배 간에 격의 없이 리뷰 한다. 정말 이렇게 하기 위해서 문화가 만들어져야 한다.

  + 아래 다양한 관점에서 리뷰 한다. 특히, 자신의 강점 분야에서 리뷰를 하는 것이 좋다.

  + 지속적으로 다른 사람들의 좋은 리뷰를 보면서 배워야 한다.

- 다양한 리뷰 관점

  + 여러 사람들에게 피드백이 있어야 한다. 특히, 큰 변화/중요한 변화라면 더 많은 사람들의 리뷰 필요하다. 관련 모듈이 있을 경우 초대하여 리뷰 받는 것도 좋다.

  + 요구 사항 관점: 기능/비기능 요구 사항에 영향을 미치는 예상 결함에 대한 코멘트들이 제공. UX/GUI 가이드에 따르는 리뷰 코멘트도 중요하다.

  + Logic 적인 관점: Memory Leak 등 프로그램 로직 관점에서 리뷰도 기본적이라고 할 수 있다.

  + Architecture 관점: 코드의 구조적 개선에 의견이 코멘트 될 수 있다. (긴 함수, 중복 코드, 미사용 코드, 복잡도 등 뿐만 아니라, Design Pattern, Architectural Style 등 포함)

  + Domain Knowledge 관점: 기술 도메인에 따른 특징들이 반영된 코멘트들도 매우 중요하다.

  + 이슈 해결의 근본 원인: 문제점의 경우, 원인을 근본적인 원인을 찾아 내려는 토론 예를 들어, Null Check만 하더라도, 현상만 보지 않고 원인이 무엇인지 찾는 리뷰가 더 좋다.

마치며

다양한 측면에서 지속적으로 고민되어야 하고, 좋은 사례는 계속 공유되어야 한다. 이를 위해서 조직의 코드를 지속적으로 살피고 좋은 사례, 나쁜 사례, 중요한 사례가 지속적으로 공유 되어야 한다.