코드 리뷰
코드 리뷰가 끼치는 효과 5가지
•
동작 오류 제거 (Reduce behavioral erros)
•
구조 결함 제거 (Reduce structural errors)
•
팀 이해도 향상 (Improve team understanding)
•
학습 촉진 (Accelerate learning)
•
팀 위험 제거 (Reduce team risk)
구글
100% 코드 리뷰, 모든 코드를 리뷰하는 Google
•
Google은 코드 리뷰 개발자 가이드(Introduction)를 통해 코딩 스타일을 비롯한 주요 원칙을 공개하고 있습니다. (한글 번역본 : Review · Soojin Ro )
•
Google은 코드 리뷰가 요청되고 나서 1영업일 이내에 반드시 코드 리뷰가 완료되어야 하는 것을 원칙으로 합니다.
◦
심지어 다음 날 아침 최우선 업무로 이것을 처리해야 한다고 규정합니다.
◦
왜냐하면 코드 리뷰가 늦어지면 팀 전체의 개발 일정이 문제가 될 정도로 코드 리뷰를 100% 강제하고 있기 때문입니다.
◦
Google의 코드 리뷰는 작은 변경은 1시간 이내, 규모가 큰 변경사항은 5시간 이내 검토가 완료됩니다. 평균적으로 4시간 이내에 완료된다고 합니다.
•
Google의 코드 리뷰의 90%는 10개 미만의 파일로 구성되어 있고, 리뷰의 75%는 리뷰어가 한 명뿐입니다.
◦
변경 요구사항(Change List; CL)의 규모가 크고, 코드 리뷰 대상이 크면 클수록 코드 리뷰 시간은 길어지기 마련입니다.
◦
그래서, Google에서는 변경사항의 전체를 조망해 보고, 주요 부분을 작게 나누어 리뷰할 수 있도록 CL을 여러 개의 CL로 분할한 다음 적절한 순서로 살펴보도록 권장하고 있습니다.
•
Google은 Tricorder라는 정적 분석(잠재결함 분석) 도구와 Rosie라는 코드 정리 시스템(Large-Scale Cleanups and Code Changes)을 활용해 사용하지 않는 코드는 없애고, 리팩토링(Refactoring)이 필요한 경우에는 수정된 코드를 개발자들에게 리뷰 요청하는 것으로 알려져 있습니다.
마이크로소프트
개발자 업무는 개발 50%, 리뷰 50%인 Microsoft
•
Microsoft의 개발자라면 매일 코드 리뷰를 해야 합니다. Microsoft의 전체 직원 수는 14만 명이고, 이중 44%인 6만 명에 이르는 개발자의 75%가 매일 코드 리뷰를 하고 있다고 알려져 있습니다.
•
다른 회사들처럼, Microsoft도 자동화된 코드 리뷰 도구인 Codeflow를 통해서 코드 리뷰를 진행해 왔습니다.
◦
다만, Microsoft에서는 팀별로 자유롭게 자동화된 검토 도구를 활용할 수 있고, 프로세스도 자율적으로 구성할 수 있다는 점이 다르죠. VSCode의 여러 코드 리뷰 플러그인과 GitHub, Visual Studio Teams Service를 활용하는 등 다양한 방법을 선택할 수 있습니다.
•
Microsoft에서는 개발자들 간에 코드 리뷰의 코멘트를 명확히 이해하고 전달할 수 있도록 이모지(Emoji)를 활용하기도 합니다. 이모지를 통해서 텍스트만으로 전달하면서 발생할 수 있는 감정적인 싸움이나 소모를 예방하기도 하죠. 이를 통해서 코드 리뷰를 하는 상대방에 대한 배려를 잊지 않도록 역할을 하고 있습니다.
네카라쿠배
•
자동화된 배포와 테스트는 이제 기본기 중의 기본기가 되었습니다. 테스트 기반의 코딩인 TDD(Test Driven Development)를 필수로 적용하고, 코드 Merge 전에 코드 리뷰는 필수적인 프로세스가 되었죠.
•
국내 IT 선도기업들은 회사에서 표준을 제공하기보다는 팀 상황에 맞추어 자율적으로 코드 리뷰 방법을 결정해서 자율적으로 적용하고 있지만, 대부분의 회사는 GitHub에서 제공하는 PR(Pull Request)을 활용해서 리뷰 요청과 검토를 완료(Approve)하는 방식으로 코드 리뷰를 진행합니다.
•
코드 리뷰 진행 이전에 Unit/UI 테스트와 정적 분석을 통해 문제점을 도출한 다음 코드 리뷰를 진행하는 카카오는 자체 개발한 TestBot을 통해 Code Smell과 Bug, Vulnerability 등의 문제를 분석하여 알림으로 제공해 줍니다.
•
코드 리뷰 진행을 위한 자체 Chrome Extension을 개발해 코드 리뷰가 필요할 때마다 코드 리뷰어를 자동 할당하여 리뷰하도록 하고 있습니다.
•
Discourse를 이용한 코드 리뷰 토론과 정보 공유가 이뤄지는 포털을 통해 온라인 커뮤니케이션을 하지만, 중요한 모듈의 코드 리뷰는 오프라인에서 모여서 진행하는 방식을 선호한다고 합니다.
•
최근 국내 기업의 코드 리뷰 트렌드는 단편적인 코드의 성능과 문제점만 보거나 버그 발생 가능성만 검토하는 것이 아니라, 전체적으로 일관적인 아키텍처를 유지하고 있는지와 기술적인 지식과 노하우를 공유하며 함께 성장할 수 있는지, 그리고 맥락(Context)과 히스토리를 누가 보아도 인지할 수 있도록 개발되고 설명이 되지는지를 코드 리뷰 과정에서 살펴본다고 합니다.
◦
쉽게 얘기하자면, 코드 리뷰가 소프트웨어 검수 절차와 품질 프로세스라기보다는 개발자와 회사가 함께 성장할 수 있도록 하는 수단으로 여겨진다는 겁니다. 코드 리뷰의 결과물은 지식 자산으로서 회사에 남게 됩니다.
◦
그래서, 리뷰 마스터 제도를 도입하여 리뷰를 독려하고, Merge 권한도 전문가에게 부여하는 등의 활동이 중요시되고 있습니다.
‘테스트 없는 코드는 없고, 리뷰는 당연하다’는 인식이 일반화되어가는 지금, 코드 리뷰 방식에서 장점은 취하고, 특성은 살리는 방식을 찾아가는 과정이 필요할 것 같습니다.
좋은 PR 남기기
좋은 Pull Request가 중요한 이유
Reviewer resource is very limited, treat it wisely!
(리뷰어는 매우 제한되어 있으니 그들을 현명하게 다룹시다!)
•
LINE Engineering Blog
•
PR의 단위와 내용이 중요한 이유는 Pull Request를 통해 코드 리뷰를 받기 위해서입니다.
•
코드 리뷰를 통해 팀원 간의 코드 스타일을 맞출 수 있고, 직접 코딩할 때 발견하지 못 했던 위험도 발견할 수 있습니다.
•
그래서 코드 리뷰를 하는 리뷰어도 우리와 같은 개발자라는 사실을 잊어서는 안됩니다..
•
PR의 내용만 보고서도 변경 사항에 대해 충분히 이해할 수 있고, 원하는 부분이나 토의해야 할 대해 명시하는 PR이 좋은 PR이라고 생각합니다.
PR 크기와 해결 시간
동그라미 크기와 색상: 변경되는 세트의 크기(코드 라인 수)
해결에 걸린 시간(Resolution time): PR 생성 후 머지(merge)될 때까지 걸린 시간
#번호: PR 번호
•
많은 IT 회사들에서는 PR의 크기를 작게 유지하기 위해 노력합니다.
•
사진에서도 나와있는 것 처럼, 하나의 PR에 소모되는 시간이 줄어들고, 빠른 피드백과 빠른 수정이 가능합니다.
•
개발을 하고 있다가 팀원의 코드 리뷰가 도착했을 때 PR이 너무 크다면, 피드백 해야 할 내용이 너무 많다면? 리뷰어의 에너지라는 리소스가 소모됩니다..
•
또한 피드백을 통해 고칠 내용이 많아지고, 또 그 내용을 다시 리뷰해야 한다면 코드의 작업 속도도 느려집니다.
•
그래서 Cisco는 300줄 ~ 400줄을 권장하고, 뱅크샐러드에서는 최대 1000줄의 줄 수 변경이라는 제한을 두고 있습니다.
큰 PR이 왜 좋지 않은지는 아래의 링크를 참고할 수 있다
https://smallbusinessprogramming.com/optimal-pull-request-size/
PR에는 어떤 내용이 들어가면 좋을까?
리뷰어가 코드의 문맥을 빠르게 파악할 수 있도록 PR의 내용에서 충분한 정보를 전달해야 합니다.
•
무슨 이유로 코드를 변경했는지
•
어떤 위험이나 장애가 발견되었는지
•
어떤 부분에 리뷰어가 집중하면 좋을지
•
테스트 계획 또는 완료 사항
•
관련 스크린샷
PR Template
1.
리뷰어에게 이 PR이 왜 필요한지 히스토리와 Context를 공유합니다.
2.
중점적으로 리뷰할 부분을 명시함으로써 해당 코드에서 생길 수 있는 버그를 사전에 발견합니다.
3.
테스트 결과를 첨부함으로써 코드에 대한 신뢰도를 올려줍니다.
.gitlab/merge_request_templates/default.md
## PR 유형
- [ ] Feature
- [ ] Bugfix
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:
## 개요
## 코드 리뷰시 참고 사항
## 테스트 결과
(스크린샷)
Markdown
복사
Branch 전략
프로젝트의 Git 브랜치를 효과적으로 관리하기 위한 워크플로우
Git Flow, Github Flow, Gitlab Flow 관심도 변화
Github Flow
Github Flow 특징
•
Github Flow는 Git Flow에서 develop, release, hotfix 브랜치를 제거한 형태다.
•
Git Flow가 Production 환경에 여러 버전을 관리하고 있는 제품을 위한 전략이라고 하면, Github Flow는 Production 환경에 단일 버전이 있는 제품을 위한 전략이라고 볼 수 있다.
•
배포를 위한 Release 브랜치를 따로 관리하지 않고 Hotfix도 마찬가지다. Github Flow에서는 Mainline을 main(master)라고 부르고, 개발자는 작업을 feature 브랜치에서 한다.
•
Github Flow는 Git flow에 비해서 Release를 위한 절차가 굉장히 줄어들기 때문에 수시로 배포가 일어나는 애자일 조직에 적합한 전략이라고 볼 수 있습니다. 그리고 여러 버전을 동시에 관리할 필요가 없는 Middle급 조직에 어울리는 전략이기도 하다.
Github Flow 주의할 점
작업도 마찬가지로 Feature 브랜치에서 하니까 Git Flow에서 develop, release, hotfix 브랜치만 제거하면 Github Flow와 똑같다고 생각했는데, 인지해야 할 중요한 점이 하나 더 있다고 생각한다.
Git Flow 뿐만 아니라 모든 브랜치 전략에는 Mainline이 존재하는데, Mainline은 모든 작업(Feature)의 시작점을 의미한다. Git Flow는 develop 브랜치가 Mainline이고, Github Flow는 main 브랜치가 Mainline이다. 그리고 언제 배포해도 상관없는 Stable 브랜치가 Release 형태로 분리되어 있는 Git Flow와 다르게, Github Flow는 배포 브랜치와 작업을 시작하는 Mainline이 동일한 main 브랜치를 사용하고 있다.
즉, Github Flow 전략에서 main 브랜치는 main line의 역할과 동시에 Stable 해야 한다.
따라서, Github Flow를 사용하는 팀원 모두는 main 브랜치가 항상 Stable 해야 한다는 명시적 혹은 암묵적 합의가 필요하다. Github Flow 전략을 사용하고 있는데 릴리즈에 포함되면 안되는 피쳐가 main 브랜치에 존재한다면 의도치 않은 장애로 이어질 수 있다.
Git Flow
Git Flow 특징
•
Git Flow는 Vincent Driessen이 2010년에 제안한 Branch Model을 기반으로 만들어졌으며 현재는 많은 기업에서 표준으로 사용하는 브렌치 전략이다.
•
Github Flow와는 다르게 크게 5개의 브렌치를 운영하며 관리한다.
◦
Main Branch : master(main), develop
◦
Sub Branch : feature, release, hotfix
•
명확한 릴리즈 기간과 주기적인 버전이 정해진 프로덕트를 개발하는 환경에 적합하다.
•
릴리즈 버전 관리를 위한 release 브랜치를 따로 관리하기 때문에, 특정 버전에 대한 유지보수, 배포 기간이 길고, 여러 버전을 동시에 관리해야 할 필요가 있을때 유용하다.
•
2, 3과 같은 장점 때문에 소규모 팀보다는 규모가 있는 팀에 더 어울린다.
Branch 소개
Main Branch (master, develop, qa) : 항상 유지되는 메인 브렌치
Sub Branch (feature, hotfix) : 일정 기간 동안만 유지되는 보조 브렌치
•
master : 제품으로 출시될 수 있는 브랜치
•
develop : 다음 출시 버전을 개발하는 브랜치
•
feature : 기능을 개발하는 브랜치
•
release : 이번 출시 버전을 준비하는 브랜치, 코드를 검수하고 수정하는 브랜치
•
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
전체적인 흐름
1.
처음에는 master와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 master에서부터 시작된 브랜치입니다.
2.
develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다.
3.
feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다.
4.
develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다.
5.
QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다.
6.
마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.
