코드리뷰, GitHub로 바로 적용하기

코드리뷰, 하고 계세요? 개발하기도 바쁜데 언제 코드리뷰 하나요? 빠르게 변화하는 세상에서 조직은 계속 바뀌고 팀 내 개발자들의 구성원은 계속 변경되는데 복잡한 코드리뷰 도구와 리뷰정책을 개발자들에게 교육하고 개발 flow에 맞게 리뷰하는 것이 가능할까요? 많이 사용하시는 코드리뷰 도구의 소개와 GitHub에서 간단하게 코드리뷰 하는 방법을 모바일데이터베이스 Realm의 사례를 들어 설명합니다

나의 코드리뷰의 기억

네. 저도 코드리뷰를 해보았습니다. 대기업에서 말이죠.

1.코드리뷰 미팅 요청 2.리뷰 받을 코드의 범위와 회의실, 시간 등을 공유

  1. 개발자들은 미리 코드를 읽어온 후 회의실에서 코드리뷰

이렇게 이루어졌는데요, 예상 하셨다 시피 성공적이지 못했습니다. 다들 바쁜데 코드리뷰 미팅을 요청하지도 않을 뿐 아니라, 회의전 미리 코드를 읽어오지도 않았고, 그러면 1시간이라는 짧은 회의시간 동안에 개발자가 코드 설명하는데 시간 소비하고 나면 회의를 참석한 개발자들 눈에 보이는건 추가적인 의문사항과 코드컨벤션 뿐이었죠. 결국은 회의에 참석한 5명이상의 개발자들은 시간도 낭비하고 얻는 것은 없는 불행한 상황이 됩니다. 😂

코드리뷰 도구

그래서 등장한 것이 코드리뷰 도구 입니다. 위에서 예를 든 코드리뷰를 다같이 모여서 하는 동기(synced) 코드리뷰라고 한다면, 코드리뷰 도구를 사용하면 비동기(async)적인 코드리뷰를 진행할 수 있습니다. 도구를 통해서 코드 저장소를 건드리지 않고 코드에 코멘드를 달고, 대화를 이어나갈 수 있습니다. 이를 도와주는 도구는 Gerrit, Review Board, Phabricator 같은 오픈소스 무료 도구 들도 있고, 조금더 예산이 있는 회사들을 위한 JetBrains 의 Upsource 나 Atlassian의 Crucible과 같은 도구 들이 있습니다. 이런 도구들은 내부 LDAP과 연동되고 JIRA와 같은 이슈 트래커와의 통합을 통해서 내부 에있는 다양한 형상관리도구 (Git, SVN)안에 있는 코드를 리뷰할 수 있도록 도와줍니다. 아래는 Upsource의 홈페이지에 있는 화면 예시 입니다.

이런 개발 뉴스를 더 만나보세요

이런 도구들은 큰 회사에서 코드리뷰를 조직적으로 관리하는데에는 좋지만 다양한 외부 모듈들과 연동하여 환경을 설정하는데 많은 노력이 들고 관리하는데에도 많은 노하우가 필요합니다. 물론 유료솔루션은 별도의 비용을 내야 하는 것도 단점입니다.

GitHub의 Pull Request를 통한 코드리뷰

많은 분들이 Pull Request를 오픈소스에 기여하기 위한 수단 으로 알고계시지만, GitHub의 Pull Request는 훌륭한 코드리뷰 도구 입니다. 많은 분들이 git flow 라고 하는 git의 브랜치 관리 전략에 대해서 들어보셨을 것입니다. 많은 도구들이 git flow를 지원하고 있지만 아직도 꽤 복잡한 방법이기에 팀 내에서 자리잡기에 많은 시간이 걸립니다. GitHub에서는 이보다 훨씬 단순한 GitHub Flow 라는 브랜치 전략을 소개했는데요 그중 핵심은 코드를 바로 커밋하거나 master에 머지하는 것이 아니라 Pull Request를 생성하고 그를 리뷰하고 논의한 후에 머지하는 것입니다. 또한 GitHub에서는 코드리뷰 기능을 자신들의 핵심기능중 하나라고 소개하고 있습니다.

Pull Request를 통해서 다른 팀원에게 @mention을 통해서 코드리뷰를 요청하고, 다른 사람은 해당 코드가 있는 브랜치를 받아서 직접 돌려보는 것은 물론 라인별로 코멘트를 통해 수정을 요청하거나 의도를 물어볼 수 있습니다. 트리거를 통해서 CI에서 자동으로 테스트 되게 할 수도 있습니다.

