OKKY 코드리뷰 노하우 세미나입니다. 이 글도 회사문서에만 올려놓고 개인블로그에는 올려놓지 않아 드디어 올립니다ㅎㅎ도움이 됐으면 좋겠네요:)

발표자는 누구?

우리는 지금 어떤 시대에 살고 있을까?

  • 소프트웨어에 의해 운영되는 제품과 서비스들의 영역이 늘어나고 있다. 즉, 소프트웨어가 매우 중요한 시대에 살고 있다.
  • DT는 Digital Transformation. 디지털로 전환하는 것
  • 개발자의 증가속도가 매우 빨라지고 있다.
  • 우리나라는 개발자가 더 많아져야 한다. 2020년 인구수 대비 개발자 수를 통계 낸 것이 있는데 우리나라가 미국과 유사한 비율로 개발자 수가 비슷해지려면 현재보다 12배나 많아져야 한다고 한다.

우리는 개발자가 매우 중요한 시대에 살고있다

이런 시대에 개발 생산성을 높이려면?

  • 출시 횟수가 증가할수록 개발자 수는 많아지지만 생산성은 떨어지고 있다.
  • 즉, 개발 조직의 성능(생산성)이 중요해지고 있다.
  • 일정한 기간 내에 설계 품질을 떨어뜨리고 어떤 목표를 달성할 수 있다면 그건 의미가 있음. 그러나 시간이 지날수록 설계 품질이 떨어지기 때문에 유지보수가 힘들어짐
  • 시간이 많이 들더라도 설계품질을 높인다면 시간이 지나도 유지보수가 쉬움(기술부채도 많이 없음)

개발 생산성을 높이려면 좋은 설계, 클린한 코드가 중요하다

SW 공학의 특성

  • 개발 생산성을 위해 클린 코드는 매우 중요함
  • SW의 비용은 유지보수 비용이 훨씬 높다.
    • 한 번 작성한 코드는 10번 이상 읽는다. 작성보다 이해에 10배의 노력을 소요한다.
    • 90% 이상의 시간을 어떤 코드를 이해하는데 사용한다.

원래있던 코드를 이해하는데 시간을 가장 많이 소모하므로 클린코드는 더더욱 중요하다.

  • SW 개발의 단순한 진리
    • The Only way to go fast, is to go well - Robert C.Martin (클린코드 쓴 사람)

코드리뷰란?

  • 개발자가 지금부터 당장 할 수 있는 공유 활동
  • Code SNS 댓글 놀이
  • 배움을 주고 받으며 지속가능한 SW 개발자가 될 수 있는 실천법

코드리뷰를 왜 할까?

  • 품질문제 감수(버그, 장애)
  • 더 나은 코드 품질. 향후 변경 비용 개선
  • 학습 및 지식 전달. 코드, 해결책 등과 관련된 지식 공유에 기여
    • 공유를 통한 역량 증대 및 성장
    • 참여한 모든 사람들의 배움의 기회
    • 리뷰어도 리뷰 과정에서 지식을 얻게 됨(하드스킬, 소프트스킬)
    • 동기부여
  • 상호 책임감 증대
    • 작성자 뿐만 아니라 리뷰어도 책임감이 생김
    • 내가 하고 있는 일에 관심을 가져주는 것
    • 팀에서 일어나는 일을 공유하는 것. 내 동료는 무엇을 하고 있나?
  • 개발 문화 개선
  • 설계 개선 제안

이렇게나 좋은 코드리뷰는 어떻게 할까?

  • 저자, 리뷰어, PR
  • 여기서 가장 중요한 건 저자다. 저자가 고생해서 리뷰어의 시간을 아껴줘야 한다. 커밋 메시지 대충쓰고, 1줄만 쓰고 이러면 안된다.
  • 풀리퀘스트에 들어가는 정보를 통해 리뷰어의 시간을 줄일 수 있도록 해야한다.

이렇게나 좋은 코드리뷰를 왜 안 할까?

  • 코드리뷰할 시간이 없다
  • 생각을 글로 전달하는 것에 대한 어려움(음성 톤, 표정의 부재 등…)이 있다.
    • 예시를 들어보자
      • 저자
        • 본인 생각에 멋지다고 생각하는 PR을 보낸다
      • 리뷰어
        • 왜 멋지지 않은지에 대해 이유를 작성한다.

