[Programming] - [우아한테크세미나] 코드리뷰 정리

in Programming on Programming, Xcode, Orientation


1. 왜 코드리뷰를 해야하는가?

1. SW가 모든것을 먹고 있는 시대

  • 전체 산업에서 IT비율이 2020년에 5% 2030년에 10%로 증가될것으로 보임 나머지 90%도 DT가 되어갈 것임
  • 자동차 산업도 소프트웨어 비중이 더 늘어나고 있다.
  • 인구수 대비 개발자 수를 통계적으로 보면 미국은 현재 개발자 숫자의 4배가 많아져야 IT서비스가 원활히 돌아간다고 말함

  • 한국은 미국의 3배 즉, 12배의 개발자 숫자가 증가해야 함

    ⇒ 결론적으로 소프트웨어 개발의 수요는 계속 증가될것으로 보임

  • 4차 산업 혁명 VUCA : 불확실, 복잡, 모호, 변화가 많은 시대
  • 변동성이 대두 됨
    혼자만의 방법으로 문제 해결하는 시대는 지나갔고, 협업을 통해서 문제 해결 해야함
  • 비즈니스 성공을 위해서는 개발이 더 빠르고 더 안정적으로 생산해야한다.

즉, 개발 조직의 생산성이 매우 중요해짐.

2. 라인당 비용 LOC

  • 출시 이후 점점 코드 생산성이 떨어짐. 왜?

    ⇒ 기술 부채 때문에

  • 첫 출시 이후 점점 생산적인 개발이 아니라 수정하고 버그잡는데 시간을 다 쓴다.

스크린샷 2022-05-02 오후 3.29.15.png

  1. 나쁜 설계가 특정 지점까지는 생산성이 좋다.
  2. 그러나 특이점이 지나면 좋은 설계가 아닐 경우 프로젝트가 무너질 수 있따.

3. SW 공학의 특성

  • 공학 = 설계(Design) + 빌드(Build)
    • 설계 : 예측하기 어렵고, 급여가 비싸고 창의적인 사람들이 필요
    • 빌드 : 좀 더 예측하기 쉬움
  • 설계와 빌드가 분리되어 있음
  • 건축에서는 # (90%의 비용이 건축 Build에서 발생)

  • 유지보수 비용이 상대적으로 작음

  • 소프트웨어의 공학은 좀 다름
  • 공학 활동의 최종 목적 : 재생산 가능한 문서 (Build를 할 수 있는 문서)
    • 건축에서도 도면만 있으면 어떤 팀이 와도 동일한 건물 생산 가능
  • 소프트웨어에서의 설계와 빌드는?
    • 항상 동일한 기술 문서 = 소스 코드
    • Build는 코드를 컴파일 하는 과정

    소프트웨어에서 Build는 비용이 발생하지 않는다. (컴퓨터가 해줌) 즉, 좋은 설계가 무엇보다 중요하다.

    • 좋은 설계 ~= 클린 코드

4. 클린 코드의 중요성

  • SW의 진정한 비용은 설계 비용
    • 유지보수가 전체 개발의 80% 이상
  • 한번 작성한 코드는 10번 이상 읽힘, 작성 보다 이해하기에 10배의 노력이 필요함. ⇒ 즉 한번 쓰인 코드는 타인에게 100배의 노력이 필요함
  • SW 개발의 단순한 진리
    • “The only way to go fast, is to go well” - Robert C. Martin
    • SW 품질에 신중해야한다.
  • SW의 비용과 품질의 관계는 비정상적, 비직관적
    • 높은 품질의 제품은 비싸다?, 소프트웨어에서는 꼭 그렇진 않다.
    • 향후 변경 비용을 낮춤으로 트레이드 오프를 역전시킴

    개발자들은 비즈니스적으로 왜 좋은 코드가 중요한지 설명을 해야한다. 단순히 테스트 커버리지를 높여야 합니다가 아니라 테스트를 통해 결함률을 줄이고, 일정을 당겨서 출시일을 당길 수 있다 등의 비즈니스 관점의 설명이 중요

5. SW 장인정신

  • 애자일
    • 현재 VUCA시대에는 최고의 개발 방법론
    • 하지만 실패하는 경우가 많음 왜?
      • 단순히 프로세스만 도입하려고함.
      • TDD, 리팩토링, 코드리뷰등 이러한 개발 역량도 같이 따라와야한다.
  • 지식과 경험의 공유를 통해 개발자의 역량을 끌어 올려야 한다.

6. 코드리뷰

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

2. 코드리뷰의 목적

  • 주 목적 : 품질 문제 검수 (버그, 장애)
  • 더 나은 코드 품질 : 리팩토링 비용 감소

  • 학습 및 지식 전달 : 지식을 전달하여 개발 역량 상승

    리뷰어들도 리뷰 과정에서 지식을 얻음 (하드스킬, 소프트 스킬 : 소통능력, 리더십)

  • 동기부여
    • 잘하는 사람들의 코드를 보고 동기부여
  • 상호 책임감 증대
    • 다 같이 코드 리뷰하는 시간을 통해 팀의 결속력 증대
  • 설계 개선 제안
  • 개발 문화 개선

3. 코드리뷰

스크린샷 2022-05-02 오후 3.46.34.png

스크린샷 2022-05-02 오후 3.46.55.png

PR은 작성자를 위한게 아니라 Reivew를 할 사람을 위한것 리뷰어를 고객으로 보고 작성해야함. 최대한 리뷰어 입장에서 리뷰어의 시간을 줄여준다는 목적을 가져야함.

코드 리뷰가 어려운 이유

  • 저자
    • 본인이 멋진 PR을 날렸다고 생각
  • 리뷰어
    • 왜 멋지지 않은지 장황하게 설명