그러면 모바일 데이터베이스를 개발하는 Realm에서 코드리뷰를 어떻게 하고 있는지 한번 볼까요? isEmpty 라는 기능을 추가하는 Pull Request를 예시로 들어보겠습니다. 먼저 위 링크는 이미 merge 가 되어있기 때문에 많은 논의 들이 ‘outdated diff’라는 이름으로 접혀 있으니 클릭하셔야 보실 수 있습니다.

먼저 아래와 같이 코드에 대해서 질문하고 답변하며 토론 할 수 있구요. 인터페이스가 페이스북 답변 달듯이 쉽습니다.

CI상에서 모든 테스트를 통과하고 2명이상의 리뷰어가 리뷰가 다 되었다고 동의를 하면 merge 하게 됩니다. 그 때까지는 계속 코드를 토론을 통해 수정해나가게 됩니다.

Pull Request는 Git의 기능이 아닌, GitHub의 기능이기 때문에 Pull Request를 통한 코드리뷰는 GitHub나 GitHub Enterprise 를 사용하는 경우에만 가능 합니다. 물론 Bitbucket 에서도 같은 기능을 제공하고 있으므로 Bitbucket에서도 Pull Request를 사용하실 수 있습니다. GitHub를 통한 코드리뷰는 GitHub만 사용하고 있다면 별도의 설정이나 추가비용 없이 당장 적용할 수 있습니다.

GitHub에서 직접 설명한 Pull Request에 대한 소개 링크 도 확인해 보시기 바랍니다.

모든 코드를 코드리뷰 해야 할까?

글쎄요. 그렇지는 않을 것입니다. 예를 들어 마케팅 팀에서 요구하는 타이밍이 중요한 UI 변경 사항이라던지, 프로젝트를 혼자 진행하는 경우(회사에서 Android개발은 혼자하는 경우)에는 이런 도구를 통한 코드 리뷰는 맞지 않을 수 있습니다. Realm에서도 Product에 사용되는 모든 코드는 코드리뷰 과정을 거치지만 다른 저장소에 있는 내부적으로 사용하는 도구라던지, 중요하지 않은 저장소 (홈페이지나 샘플코드 등)의 경우 리뷰가 필요한지 판단해 선택적으로 Pull Request 과정을 거칩니다. 비지니스 로직이라던지, 여러명이 하나의 프로젝트를 함꼐 개발하는 프로젝트의 경우에는 코드리뷰를 통해 다른사람이 개발한 코드와 같이 동작하면서 생길 수 있는 문제를 미연에 방지하고, 코드의 완성도를 높일 수 있습니다.

모든 코드를 리뷰해야 한다거나 완벽한 코드리뷰를 해야 한다는 것에 강박관념을 가질 필요없이 GitHub와 같은 도구를 사용해 하나하나 도입해 나가는건 어떨까요?

코드리뷰는 문화다. 개발자의 권리다

적절한 코드리뷰는 개발자의 권리 입니다. 남의 코드를 리뷰하고 토론하는 것은 무엇보다도 훌륭한 프로그래밍 역량을 기를 수 있는 방법 입니다. 또 ‘리뷰를 받을 코드이다’라는 생각으로 코딩을 하게 되면 더욱 가독성이나 로직등에서 더 깔끔하게 코딩하게 됩니다. 코드리뷰는 시스템으로 강제되기 보다는 제품과 사람을 우선시하는 문화를 바탕으로 해야 합니다. 그래서 적용이 쉽지 않지만 노력해 볼만 합니다. 영어학원 지원 프로그램이나 다른 복지 보다 코드리뷰 할 수 있는 시스템과 문화를 요구하세요. 회사를위해서, 개발자 자신을 위해서.


Realm은 모바일 데이터베이스 입니다: SQLite 또는 Core Data를 대체하여 사용하실 수 있습니다. 더 알아보기

컨텐츠에 대하여

이 컨텐츠는 저자의 허가 하에 이곳에서 공유합니다.


박민우

비지니스를 좋아하는 소프트웨어 개발자 @tebica / Realm을 아시아지역에 확산시키는 일을 합니다.

4 design patterns for a RESTless mobile integration »

close