당신의 코드리뷰가 어려운 이유

2022년 4월 24일 Velog에 작성한 글을 옮겨왔습니다.

이미지 출처

백명석님의 코드리뷰 강의를 듣고 작성한 글입니다.

코드 리뷰 목적

• 주목적은 품질 문제 검수(버그, 장애)

• 추가적인 목적

  • 아키텍처 속성 개선을 위해 코드를 개선하는 것.

  • 코드, 해결책 등과 관련된 지식 공유에 기여하기 위함.

  • 집단 코드 오너십 및 결속 증대.

코드 리뷰가 어려운 이유

• 저자는 본인이 멋지다고 생각하는 PR을 보내고

• 리뷰어는 왜 멋지지 않은지에 대해 장황한 이유를 작성한다.

• 코드에 대한 비판을 자신에 대한 비판으로 이해한다.

  • 특히 상대가 직책자라면 ?

• 피드백을 조심스럽게 표현하는 것이 중요하다.

그래서 어떻게 하라고 ?

1. 지루한 작업은 컴퓨터로 처리한다.

• 기계가 할 수 있는 것들

  • 공백, 들여쓰기 등

• 별도의 커밋, PR로 분리해 불필요하게 리뷰할 필요 없게 한다.

2. 스타일 가이드를 통해 스타일 논쟁을 해소한다.

3. 리뷰는 즉시 시작해라.

• 코드리뷰를 높은 우선 순위로 둔다.

  • 저자는 리뷰를 받을 때까지 Block 되므로

• PR의 Size와 Complexity가 중요.

  • 작고 범위가 좁은 PR ->

  • 쉽고 상쾌하게 리뷰하기 좋음 ->

  • 빠르게 리뷰 수행

• 리뷰 라운드의 최대 시간은 하루

  • 우선 순위 높은 업무로 1일 내 불가하면 다른 리뷰어를 지정한다.

  • 재지정이 자주 일어난다면, 그 팀의 일하는 속도를 고려해봐야한다.

4. 고수준으로 시작, 저수준으로 내려가라.

• 한 리뷰에 20~50개의 의견은 위험하다.

  • 초기 라운드에서 고수준 피드백으로 제한한다.

    • 인터페이스 클래스의 재설계, 복잡한 함수의 분리 등

  • 고수준 피드백 처리된 후 저수준의 이슈를 처리한다.

    • 변수명 변경, 주석을 명확하게 하는 것 등

5. 예제 코드 제공에 관대해라.

• 하지만, 너무 긴 예제를 제공하는 것은 억압적으로 보인다.

• 너무 많은 예제를 제공하는 것도 안좋아 보일 수 있다.

  • 저자가 코드를 작성할 수 없다고 생각한다는 신호가 될 수 있다.

6. 절대 "너"라고 하지 마라. (=~님도 같다)

• 리뷰의 핵심은 코드가 나아지게 하기 위한 것.

• 너라고 하는 순간 비판의 대상은 저자가 된다.

• 단어가 틀린 경우 "너 스펠링 틀렸어 00" X -> "스펠링만 정정"

• 주어만 빼라

7. 피드백은 명령이 아니라 요청으로 표현해라.

• ~해(X) / ~하는게 어떨까요?(O)

8. 의견이 아니라 원칙에 기반해서 피드백해라.

• 저자에게 의견을 줄 때는 "제안하는 변경"과 "변경의 이유"를 모두 설명해라.

• SW는 항상 원칙에 기반할 수는 없다.

  • 단지 그냥 보기 싫거나 직관적이지 않을 수도 있음.

  • 무엇을 할 수 있을지 객관적으로 설명해라.

    • 이거 너무 혼란스러워(X)

    • 이건 이해하기 어렵다(O)

9. 한 두 등급만 코드레벨을 올리는 것을 목표로 한다.

• D 등급이면 C나 B 등급을 받도록 도와라.

  • Working effective with legacy code

