4월 우아한테크세미나 <지속가능한 SW 개발을 위한 코드리뷰> 후기

 

 

 

이전 회사에서도 코드리뷰를 도입해서 했지만 적극적으로 참여한 것은 아니어서 여전히 '코드리뷰란 무엇인가' 상태에 있었던 찰나

우아한테크에서 이런 좋은 세미나를 열어주었다.

 

1. 왜 코드리뷰를 해야하는가?
   1. 좋은 설계의 중요성
      1. 시장은 VUCA, 이중에서도 변화 주기가 빨라지고 있어서 비즈니스는 더 빨리 혁신해야하는데 개발의 경우 빠르게, 자주, 더 안정성있게 배포되어야 한다고 말하기 때문에 개발 조직의 성능(생산성)이 중요해졌기 때문 -> 좋은 설계
      2. SW 공학에서 설계는 완전한 소스 코드고 좋은 설계는 클린한 코드, 설계를 잘하는 사람은 코드를 잘 작성하는 사람이라고 할 수 있음
      3. SW의 진정한 비용은 유지보수, 90% 이상의 시간을 어떤 코드를 이해하는데 사용함
   2. SW 개발의 단순한 진리 : 제일 빠르게 가는 유일한 방법은 잘 가는 것이다. SW 품질에 신중해야 함
   3. SW 장인정신 : 지식과 경험의 공유로 전문성을 갖춘 개발자 육성
      1. 코드리뷰 : 배움을 주고 받으며 지속가능한 SW 개발자가 될 수 있는 실천법
   4. 코드리뷰의 목적
      1. 품질 문제 검수, 더 나은 코드 품질 -> 향후 변경 비용 개선, 학습 및 지식 전달 -> 동기부여
      2. 상호 책임감 증대, 설계 개선 제안, 개발 문화 개선
2. 코드리뷰의 절차
   1. 저자 : 코드 작성, 리뷰 요청
   2. 리뷰어 : 코드를 읽고 머지 가능한지 결정
   3. 변경 내역 (PR) : 리뷰 시작 전에 작성, 저자가 머지를 원하는 소스 코드에 대한 일련의 변경(잘한 것, 아쉬운 것, 눈여겨 볼 것)에 대해 기술
      1. Description : 어떤 PR인지 간단히 기능 위주로 작성
      2. How to Test : 테스트를 어떻게 하는지 적어두기
      3. Commits : PR에 있는 유의미한 커밋 리스트
3. 코드리뷰가 어려운 이유
   1. 코드에 대한 비판을 자신에 대한 비판으로 이해 -> 물거품
   2. 생각을 글로 전달하는 것에 대한 어려움 -> 오해의 위험이 큼
4. 효과적으로 코드리뷰 하는 법
   1. 효율적인 PR 방법
      1. 지루한 작업은 컴퓨터로 처리 : 포매팅 툴로 인한 커밋은 리뷰 생략할 수 있도록 별도의 커밋이나 PR로 분리, 툴에 익숙해지자 (vsc나 intellj -> 설정으로 쉽게 해결 가능)
      2. 스타일 가이드를 통해 스타일 논쟁 해소
         1. 기존 스타일 가이드를 따르자
         2. 팀의 스타일 가이드를 만들자
         3. 둘의 관점을 섞자
      3. PR 올릴 때 주석 달기 (커밋에)
      4. 리뷰어는 최대한 팀원 모두를 포함하라 : 많은 사람들이 볼수록 버그를 더 잘 찾아낼 수 있고, 많은 사람이 본다는 생각에 더 잘하려고 함
      5. 의미 있는 커밋으로 분리
   2. 효율적인 리뷰 방법
      1. 리뷰는 즉시 시작 : 이상적으로는 5분 이내로, 리뷰 라운드의 최대 시간은 하루, 월 1회 이상 재지정을 한다면 속도를 줄여야함, 매일 아침 30분, 점심 식사 후 30분은 리뷰를 위해 미리 확보, PR에 포함된 변경이 적도록 노력
      2. 고수준으로 시작해서 저수준으로 내려가라 : 초기 라운드에서는 고수준 피드백으로 제한(버그, 장애, 성능, 보안...), 고수준 피드백이 처리된 후 저수준 이슈를 처리(선택적인 설계 개선, 변수명 변경, 주석을 명확하게 하는 것 등)
      3. 예제 코드 제공에 관대해라 : 리뷰 중에 선물 주기, 라운드당 2~3개의 코드 예제로 제한
      4. 리뷰의 범위를 존중하라 : PR에 포함되지 않은 라인은 리뷰 범위가 아님
      5. 태그를 활용 : [Nit] 고치면 좋지만 아니어도 그만, 리뷰어는 항상 더 개선할 수 있는 의견을 자유롭게 남길 수 있어야 함, 저자가 무시할 수 있도록 할 수 있음, 교육적인 목적, 지속적으로 기술을 연마하는 것을 돕는 목적
      6. 한두 등급만 코드 레벨을 올리는 것을 목표로 : D등급의 PR을 받으면 저자가 C나 B등급을 받도록 도와라, 완전하지는 않아도 충분히 좋은 코드가 되도록, 수차례의 리뷰 라운드 후에도 코드가 F 상태인 경우 승인 보류