⇒ 코드에 대한 비판을 자신에 대한 비판으로 이해

서로가 자기가 더 훌륭하다는 마인드로 접근하면 안된다.

  • 생각을 글로 전달하는것은 어려움, 오해의 위험이 큼

효율적인 PR 방법

  1. 지루한 작업은 컴퓨터로 처리
    • 코드를 읽는것은 고수준의 집중이 필요
    • 컴퓨터가 잘 할 수 있는 일은 자동화 (ex. 테스트, 정적 분석 등)
    • Formatting Tool : 서로 쓰는 방식이 다르면 이해하기 어려워함
      • Lint등 내규를 따르자
    • 리뷰가 필요없는 PR은 별도로 분리해서 리뷰 생략 하도록
  2. 먼저 주석을 달아라
    • PR의 저자가 먼저 읽어보고 설명을 커맨트로 남겨라 ⇒ 리뷰어들의 시간을 아껴라
  3. 많은 사람이 보면 버그를 잘 찾아낸다.

효율적인 리뷰 방법

  1. 코드 리뷰는 높은 우선순위로
    • 저자는 기다리고 있음 Blocked되 있음
    • 리뷰를 바로 하면 선순환됨
  2. 리뷰가 힘들면 더 자주해라
    • ex. 매일 아침 30분, 점심 식사후 30분을 리뷰를 위해 미리 확보
    • 반나절 정도 작업한 양을 리뷰 요청 해라

    리뷰 하는 사람의 노력도 성과로 인정해줘야 한다.

풀리퀘스트 vs 페어프로그래밍 단점 : 지연 발생 vs 생산성 감소 내부 팀원들 성향고려해서 진행해라

  1. 고수준으로 시작해서, 저수준으로 내려가라
    • 고수준 피드백부터 제한해라
      • 버그, 장애, 성능, 보안 등
    • 고수준의 피드백이 처리된 뒤에 저수준 이슈 처리
      • (선택적) 설계 개선
      • 변수명 변경, 주석을 명확히 등

      변수명은 고수준이라고 생각해도 됨( 개인차 )

  2. 저자에게 예제 코드로 선물을 주는 방법도 있다.
    • 너무 긴 예제 코드는 오히려 이대로 하세요!라는 억압되게 보일 수도 있음
  3. 범위를 존중하라
    • 현재 PR날린 범위를 벗어난 요구사항은 되도록 자제하라.
    • 예외 : PR에 기존 코드 영향을 주는 경우가 있음 ex) 삭제된 코드로 인해 쓸모없어진 함수 ⇒ 삭제 필요 등
  4. 태그 활용 : [Nit] (고치면 좋은데 안고쳐도 됩니다)
    • ex) null대신 옵셔널 쓰면 어떨까요?
    • OCP 준수를 위해 전략 패턴 도입은 어떨까요?
  5. 한 두 등급만 올리려고 해라!
    • D등급의 PR이라면 A가 아니라 C나B를 받도록 도와라
    • F : 기능적으로 틀렸거나, 너무 복잡해서 정합하기 어려울 때
      • 이럴때만 보류해라

피드백 방법

  • 절대 ‘너’라고 하지마라
    • ‘너는’ ‘왜’ ‘맨날’ 하지말아라
    • I Message 대화법 : 행동 - 결과 - 감정
    • 나를 주어로 이야기해라
    • ex) 이 코드는 혼란 스럽네요 ⇒ 내가 혼란스럽다고? 오해 가능 여지 있음 나는 이 코드를 이해하기 어렵네요 ⇒ 왜요? 라고 이유를 묻게 됨.

    공격한다고 오해할 여지를 최대한 줄여라

  • 경쟁 유발하지 말고, 팀의 생산성을 높이도록 해라
  • 비판이 아니라 학습의 과정으로 인지해야한다.
  • 건설적인 피드백이 아니면 차라리 하지말아라

  • 잘한것은 꼭 ! 칭찬해주라

    비판만 하지말고, 꼭 칭찬을 해서 동기부여를 해주어라

  • 명령 하지말고 요청해라

    • ex) 이 클래스 별도의 파일로 분리해라

      ⇒ 이 클래스 별도로 분리 할 수 있을까요?

      ⇒ 이 클래스가 너무 커지는것 같은데 괜찮을까요?

      ⇒ 이 클래스를 SRP 원칙을 준수하는게 어떨까요?

교착상태를 적극적으로 처리하라

  • 교착상태 : 요청 거부 + 승인 거부
  • 온라인으로 해결 불가 ⇒ 만나서 해결해라 (줌보다 직접 만나라)
  • 교착상태가 길어지면 관계가 나빠짐 (퇴사)
    • 되도록 그냥 승인해라 (덜 좋은 코드를 승인하는 비용이 퇴사보다 저렴하다)

추가적인 사례

  • PR을 작성한 사람과 짝 프로그래밍을 하며 어떻게 고치면 좋을지 보여주고
  • Revert
  • PR을 작성한 사람이 스스로 개선할 수 있도록 기회를 주자
    • 20분 짝 프로그래밍 / 2시간 스스로 개선
    • 그래야 스스로하는 법을 배움
  • 결정은 저자가 하도록 해라
    • 팀 정신을 유지하기 위해 불완전한 해결책을 받아들여라
    • 모든 설계 결함이 항상 문제가 되는건 아니다.

스크린샷 2022-05-02 오후 4.13.45.png

타인은 쉽게 변하지 않는다. 변할 수 있는건 너 자신 스스로이다. 너를 변화시켜 타인을 변화시켜라

스크린샷 2022-05-02 오후 4.13.34.png

새로운 툴, 방법의 도입은 고통스럽다 하지만 버티고 나아갈때 성과가 나기 시작한다.