그동안 또 블로그 포스팅이 뜸했다...

메모하고 정리한 내용은 많은데, 보통 나만 알아보기 편하게 적어서 최근 프로젝트로 바빴는데 이걸 기존 포스팅 처럼 블로그에 올릴 수 있는 문체로 바꾸고 다듬으려니 엄두가 나지 않더라ㅋㅋㅋ
그래서 이 문제를 다시 차차 극복하기 위해 '우선 가공되지 않은 글일지라도 먼저 올리고 차차 수정해나가는 식으로 라도 하는게 낫지 않을까'라는 생각이 들어 앞으로는 원본 날 메모에서 약간 소스만 친 1차 가공 내용도 올려보고자 한다.

그 첫번째는 9월 1일 참석한 '코드 품질 향상을 위한 Code Review' 세미나의 정리 내용이다.

코드 리뷰 도입이 힘든 이유

꼭 필요한 과정. 하지만 처음 도입하는 과정이라면 굉장히 어렵다…

코드 리뷰를 하는 리뷰어 입장과 받는 입장을 모두 알아보겠다

그거 하고 있을 시간이 어딨어?

코드 리뷰가 개발 과정의 병목이라는 주장

“리뷰 하나씩 다 보고 있으면 티켓 처리가 느려진다.”
“지금은 과하고, 나중에 문제 있을 때 수정하자.”

나 하나 쯤이야…

코드 외적인 요인으으로 유야무야 되버리는 리뷰들

“혹시 이걸 지적하면 상대가 마음 상하지 않을까?”
“나보다 경력자인데 내가 리뷰를 하는게 맞을까? 이상한 걸 짚었다고 생각하지 않을까?”
“나 말고도 다른 사람들이 봐주겠지…”

ㅁㅁ님은 항상 이렇게 하시더라구요

리뷰 안에 상대방에 대한 비난이나 공격이 포함되는 경우
제발 꼽 주는 방식으로 말하지 말자. 이렇게 되면 상대는 당연히 방어적이되고 반발이 나올 수 밖에 없다.

A : “습관적으로 이렇게 짜시던데, 옳지 않은 것 같아요.”
B : ”그건 상황에 따라 다른거 아닌가요? 취향 차이의 문제이지 옳고 그름의 문제는 아닌 것 같아요.”

코드 리뷰를 해야하는 3가지 이유

1. 제품의 품질의 전반적인 상승과 보존

• 설계/구현/배포 잠재 오류를 사전에 발견하고 제거할 수 있음
• 여러 사람이 보았기 때문에 문제 발생 시 해결 속도가 빨라짐(내 코드가 아니더라도)

2. Bus Factor의 최소화

• Bus Factor = 프로젝트가 잘 진행되기 위해 꼭 필요한 사람 수. 같이 일하던 동료가 버스 사고가 나더라도 팀원들이 커버해서 프로젝트를 무사히 진행시킬 수 있는 인원을 말한다.
• Context Sharing을 통한 엔지니어 가담 가능성 상승

3. 엔지니어링 업무의 효율화

• 각자 다른 개인의 방식을 팀의 방식으로 합의 시키는 과정
• 서로 다른 코딩 컨벤션부터 전반적인 설계 원칙까지 점진적으로 싱크

우리 팀에 올바른 코드 리뷰 문화 정착시키기

☝🏻 두 가지 방향에서의 노력이 필요

• 코드 리뷰를 받는 사람의 노력 ⭐⭐⭐⭐⭐
• 코드 리뷰를 하는 사람의 노력 ⭐⭐⭐

코드 리뷰를 받는 사람의 자세

리뷰받을 준비를 잘 하는 것이 리뷰 자체보다 더 중요

⇒ 코드 리뷰의 부담은 줄이고, 효율성은 높이고

1. Git을 똑바로 사용하자.
2. 리뷰 받을 준비가 된 PR을 만들자.

Git부터 똑바로 사용하자

깃을 관리하는 방법을 조직적으로 약속하고 관리

• 어떤 코드가 어디에 있을 것인지 직관적으로 알 수 있게 한다.

• 리뷰어가 리뷰를 시작하기 전에 Context를 빠르게 이해하고 준비하도록 돕는다.

• 팀 내 Branch 관리 전략 준수

  • Git-flow, Github-flow, GitLab-flow, …
  • 팀에 어울리는 하나의 방법을 정해 합의하자

• Commit Convention

  TYPE: SUBJECT

  [BODY]

  [FOOTER]

  • TYPE의 종류
    • build
    • ci
    • docs
    • feat
    • fix
    • pref : 성능 개선 변경
    • refactor
    • style
    • test
    • chore : 레포 관리를 위한 단순 작업

리뷰받을 준비가 된 PR을 만들자

리뷰어의 시간은 소중하다. 당연하게 여기지 말자.

1. CI 파이프라인 통과

   개인의 코드가 인정받기 위한 최소 조건이자, 리뷰어가 굳이 보지 않아도 될 당연한 문제들을 없애주는 역할

   • Formatter, Type Checker(컴파일 오류) 등 팀이 합의한 기준 통과 확인하기
   • Unit Test 코드 모두 통과 확인하기

2. PR의 크기를 조절하자

   File Changed가 너무 많으면 리뷰를 보는 사람이 너무 피곤함

   프로젝트 다 끝나고 코드를 한번에 올리는 문제

   충분히 고민할 수 있는 문제도 대충 넘기게 됨

   적당한 크기의 PR을 세팅하고 꼼꼼하게 리뷰 받자!

   • 리뷰어 설정시 팁! 개인 별 지정도 가능하지만 팀 리뷰어 지정도 된다. 팀 리뷰어에서 랜덤이나 특정 규칙에 따라 리뷰어가 선택되도록 할 수 있다.
   • 특정 수의 approve를 받아야만 머지가 되도록 해서 함부로 머지 되는 것을 방지할 수 있다.
   • 특정 코드가 수정되었을 때 꼭 리뷰해야하는 사람 지정 가능. Code Owner
     파일 혹은 디렉토리 단위로, 사람 또는 팀 지정 가능

3. Self-review

   리뷰 보내기 전에 내가 먼저 리뷰하자

   코드를 작성할 때 고민했던 다른 대안, 내가 생각하는 문제점 등을 미리 코멘트로 달아 전달하자.

   고민을 먼저 제시하여 더욱 효율적이고 풍부한 리뷰 가능

코드 리뷰를 하는 사람의 자세

“코드만” 리뷰하는 것이 아니다.

코드 리뷰의 진정한 가치를 뜰어올리는 3가지 제안

1. 모든 것이 리뷰의 대상이다

풀고자 하는 이슈를 잘 해결했는지?

• 전반적인 로직 구성과 대안 검토는 당연(비즈니스 문제)
• 풀고자 하는 문제와 미래에 올 상황에 대한 고민 역시 해야함(금방 사라질 수 있는 임시 코드인데 너무 추상화를 한다던지)

내 지식은 공유, 책임은 서로 나눈다.

• 그 코드를 가장 잘 짤 수 있는 방법을 다각도에서 공유
• 그 코드에 대한 Ownership은 공유해서 문제에 함께 대응

2. 리뷰를 두려워하지 말자

Request Change를 두려워하면 안된다.

• 코드를 더 좋게 만들기 위한 의지가 있음을 서로 믿어야 함. 그렇기 때문에 솔직하게 이야기하고 건강하게 충돌하자.

사람이 아닌 코드와 현상을 비판한다는 합의를 전재한다.

• 이 리뷰가 나에게 하는 인신공격이나 비난이 아님을 알고 상처받지 말자.
• 조직 전체가 효율적으로 소통하고 더 생산적으로 일하자는 약속

3. 상대방을 존중하고 좋은 부분은 칭찬하자

지적 사항이 없을 때도 찾아서 쓰려고 하지는 말자

• 그냥 Approve만 한다고 대충 리뷰하는 것이라고 생각하지 말자. 괜히 잘 쓴 코드를 다시 보고 망가뜨리는 일이 될 수 있다.

서로 존중하고 칭찬하는 문화를 유지하자

• 끈끈한 팀워크는 엔지니어링 팀에 큰 효용을 가져다주는 특성
• 양성 피드백은 그 개발자의 의지를 북돋아 더 나은 퍼포먼스를 내게 한다.

정답이라는 건 없다!

코드 리뷰는 “문화”다

나 혼자 해서는 안되고, 팀 전체가 그에 맞게 이해하고 움직여야만 잘 할 수 있다.

그렇기에 서로 다른 팀은 서로 다른 문화를 지닌다.

우리 팀에 맞는 방법을 먼저 찾아서 제안해보자

코드 리뷰를 위한 문서 정리 예시

만약 코드 리뷰를 할 수 있는 팀원이 없는 상황이라면
셀프 리뷰를 생활화 하고
내 로컬에 CI 파이프라인을 구축해서 돌려보자.

혼자라도 문화를 확립해보자. 이런 문화를 만들어 나가다 팀원이 합류하면 같이 이어나가면 되고, 만약 팀원 합류가 안되더라도 내 이력서에 한 줄 추가할 내용이 되지 않겠는가?