5. Pull Request vs Pair Programming
   1. 내성적, 사색, 비동기 -> PR
   2. 외향적, 친밀한 개인적 상호 작용 -> PP
   3. 앙상블 방식도 있음
6. 피드백 방법
   1. I message 이용 : 행동 -> 결과 -> 감정, ~하는 게 어떨까요?
      1. 리뷰대로 해도 되고, 안해도 되고 자유
   2. 건설적인 피드백 : 팀의 생산성을 높이고, 역량을 증대하도록 동기부여하는 역할
   3. 진정한 칭찬
   4. 피드백은 명령이 아니라 요청 : 걱정을 전달할 것
   5. 의견이 아니라 원칙에 기반하여 피드백하라 : 제안하는 변경과 변경의 이유를 모두 설명, 무엇을 할 수 있을지 객관적으로 설명
   6. 반복적인 패턴에 대해서 피드백을 제한하라 : 동일 패턴에 대해서 2~3개 정도의 예를 언급하라
7. 교착상태를 적극적으로 처리해라
   1. 교착상태 : 코멘트 반영 안하니 승인 거부, 저자는 코멘트 반영 거부
      1. 토론의 톤이 팽팽해지고 공격적으로, 라운드당 코멘트가 줄어들지 않는 경향을 보이고 너무 많은 코멘트에 저항이 보임
      2. 만나서 얘기하라
      3. 인정하거나 Escalate하라
      4. 상황을 관리자와 논의
      5. 휴식 -> 안정될 때까지 서로 PR 보내지 않기
      6. 갈등 해결책을 학습하라
      7. 설계 리뷰를 고려하라 -> 설계 리뷰 때 논의되었어야 할 사항을 논쟁하는가? 설계 리뷰는 있었나?
      8. 아주 심각하지 않으면 인정하고 좋은 관계로 동료와의 협업을 지속해라
8. 코드리뷰를 하는 아주 재밌는 방법
   1. PR을 작성한 사람과 20분 짝 프로그래밍하며 어떻게 고치는 게 좋은지 보여주고 Revert, 2시간동안 저자가 스스로 개선하도록
   2. 결정은 저자가 하는 것 -> 저자에게 개발 외적인 문제가 생겼을 때 코드 자체가 이상하게 그날 이상할 수 있다
9. 코드리뷰 문화 정착의 어려움과 극복방법
   1. 멋져 보여야 하고 싶어짐
   2. 타인에게 영감을 주기 위해서는 모범이 되어야 한다 (영감은 부산물)
10. 코드리뷰를 잘 하기 위해 필요한 기술들 : 리팩토링, 레거시 코드 다루기, 클린 코드, TDD

 

• 생산자는 소비자를 위해 좀 더 고생해야 한다
• 팀 구성할 때 코드리뷰가 필요하다면 코드리뷰 룰을 간단하게 만들고, 그에 맞게 진행하자