인용구가 있어 해당 글은 배포를 허하지 않습니다.

1. 코드리뷰 메뉴얼

1. 코드리뷰를 하는 이유

The only way to go fast, is to go well" - Robert C. Martin(클린 코드, 클린 아키텍처, 클린 애자일 등의 저자)

“소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.” - 코드 컴플릿(Code Complete) 저자 스티브 맥코넬(Steve McConnell)

개발 생산성

Clean Architecture: A Craftsman’s Guide to Software Structure and Design

Clean Architecture: A Craftsman’s Guide to Software Structure and Design
글로벌기업은 코드 리뷰를 어떻게 할까요? (개발자 업무는 개발 50%, 리뷰 50%인 Microsoft, 리뷰가 당연한 네카라쿠베) - 하단에 레퍼런스 확인해주세요. 사전 동의 없이 가공이 금지되어 있어 링크만 전달합니다.
사전에 장애 위험 요소를 발견하거나 더 좋은 코드를 작성하기 위해, 성장을 위해 해야합니다. ‘코드리뷰를 부탁할 때 더 좋은 코드를 작성할 확율이 높다.’는 말에 공감하며, 다소 절차가 복잡해져 속도가 늦어지더라도 일정 규모 이상의 프로덕트 생산 프로세스에 코드리뷰는 빼놓을 수 없는 부분이라고 생각해요.

2. 코드리뷰 절차

코드를 비판할 때에는 코드를 비판하는 것이지 개인을 공격하는 점이 아니라는 것을 꼭 기억해주시기 바랍니다.
- 코드와 본인의 인격은 분리해서 생각해주셔야 합니다. 공격적인 태도로 저자를 공격하는 것이나 방어적인 태도로만 리뷰어의 의견을 듣는 것을 방지하기 위한 문화가 필요합니다.

저자는 리뷰 요청을 할 때 문서를 작성해야 합니다. 문서는 상세해야 하는데 대표적으로 2가지 이유를 들 수 있습니다.
- 자신이 짠 코드라도 2~3주 후면 기억이 잘 안납니다.
- 리뷰어는 자신의 코드도 짜면서 저자의 코드도 봐야 합니다. 출근 대부분의 시간을 리뷰에 쏟을 수는 없기 때문에, 리뷰어가 읽어서 이해가 안되면(그만큼 문서가 불충분하다면), 리뷰를 거절해야 합니다.
변경내역은 보통 PR로 날립니다. (여기에 상세 기록을 해주셔야 합니다.)

3. 우리의 코드리뷰

PR이 아니라 전체 압축 파일로 받습니다.
리뷰의 수정 결정권한은 저자에게 있습니다. 의견을 반영하지 않으셔도 됩니다.
저자가 고생하여 리뷰어가 덜 고생하게 해야합니다. 단순히 우리가 덜 고생하겠다 얘기하는 것이 아니라, 여러분이 실무에서 PR을 할 때에도 선임은 처음 보는 코드이기 때문에, 상세하게 코멘트 해주셔야 합니다. 전체 개요, 변경 내역, 아쉬웠던 부분이나 자신이 없는 부분, 테스트를 해야 한다면 테스트 할 수 있는 방법, 컴밋된 내용이 보통 PR줄 때 많이 씁니다.
코드리뷰 원하는 곳, 3곳 ~ 10곳을 지정해주세요.
1. 실무에서도 풀리퀘 반영된 곳 바로 위에 오타가 있어도 지적하지 않는 경우가 많습니다. 따라서 이번에도 코드리뷰 원하는 곳 3곳 ~ 10곳을 아래와 같은 형식(CODE_REVIEW.md 파일로 주시면 됩니다.)으로 압축파일 최상단에 주시면 됩니다. github으로 주실 경우에는 최상단에 CODE_REVIEW.md파일을 넣어주세요.
  1. 형식(동일 형식으로 3곳 ~ 10곳)
```
# 1번 리뷰

* 범위 : abc/a.py파일 65 ~ 72 line

* 전체 개요
...

* 기능 내용(함수나 변수 등은 주석으로 넣어주세요.)
...

* 기타(해당 코드 라인에 잘 모르겠는 부분 등을 적어주시면 됩니다.)
...

# 2번 리뷰
...

# (신규) 3번 리뷰
...
```