코드 리뷰

코드 리뷰는 배우는 과정이기도 하다.
남의 코드를 읽으면서 습득하는 과정이기도 하고,
선배나 다른 코드를 보면서 왜 이렇게 짰는지 물어볼 수도 있는 자리이기도 하다.

잘하는 부분을 칭찬하는 것도 좋은 리뷰

• 이거 몰랐지? 라는 것도 코드 리뷰인데
• 칭찬도 좋은 코드 리뷰이다.

코드 리뷰 기다리느라 idle 타임이 없다.

태스크를 병행하면서 리듬찾기

• 한 태스크가 리뷰를 기다리는 중이라면 다른 태스크 구현을 시작한다.
• 병렬로 여러 feature 를 구현

이걸 지금 당장 완벽하게 코드 리뷰를 못하더라도 비즈니스 데이로 하루를 넘기면 안된다.

코드 리뷰를 잘 받으려면 어떻게 해야 할까?

코드 짧게 유지하기 (500~800 라인 정도가 적당)

길게 던지면... 너무 시간이 길어진다.

추상화 잘하기

• 복잡성을 단순함에 숨기기

발표할 거리를 많이 넣기

• UML, 코드 레이아웃을 설명하는 글, 최대한 많은 설명 컨텍스트로 리뷰어가 이해하기 쉽게

코드 리뷰를 잘 줄라면

• 모멸감을 주면 안된다. : 이걸 어떻게 놓쳐?? NO!
• 왜 이렇게 했는지 이해9하려고 노력 : 그래도 모르겠으면 왜 이렇게 했는지 물어봐요
  -왜 별로인지 설명할 줄 있어야 한다.
• 개선 방향을 함께 제세 : 대안 없는 비판은 코드 리뷰 절차를 더디게만 할 뿐

공통 브랜치에 합칠 땐 항상 코드리뷰 하기

내 브랜치가 아니기 때문에 꼭 코드 리뷰를 하고 merge 를 해야 한다.

• PR/MR title 에 이모지 달기

comment 에 카테고리 표시하기

nit : 사소한 지적 사항
thinking out loud : 생각나는 대로 한 번 써보는 거야
optional : 이것도 괜찮아!
questional : 물어볼 게 있어

코드 리뷰 시간 정례화

• 우리 팀은 오전에 모드 전날 올라온 코드 리뷰 요청을 처리한다.

코드를 짧게 유지하는 방법

Line of Code 가 길어질 수록 생상성은 코더는 높아지다가 낮아진다.
Line of Code 가 길어질 수록 생상성은 리뷰어는 낮아진다.

• 잘나뉜 커밋/MR 은 제목을 간결하면서도 구체적으로 작성할 수 있다.

  feature 1 개발 : 너무 많은 것이 들어가서 모르겠다..!

한 MR 에 여러 커밋을 넣는 것은 비권장하지만, 그래도 해야 한다면 커밋들이 논리적인 작업 흐름을 드러내야 함.

git add -p # 일부 라인만 커밋
git commit --amend # 커밋 메세지 수정
git reset >commit> # 커밋을 취소하지만 변경사항은 보존
git rebase -i # 커밋의 순서 변경, 제거, 메세지 수정 등