• Make it work, make it right, make it fast.

  • 첫번째만 필수고 나머지는 추가적인 것.

• 완전하지는 않아도 충분히 좋은 코드가 되도록 하면 된다.

  • 승인을 보류하는 유일한 이유는 수차례 리뷰 후에도 코드가 F인 경우

10. 반복적인 패턴에 대한 피드백을 제한한다.

• 2~3개 정도만 언급하고 끝낼 것.

• 개별 사례가 아닌 패턴으로 언급할 것.

11. 리뷰의 범위를 존중한다.

• PR 범위에 대해서만 언급해라.

  • 하지만 PR이 둘러싼 코드에 영향을 미칠 경우엔 언급한다.

12. 큰 리뷰를 잘게 나눌 기회를 찾아라.

• 400 라인 이상 리뷰는 작게 분리한다.

• 분리를 위한 논리적 경계를 식별해 짐을 덜어준다.

• 여러 파일에 걸쳐 변경했다면, 파일별로 리뷰를 나눠라.

• 코드 품질이 낮을 때 특히 리뷰 분리를 강조한다.

  • 품질이 낮은 코드 리뷰는 라인이 늘수록 리뷰하기 어려워지기 때문

13. 진정한 칭찬을 해라.

• 잘못된 부분만 리뷰하지 말고 긍정적인 행위에 대해서도 PR 해라.

14. 사소한 이슈만 남았다면 승인해라.

• 모든 comment가 수정되는 걸 확인하고 나서야 승인하지 않아도 된다.

• 중요한 comment가 완료되었다면 승인해도 된다.

• 아래 조건 중 하나라도 만족되면 승인한다.

  • 더 이상 comment가 없을 때

  • 남겨진 comment가 사소한 이슈일 때 (오타 등)

  • 남겨진 comment가 선택적 제안인 경우

    • ex) 높은 수준의 리팩토링 / 디자인 패턴 적용 등

15. 교착상태를 적극적으로 처리해라

• comment를 반영하지 않고 승인 거부 하는 경우.

• 저자는 comment 반영을 거부하는 경우

  • 만나서 얘기해라

  • 인정하거나 Escalate

• 인정이 불가한 경우

  • 팀장이나 테크 리더에게 Escalation을 권유한다.

  • 다른 리뷰어에게 할당

좋은 리뷰어가 되기 위한 방법

• 학습, 연습 뿐이다.

• 사례를 공유한다.

• Letter Grade

  • Make it work / right / fast : working 할 정도로만 해라

• PR Template(Chrome Plugin 등)을 사용해라.

안하는 사람들을 어떻게 해야할까

• 자신에게 이득이 되어야 한다.

  • 멋져보여야 하고 싶어진다. 그게 뭐든

• Refactoring Tip을 공유한다.

Code Review 문화 정착의 어려움과 극복 방법

• On / Offline의 차이에서 오는 어려움

  • 꾸중 vs 토론

    • Online에서의 토론이 꾸중처럼 느껴질 수 있다.

• Author의 노력

  • 작성자의 노력이 제일 중요하다.

  • 어떻게 작성하느냐에 따라 다수의 리뷰어의 시간을 절약하고, 효과적인 리뷰가 가능하다.

• Leader의 관심과 의지가 필요하다.

• 코드 비난에 대한 두려움 -> 나에 대한 비난이 아니다.

PR 효과

• 예상 못한 버그를 타 프로젝트에서 발견하기도 한다.

• 선플이 달리기 시작함.

• 많은 사람이 코드를 보고 있다는 생각에 PR 올리기 전 코드를 더 다듬게 된다.

• 좋은 설계, 아키텍처, 클린코드, TDD 등에 대한 공감대가 형성된다.

기타

• 변경 내역이 많으면, 커밋을 의미있게 나눠서 한 경우 커밋 단위로 봐달라고 요청을 하자

  • 그래도 잘라서 올리자 200-400자 내외로