코드-리뷰의-또-다른-접근-방법:-Pull-Requests-vs-Stacked-Changes.md

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes - 치즈(서지연)

코드 리뷰를 잘 한다는 것?

코드를 꼭 해야한다, 왜 해야한다는 이야기는 필요 없다. 당연히 해야한다는 건 공감하고 있다. 그렇다면 '잘 한다는 것?'은 무엇일까?

영철님께 배우면 된다.

좋은 코드리뷰들의 특징

• 적당한 크기의 코드 변경
  • 코드 변경이 작을 수록 작업이 명확해짐
• 작업 명확성
  • 작업이 명확할수록 리뷰어도 쉽다.
• 빠른 속도
  • 그럴 수록 모두가 빨리진다.

근데 이게 왜 잘 안되는 거지?

1. pull request 관점에서의 코드 리뷰(PR의 아쉬운점)

"댓글 기능을 만들어주세요"

댓글 생성 API endpoint 추가 -> 백엔드 로직 추가 -> 프론트엔드 댓글 컴포넌트 추가 커밋 PR을 보니 +1500/-200 라인...

작업자: 도대체 언제 리뷰해주는거야... 리뷰어: 도대체 어디부터 봐야하는거야...

작업 과정 수 많은 고민들과 커밋들이 들어간다. 그러나 실질적으로 리뷰어가 만나는 건 PR 이름과 file changed 뿐. 실제로 file changed에만 집중하는 리뷰어들이 많다.

10줄의 작업엔 많은 리뷰가 달리지만, 500줄의 작업엔 LGTM이 달린다.

작업 단위가 커지면 리뷰가 느려지고, 다른 작업과의 충돌 가능성이 높아지고 코드 롤백시 모든 작업이 함께 롤백된다. 심적 부담감 증가. 하기 싫어 상태....

2. Stacked Changes 관점에서의 코드리뷰

"댓글 기능을 만들어주세요"

커밋 흐름을 좌->우 가 아닌 상->하로 바꿔보자. 작업위의 작업, 작업위의 작업. stack changed 코드 변경 크기가 작아지고, 작업의 명확성이 높아지고, 리뷰 속도가 빨라진다. (각 커밋 = 작업마다 변경을 한 눈에 살펴볼 수 있기 때문에.)

구글의 Gerrit, 메타의 phabricator 를 통해 활용할 수 있다.

그러나 phabricator는 작년중순부터 관리가 멈췄다. 그리고 그보다 대부분 Github을 모두 사용중이기 때문에 전환이 어려울 것이다. 그렇다면 현업에서 Stack Diff를 써볼 순 없을까?

3. Graphite

open-course CLI and code review dashboard

깃헙과 친화적인 프로그램이다. 그라파이트를 사용

하면서도 기존 깃헙 사용팀에서도 동일하게 사용 가능 (자세한 사용 방법은 웹 사이트 확인해볼 것)

그럼 깃헙은 왜 이 좋은걸 안할까? 깃헙은 오픈소스, 전지구 커뮤니티. 그라파이트는 팀 내 동료, 내 옆자리. 각각이 집중하고 있는 분야가 다르다.

10줄의 변경을 10번 리뷰할 것인지, 100줄의 변경을 1번 리뷰할 것인지? 선택은 너의 몫!

4. 결론

PR: 여러 팀이 함께 작업하는 경우 잦은 리뷰 처리가 어려운 경우

Stacked Changes: 작은 변경이 많은 경우 팀 내 변경이 잦은 경우

가장 중요한건 코드리뷰는 함께하는 것, 중요한건 공감이다.