- https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/
- https://medium.com/zigbang/%EC%8A%AC%EA%B8%B0%EB%A1%9C%EC%9A%B4-%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0-%EC%83%9D%ED%99%9C-with-github-pull-request-7932b5d47c70
- 친구들과의 약속 보름 뒤로 미루기 (오랜만에 봐야 더 정겹고 할 말이 많다.)
- 게임하지 않기 (오랜만에 해야 더 재밌다.)
- 야근하면서 리뷰 진행하기 (퇴근하고 집가면 하기 싫다.)
- 한 번 리뷰가 밀리기 시작하면 부담이 커진다.
- 리뷰이들은 오매불망 나의 리뷰를 기다리고 있다.
- 롤을 한판하면 리뷰이의 1시간을 빼앗은 것과 마찬가지
- 막상 리뷰해보면 별거 없다.
- 리뷰할 시간을 정해두자. (매일 아침 출근 직후, 매일 저녁 퇴근 직전)
- 초~중반 단계에서 미션 진행이 더딜 경우 의욕이 크게 저하될 수 있다.
- 말도 안되는 코드를 작성했거나, 큰 규모의 리팩터링이 필요한 경우 request changed 를 남긴다.
- 사소한 코멘트로 충분하다면 다음 단계 진행과 함께 리팩터링을 진행할 수 있도록 approve 를 남긴다.
- 마지막 단계에선 만족스러운 코드가 완성될 때까지 놓아주지 말자.
- 리뷰어는 리뷰이를 가르치는 존재가 아니다. 더 나은 결과물을 위해 아이디어를 제안하는 동료 개발자.
- 요구 사항 규모보다 극단적인 리팩터링을 제시해볼 수도 있다.
- 이를 반영할지 말지는 리뷰이의 재량.
- 리뷰이가 잘 모르는 부분에 대해서도 예시 코드와 함께 설명해보자.
- 특정 지식에 대해 쉬운 문장으로 상대방에게 설명할 수 있어야 진짜 자신의 지식이다.
- 리뷰이는 학생이 아니다. 같은 업계에 종사하는 동료 개발자.
- 프로그래밍 설계와 구현에 정답은 없다.
- 내 의견이 수용되면 좋고, 아니면 마는 것.
- 서로 정답을 찾기보다, 요구 사항에 적합한 최선의 설계와 구현 코드를 찾기 위해 노력하고 토론하자.
- 리뷰이의 코드를 평가하는 것이 아니라, 더 나은 결과물을 함께 만들기 위해 토론하는 과정임을 꼭 기억할 것.
- 왜 개선이 필요한지 충분한 이유를 설명할 것
- 바로 답을 이야기하기보다, 스스로 고민하고 개선할 수 있는 방법을 제시할 것.
- 리뷰를 억지로 쥐어짜지 말을 것. 할 말이 없으면 칭찬을 해라.
- 팀 컨벤션에 포함되지 않는 사소한 스타일(성향) 차이는 가능하면 터치하지 않을 것.