개발자를 위한 코드리뷰

개발자를 위한 코드리뷰

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

• 시장과 비지니스의 요구사항

  • 항상 변한다.
    • 빠르게, 자주, 안정적으로 배포 해야 한다.

• 릴리즈별 개발자 수(기하급수적 늘어남) , 릴리즈별 생산성 (늘어나지않음) , 릴리즈별 코드작성 비용 (늘어남)

• 동작 > 복붙 > 공유부족으로 인한 개발 인력에 대한 의존도 높아짐

아키텍처의 중요성

클린코드, 좋은설계, 아키텍처에 대한 중요성

• 중복이 하나도 없게 하는것도 리소스가 너무 들어감 (3개까지는..인정)

• Big ball of mud

  • 뚜렷한 아키텍처 없이 구현된 시스템

• 지속적으로 변화하는 요구사항 수용

코드를 잘짜는게 중요한 설계다.

• Agile 더 좋은 sw개발 , 단순절자변경 개발 역량
• Transformation ?

코드리뷰 목적

• 주목적: 품질문제 검수 (버그/장애)
• 부가 목적
  • 서로에게 관심
  • 지식공유
  • 집단 코드 오너십 및 결속 증대
• 컴퓨터가 할수 있는건 컴퓨터에게 맡겨라
• 스타일같은걸로 힘빼지 말자
• 기분안상하게 조심

리뷰는 즉시 시작

• 속도를 위해. PR은 작고, 범위가 좋은 사이즈로
• 너무 크면 PR을 분리하라
• 예제코드 제공에 관대해라 .
  • 다 알려줄 필요는 없지만 헤메는걸 보고있을 필요도 없다.

공격적 리뷰 자제

• 코드작성자에 대한 지적은 제외해라.
• 명령하지 마라. 요청해라
• 의견을 줄때는 레퍼런스로 .
• PR에 포함되지 않은 라인은 리뷰범위가 아님.

칭찬해라

• 잘못된 부분에 집중하지 말고 좋은변경에 대한 진심어린 칭찬을 해라 (특히 주니어에게)

교착상태를 피해라.

• 만나서 얘기해라 텍스트로는 한계가 있다.

• 인정하거나 Escalate 해라. (그냥 승인해라)

• 다른 리뷰어에게 할당

• 오프라인 리뷰 최소화 (오프라인상에서 선배가 하는 리뷰는 지시로 받아들일수 있다.)

• 코드 비난에 대한 두려움을 극복해라 - 그냥 받아들여라