복's
[ Github ] 코드 리뷰 방법 (Code Review) 본문
요즘 코드 리뷰 방법에 대해서 계속해서 고민하다 보니까 나처럼 처음에 코드 리뷰를 시작할 때 막막할 때를 생각하며 작성 하기로 했다.
가장 좋은 방법은 Github Docs 에서 확인 하는 것이다. (한글 번역 버전으로 봐도 크게 어렵지 않음)
나는 Web browser 에서 코드 리뷰하는 방법에 대해서 내가 아는 부분에 대해서 소개 하고자 한다.
[ 📌 코드 리뷰는 어디서? ]
누군가가 PR 을 올렸다면 해당 PR 로 들어갔을 때 아래와 같이 'Commits' 탭과 'Files changed' 탭이 보인다.
둘 다 코드 리뷰를 남길 수 있는 공간인데 나는 아래와 같은 용도에 따라서 사용한다.
- Commits: 커밋별로 기능 리뷰할 때
- Files changed: 모든 코드 변경을 확인할 때
예를 들어 위 스크린샷 처럼 알고리즘 문제 풀이에 대해서 리뷰를 할 때 아래와 같이 문제별로 나눠서 올리는 경우가 있고, 다른 케이스에는 기능 단위로 커밋했을 확률이 높다.
수정된 파일이 너무 많다면 나눠서 리뷰할 때 나는 주로 Commits 탭에서 코드 리뷰를 진행한다.
[ 📌 코드 리뷰 시작 전에 ]
- 파일 목록: 변경, 수정, 삭제 등 모든 변경이 있는 파일들을 나타낸다.
- 옵션: 여러가지 옵션들이 있는데 눌러보고 필요한 옵션들을 찾아서 사용 (나는 톱니바퀴 모양에서 Diff View 는 이용한다.)
- 현황 & 리뷰 끝: files viewed 를는 밑에 노란색 영역에서 오른쪽 맨 위에 체크 박스를 체크하면 카운팅 되며, 내가 리뷰한 파일들을 체크해서 현황을 알 수 있게 하고, Review changes 버튼을 통해서 리뷰를 마무리 할 수 있다.
- 파일 상세보기: 실제로 리뷰를 하는 공간
Diff view 만 살펴보면 파일의 변경점을 쉽게 볼 수 있도록 비교하는건데, 위 스크린 샷에서는 파일이 새로 생성되었기 때문에 왼쪽 공간이 비어있다.
[ 📌 코드 리뷰는 어떻게? ]
왼쪽 '+' 버튼을 클릭하면 아래와 같이 리뷰하는 공간이 생성된다.
Github readme 작성하듯이 마크다운 언어로 작성하면 된다.
위와 같이 테스트용 리뷰를 작성했고, Preview 버튼을 통해서 미리보기가 가능하다.
이제 리뷰를 확정 지어야 하는데 버튼이 두 개 있다.
먼저 Start a review 버튼을 알아보면
보류되는 리뷰로 바로 리뷰로 등록되는게 아닌 나중에 Finish your review 버튼을 통해서 일괄로 Pending 된 리뷰들이 등록 된다.
임시 저장이라고 봐도 무방하다. (다른 페이지로 이동해도 남아있음)
다른 버튼 'Add single comment' 는 반대로 바로 적용되는 리뷰이다.
리뷰를 범위를 지정해서 하는 방법도 있는데, 코드를 제안할 때 사용하면 좋은 기능이다.
'+' 버튼을 우클릭 상태에서 드래그해서 내린 상태이다. (21 라인 시작, 26 라인 끝)
단순히 범위만 지정할 수 있지만 이 상태에서 좋은 리뷰 방법이 있는데
suggestion 이라고, 지정한 코드를 내가 원하는 코드로 보여주는 방법이다.
실제로 내가 작성했던 리뷰 중에서 가져왔는데 버튼을 누르면 위와 같이 suggestion 이 구성되고, 내부를 수정하면 원본 코드와 비교해서 내가 제안하는 코드가 보여진다.
빨간 영역은 원본 코드이고, 녹색 부분은 내가 제안한 코드 부분이다.
코드 부분만 리뷰 할 수 있는건 아니고 파일 단위로도 코멘트를 남길 수 있다.
위 말풍선 버튼을 클릭하면 코드가 아닌 하나의 파일에 대해서 리뷰를 남길 수 있는 공간도 주어진다.
[ 📌 코드 리뷰 끝내기 ]
리뷰를 다 했다면 Review cahnges 버튼을 클릭하면 아래와 같이 나온다.
해당 리뷰는 전반적인 PR 에 대해서 코멘트를 남기는 방법이다.
- Comment: 리뷰만 남길 때
- Approve: 해당 PR 이 merge 되어도 이상 없을 때
- Request changes: 강력하게 변경을 요구할 때
나의 경우에 운영하는 알고리즘 스터디에 스터디원들에게 권한을 주지 않았기 때문에 나만 Merge 작업이 가능하지만, 협업하는 공간에서 동료들의 PR 에 대한 리뷰에 따라서 반영 여부가 갈리는 부분이 되겠다.
[ 📌 마치며... ]
코드 리뷰를 기회를 가능하면 많이 만드려고 하는 중이다.
실제로 내가 일하는 곳에서는 MR(Merge Request - Gitlab) 에 대해서 코드 리뷰가 활발한 편이 아니다.
물론 코드 리뷰를 신청해서 시니어들에게 리뷰를 받는 시간을 갖을 수는 있지만, 이렇게 Github 기능을 통해서 받지는 않는다.
내가 알고리즘 스터디를 유지하는 이유는 크게 두 가지인데
- 알고리즘 감각 잊지 않기
- 소스 코드 리딩 & 리뷰
리뷰를 할 수 있는 공간을 만드는게 회사를 제외하고는 쉽지 않아서 리뷰까지 하는 알고리즘 스터디를 유지하고 있다.
물론 토이 프로젝트를 하고 있다면 리뷰를 조금 더 많이 할 수 있지만 지금은 진행하는 프로젝트가 없으니..
내가 리뷰가 어려운 이유는 정답이 없어서 인데... 리뷰를 어찌 되었든 남들이 하는걸 관찰하고, 자주 하려고 노력하다 보니까 정답인지는 모르겠지만 익숙해지고 있는 중이다.
[ 📌 References ]
github 는 Docs 가 진짜 잘 되어 있는거 같다.
끌어오기 요청에서 제안된 변경 내용 검토 - GitHub Docs
끌어오기 요청에서 커밋, 변경된 파일 및 기본 파일과 분기 비교 간의 차이점을 검토하고 논의할 수 있습니다.
docs.github.com
'형상관리 > Github' 카테고리의 다른 글
| [ Github ] Issue & PR 템플릿 만들기 (3) | 2024.09.03 |
|---|