저자 입장에서 효율적인 PR 방법은 어떤 게 있을까?

  • 지루한 작업(Formatting 공백, 들여쓰기 오류 등)은 컴퓨터로 처리한다
    • 별도의 PR로 분리해 전체적인 포매팅을 한 번에 맞추자
  • 스타일 가이드를 통해 스타일 논쟁 해소하자(구글 스타일 가이드 착안 등..)
  • PR을 날리고 먼저 읽어본 후, 코드 조각에 Comment를 남겨서 리뷰어들의 시간을 절약할 수 있게 하자
  • 최대한 의미있는 Commit으로 분리하자
    • 본인이 작성한 코드도 2주 후에 보면 남이 짠 코드같다. 그래서 커밋 로그를 잘 작성해야 된다
  • 적은 양의 PR을 올리자!

리뷰어 입장에서 효율적인 리뷰 방법은 어떤 게 있을까?

  • 코드리뷰는 PR이 올라온 즉시 시작하자
    • 왜냐면 저자는 PR을 올리면 Block이 걸린다
    • 코드리뷰 자체를 높은 우선순위로 둔다면 선순환된다
  • 리뷰 라운드의 최대 시간은 하루로 잡는다
  • 고수준으로 시작해서 저수준으로 내려가라
    • 초기에는 고수준인 버그, 장애, 성능, 메서드 추출 등으로 시작해서 저수준인 변수명 변경, 주석, 설계 개선등을 이야기 하자
  • 리뷰를 한 번 할 때 너무 많은 의견을 남기면 저자가 당황할 수 있다.
    • 하나의 라운드에 20개 이상의 의견은 위험하다
  • 예제 코드를 제공하면 좋으나 너무 긴 예제는 억압적으로 보일 수 있다.
    • “아 나는 리뷰어가 다 알려줘야지 아는구나” 이런 뜻으로 보이지 않게 해야된다.
  • 리뷰의 범위를 존중하라
    • 오타가 보이더라도 현재 PR의 범위는 아니므로 지적하지 말자
  • Nit 의미를 활용하자
    • Nit이란 ‘고치면 좋지만 아니어도 그만’ 이라는 의미다
    • 즉, 저자가 이 리뷰는 무시해도 괜찮다는 의미로 사용한다
    • e.g. nit: null 대신 Optional을 쓰면 어떨까요?
  • 저자의 코드레벨을 한 두 등급만 올리는 것을 목표로 삼자
    • 코드리뷰를 한 순간에 많이 해서 바로 최상의 코드가 될 순 없다
    • 신입이 왔는데 한번에 자기 수준으로 올리려고 하지말자
  • 절대 너라고 하지 마라. (너는 왜 맨날~ 같은 소리 절대 X)
    • ~하는 게 어떨까요? 이런 게 좋은 커뮤니케이션이다
    • 비판의 대상은 사람이 아니라 코드이며 학습의 과정으로 인지하자
    • 니가 잘하니 내가 잘하니… 상관하지마라
    • 항상 조심스럽게 표현하자
  • 칭찬도 코드리뷰에 담자
    • 대부분의 리뷰어가 잘못된 부분에만 집중하는데 리뷰는 긍정적 행위 강화를 위한 값진 기회이기도 하다.
    • 오 이런 API가 있나요! 유용해요! 정말 좋은 해결책이네요. 감사합니다! 등등…
  • 피드백은 명령이 아니라 요청으로 표현해라
    • 이 클래스를 별도의 파일로 분리하라 → 이 클래스를 별도의 파일로 분리할 수 있을까요? → 이 클래스가 너무 커지는 것 같은데 괜찮을까요?
  • 의견이 아니라 원칙에 기반하여 피드백하라
    • 코드 변경을 제안할 때 변경의 이유를 설명하라.
    • 이 클래스를 2개로 분리해야해요 → 지금 이 클래스는 2가지 책임을 가지고 있어요. 분리해서 SRP를 준수하는 게 어떨까요?
  • 가끔 교착상태가 일어날 수 있다.
    • 코멘트를 반영하지 않으니 승인 거부
    • 저자는 커멘트 반영을 거부
    • 감정싸움으로 번질 수 있다. 코드리뷰 시 최악의 상황이다.
    • 교착상태가 길어지면 관계가 나빠질 수 있으니 직접 얼굴을 보고 이야기해라
  • 어쨌거나 코드리뷰의 결정은 저자가 한다
    • 팀 정신을 유지하기 위해 불완전한 해결책이더라도 받아들일 줄 알아야 한다
    • 모든 설계 결함이 항상 문제가 되진 않는다

코드리뷰 문화 정착의 어려움 / 극복방법

  • 리더의 관심과 의지가 필요하다
  • TDD와 리팩토링을 결합해서 적용해보자
  • 일단 코드리뷰 문화를 시도해보고 피드백을 받자. 한 번에 잘 할 생각하지 말자.
  • 코드리뷰 자체를 가끔 세미나 형식으로 사례를 공유하기도 한다.

책 추천