기억 파편

팀 내에서 코드 리뷰를 하고 있지만 어떻게 하는 것이 서로에게 좋은 시너지를 낼 수 있는 방법인지 확신이 서지 않을 때가 많았다. 누구 하나 가이드를 주지 않고 작성하다 보니 종종 의도하지 않은 상처를 준다거나 상처를 받았던 경우가 생기는 것 같아 더 나은 협업을 위한 방법을 모색하게 된다.

아래 영상은 그 일환으로 시청했던 것인데 매우 유익하고 공감 가는 내용이 많아서 정리하려고 한다.

1. 효율적인 코드 리뷰하기

코드 리뷰의 어려움:

• 생각을 글로 전하는 것에 대한 어려움, 피드백을 조심스럽게 표현하는 것이 더 중요.

팀 내의 노력:

• 지루한 작업은 컴퓨터로 처리(공백, 들여 쓰기 등)
• 스타일 가이드를 통해 스타일 논쟁 해소
• 모두를 포함하라

저자의 노력:

• 의미 있는 커밋으로 분리(나중에 나의 코드조차 낯설다, 커밋도 로그, 잘 정리하면 미래에 모두에게 도움이 된다)
• pr 올릴 때 주석 달기
• 저자가 먼저 읽어보고 -> 리뷰어들을 위한 설명을 코멘트로 남겨서 -> 리뷰어들의 시간을 절약할 수 있게 하라
• pr은 적게(반나절 작업한 정도) 자주 올리는 게 좋다(리뷰할 시간이 없다고 생각하면 안 됨)

리뷰어의 노력:

• 리뷰는 즉시 시작하라
• 고수준 피드백(버그, 장애, 성능, 보안)에 대해 먼저 잡고 -> 저수준 피드백(설계 개선, 변수명, 주석 등)을 남기자
• 리뷰 라운드에서 너무 많은 의견을 남기면 저자가 당황할 수도.. 한 라운드에 20~50개는 위험의 시작.
• 한 두 등급만 코드 레벨을 올리는 것을 목표로, 완전하지는 않아도 충분히 좋은 코드가 되도록
• Nit 태그: 고치면 좋지만 아니어도 그만, 개선할 수 있는 의견을 자유롭게 남길 수 있어야 함

피드백 방법:

• 진정한 칭찬이 필요 -> 우리는 잔인한 감시자가 아니라 도와주려는 팀 동료
• 피드백은 명령이 아니라 요청(나의 걱정): 하세요 XXX ~하는 게 어떨까요? OOO
• 원칙에 기반한 제안(~에 맞으려면 이렇게 하는 게 더 좋을 것 같아요)
• 항상 원칙에 기반하여 설명할 수 있는건 아니다. 이럴 땐 무엇을 할 수 있을지 객관적인 설명이 필요하다.
• 반복적인 이슈는 다 말할 필요 없다(2~3개의 예시를 언급하고 그 이상은 비슷한 패턴에 대해 수정 요구)
• 그러려니~ 하는 마인드 필요, 우리는 싸우려고 코드 리뷰하는 게 아니다. 동료와의 협업이 훨씬 중요한 것이다.
• 팀을 유지하기 위해 불완전한 해결책을 받아들여라. 모든 결함이 항상 문제가 되지는 않음
• 코드 리뷰의 목적은 비난이 아니라 배움이다.

2. git commit message structure

기본적으로 커밋 메시지는 아래와 같이 제목(subject), 본문(body), 꼬리말(footer)로 구성된다.

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

• <설명>은 50자 이내로 작성, 마침표 찍지 않는다.
• 타입에는 아래와 같은 값들이 올 수 있다.

• body는 선택사항으로 모든 커밋에 작성할 필요는 없지만 부연설명이 필요할 경우 72자 이내로 작성한다. 제목과 구분하기 위해 한 칸 띄어 쓰고 시작한다.
• footer는 issuer trackerId(이슈 문서 id 등)를 기입하는데 주로 사용된다.

참고: 더 디테일한 commit message

https://medium.com/humanscape-tech/%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9D%B8-commit-message-%EC%9E%91%EC%84%B1%EC%9D%84-%EC%9C%84%ED%95%9C-conventional-commits-ae885898e754

https://haesoo9410.tistory.com/299

2-1. 커밋 시 자동으로 commit format 띄우기

아래와 같이 format 파일을 만들고 커밋을 친다. 이름은 아무거나 해도 되는데 나는 /.github/.gitmessage 로 저장하였다.

# 제목은 대문자로 시작합니다.
# 제목에는 타입,콜론,스페이스로 시작합니다.
# ex. Fix: typo in baduk.js
# 본문과 푸터는 선택 사항 입니다.
#######제목#######
Add: commit format
#######본문#######

#######푸터#######

######### 타입 #########
# Fix : 수정
# Add : 추가
# Remove : 삭제
# Simplify : 단순화
# Update : 보완
# Implement : 구현
# Prevent : 방지
# Move : 이동
# Rename : 이름변경
##################

아래와 같이 템플렛으로 지정한다는 명령어를 터미널에 입력한다.

git config --global commit.template .github/.gitmessage editor
## --global 옵션을 주면 전 프로젝트에 적용된다.

git config --unset-all --global commit.template
## 템플렛 취소

commit.template로. gitmessage라는 파일을 사용한다는 뜻이고, 마지막에 editor는 커밋할 때마다 editor가 떠서 메시지를 수정하게 한다는 뜻이다(vim으로 지정해도 된다).

이를 활용하여 커밋하려고 하면 터미널에 아래와 같은 순으로 작업한다.

git add [파일명]
git commit
## //-> 이러면 premade한 에디터가 뜨고 메세지를 수정 후 :wq 로 저장하고 나온다.
git push

이 방법의 문제는

1. 개개인별로 설정해야 한다. 팀에 일괄 설정 안 됨
2. 터미널에서밖에 안된다. git kraken이나 sourcetree 같은 툴에서는 주석이 먹지 않아서.. 매우 번거로워진다.

참고로 한글로 메시지를 쓸 경우 깨지는 경우가 허다.. 해서 아래와 같은 추가 노력이 필요할 수 있다.

https://velog.io/@haejung/Git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80%EB%A5%BC-%EC%9C%84%ED%95%9C-Editor-%EC%84%A4%EC%A0%95-5072

3. git pr format 생성

좋은 코드 리뷰란?
저자가 고생해서 리뷰어의 시간을 아껴줘야

• git 자동으로 pr format 생성하는 법
• pull_request_template.md 파일을 아래 링크처럼 생성하고
• 이 파일을 git의 default branch(보통 master or main)에 커밋을 해야! 그다음부터 적용된다.

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository