적극적인 코드 리뷰 문화를 위한 조금 특별한 스터디 도입기(LG 유플러스 아이들나라)

🦡 작성자 : 혜원

🔥 인사이트 한줄 소개!

서치하다가 우연히 본 글인데 LG유플러스 아이들나라 팀이 효과적인 코드 리뷰를 위해 우테코에서 아이디어를 얻어 “미션 스터디”를 도입한 내용이에요 👀 우테코의 프리코스와 거의 유사하지만, 필력도 엄청 좋고 내용도 흥미로워서 가져와 봤습니다!! 특히 리뷰이/리뷰어를 위한 규칙 부분은 제가 평소에 지키지 못하고 있는 부분이 많은 것 같아서 반성하게 되었네여,,,

복붙이 안 되어서 아래는 제가 따로 정리한 내용이에요…!!

🔎 본문 내용

• 리뷰를 해 주는 쪽은 확증 편향으로, 리뷰를 받는 쪽은 동기 추론 편향으로 효과적인 코드 리뷰가 이루어지지 않을 수 있다!

→ 코드 리뷰의 필요성을 깨닫게 하는 게 중요할 것 같아, 우테코 등을 참고해 사내에서 미션 스터디 진행

• 쉬운 난이도의 미션을 진행하면서 기존에 자신이 생각했던 좋은 코드와 좋은 테스트를 적극적으로 작성하고, 이를 리뷰하면서 더 나은 코드로 다듬는 것과 동시에 새로운 지식을 공유하는 효과도 기대할 수 있다

• 단계

  1. 리뷰이는 단계별 요구사항을 충족시킨 후, 리뷰어에게 Pull Request를 남김
  2. 리뷰어는 코드 품질을 높이는 방법과 리뷰이에게 도움이 될 만한 정보를 전달하기 위한 적극적인 코멘트를 작성하여 Code Review 진행
  3. 리뷰이는 리뷰어가 만족할 만큼의 코드를 작성할 때까지 리뷰 내용을 반영하거나 토의 진행
  4. 리뷰어가 만족할 만큼의 코드가 완성되었다면 Approve & merge를 진행하고, 그렇지 않다면 Code Review 반복

• 필자는 미션 난이도가 쉬운 편이기 때문에, 평소 고민하던 객체지향 설계 및 TDD를 적극 시도해 볼 수 있었고, 각자 알고 있었던 프로그래밍 언어 관련 소소한 팁도 공유할 수 있었다!

• 미션 스터디를 알차게 진행하기 위해 규칙 및 가이드 설정

  • 미션 내에서 무조건 지켜야 할 객체지향 생활체조 원칙
  1. 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
     1. for 문 내부에서 if 문이 포함되는 순간 2 indenet가 된다.
  2. else 예약어를 쓰지 않는다.
  3. 모든 원시 값과 문자열을 포장(VO)한다.
  4. 한 줄에 점을 하나만 찍는다.
  5. 줄여 쓰지 않는다(축약 금지)
  6. 모든 엔티티를 작게 유지한다.
  7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
  8. 일급 컬렉션을 쓴다.
  9. 무의미한 getter/setter/프로퍼티를 쓰지 않는다.

→ 9가지 규칙을 지키면서 의식적으로 가독성이 높은 코드를 작성할 수 있고, 리뷰 코멘트의 근거가 되어줄 수도 있음

✔️ 리뷰이를 위한 가이드 → 개인적으로 이 부분이 좋았다 👀

• 시간 확보
  • 친구들과 약속을 보름 뒤로 미룬다(ㅋㅋㅋㅋ)
• 매일 1~2시간씩 미션 진행
  • 일주일에 최소 3회 이상 코드 리뷰 요청을 보내자
  • 한 번에 모두 구현하기보다 일정한 시간을 꾸준히 투자하자. 밀리면 밀릴수록 부담스럽다.
• 리뷰어의 의견을 적극 수용하자
  • 거부감이 들 수 있지만 일단 적용해 보고, 적용하기 전과 후의 코드를 비교해 본다.
  • 자신이 가진 것을 비울 때 가장 많은 것을 배울 수 있다.
• 그렇지만 리뷰어의 의견에 적극 반대도 해 보자
  • 리뷰어는 선생님이 아니라 함께 일하는 동료 개발자
  • 프로그래밍 설계와 구현에는 정답이 없다
  • 요구사항에 적합한 최선의 설계와 구현 코드를 찾기 위해 노력하고 토론하자

✔️ 리뷰어를 위한 규칙

• 시간 확보
• 매 리뷰 요청 시 24시간 내로 리뷰 진행
  • 리뷰가 밀리기 시작하면 부담이 커진다. 리뷰이들은 오매불망 나의 리뷰를 기다리고 있다!
  • 리뷰할 시간을 별도로 정해두자 (매일 아침 출근 직후, 매일 저녁 퇴근 직전 등)
• 리뷰이에게 적극적으로 의견 내비치기
  • 리뷰어는 리뷰이를 가르치는 존재가 아니다. 더 나은 결과물을 위해 아이디어를 제안하는 동료 개발자.
  • 요구사항 규모보다 극단적인 리팩터링을 제시해 볼 수도 있다. 이를 반영할지 말지는 리뷰이의 재량.
  • 리뷰이가 잘 모르는 부분에 대해서도 예시 코드와 함께 설명해 보자. 특정 지식에 대해 쉬운 문장으로 상대방에게 설명할 수 있어야 진짜 자신의 지식이다.
• 리뷰이의 코드를 평가하는 것이 아니라, 더 나은 결과물을 함께 만들기 위해 토론하는 과정임을 꼭 기억할 것.
  • 왜 개선이 필요한지 충분한 이유를 설명할 것
  • 바로 답을 이야기하기보다, 스스로 고민하고 개선할 수 있는 방법을 제시할 것.
  • 리뷰를 억지로 쥐어짜지 말 것. 할 말이 없으면 칭찬을 해라.
  • 팀 컨벤션에 포함되지 않는 사소한 스타일(성향) 차이는 가능하면 터치하지 않을 것.
• 완벽한 리뷰보다 완주를 목표로
  • 초~중반 단계에서 미션 진행이 더딜 경우, 의욕이 크게 저하될 수 있다
  • 말도 안 되는 코드를 작성했거나, 큰 규모의 리팩터링이 필요한 경우 request changed 를 남긴다
  • 사소한 코멘트로 충분하다면 다음 단계 진행과 함께 리팩터링을 진행할 수 있도록 approve 를 남긴다
  • 마지막 단계에선 만족스러운 코드가 완성될 때까지 놓아주지 말자
• “이 부분은 별도 클래스로 분리하는 게 낫겠어요” (X) ”이 부분은 반복적으로 수정하게 될 것 같은데, 별도 클래스로 분리하면 찾기도 쉽고 테스트 코드 작성도 용이해질 것 같아요.” (O)

https://github.com/mission-study-to-finish-in-15-days/kotlin-racingcar/pulls

✔️ 미션 종료일 팀이 진행한 KPT 회고

• 좋았던 점 (Keep)
  • 코틀린 관련 새로운 지식을 습득할 수 있어 좋았다
  • 코드리뷰 습관을 익히고, 잘하는 방법을 배울 수 있었다
  • 다른 파트분들과 코드 리뷰할 기회가 적었는데, 스터디를 통해 경험해 볼 수 있어서 좋았다
• 아쉬웠던 점 (Problem)
  • 리뷰이-리뷰어가 고정되어 아쉬웠다
  • 코드에 대해 더 신랄한 비판을 받지 못한 게 아쉽다
• 다음 미션 스터디에 적용해 볼 액션 플랜(Try)
  • 각 단계마다 리뷰이-리뷰어 매칭을 달리해보자
  • 각 단계가 시작할 때마다 한 자리에 모여 공유하고 이야기하는 시간을 가져보자