좋은 코드리뷰어 되기
코드리뷰가 필요한 이유
- 코드 작성자가 발견하지 못한 실수를 다른 사람이 발견하여 사이트 이펙트와, 오류 조기 대응
- 작업자 본인이 작업한 코드의 경우, 오류를 발견하지 못하는 경우가 있습니다. 잘 안보여요ㅠㅅㅠ
- 많은 사람들이 볼 수록 버그를 더 잘 찾아낼 수 있습니다.
- 팀내 정해진 컨벤션 규칙을 유지하여, 기술부채를 줄이고 제품의 퀄리티를 유지할 수 있다.
- 서로의 업무 내용을 팔로업
- 서로의 업무 내용을 팔로업 하여 진행상황을 확인하고
어떤 부분을 중심으로 리뷰해야 할까
- 고수준에서 저수준으로
- 고수준 : 버그, 장애, 성능 보안
- 저수준 : 설계개선, 변수명 변경, 주석 명확
- 작은 커밋단위가 아닌 전체 코드의 맥락을 살필것
지켜야 할것
- 개발자의 성향을 리뷰하는것은 지양하기
- 리뷰의 범위 존중하기 : PR에 포함되지 않은 라인은 리뷰의 범위가 아니다.
어떤 방식으로 코멘트를 달아야 할까
- 왜 개선이 필요한지 충분한 설명을 해주기 (의견이 아닌 원칙기반 ) → 제안하는 변경과 변경의 이유
(X) 이 클래스를 2개로 분리해야 해요
(O) 이 클래스는 2가지의 책임을 가지고 있어요. 2개의 클래스로 분리해서 SRP를 준수하면 어떨까요?
- 무엇을 할 수 있을지 객관적으로 설명하기
(X) 이 코드는 혼란스럽네요(”너” 대화법)
(O) 저는 코드가 이해하기 어려운거 같아요.
- 클린 코드를 유지하고, 일관되게 구현하도록 안내해주세요.
"함수를 선언하는 두 가지 방식(함수 표현식, 함수 선언식)을 사용했는데
특별한 이유가 아니라면 함수를 선언하는 방식을 스스로 정하고 그 컨벤션 규칙을
따르도록 해보세요. 일관되게 동작하는 코드는 훨씬 보기 좋고 쉽게 수정할 수 있습니다.
그리고 reduce를 통해서 새로운 자료구조를 만든 건 잘했습니다.
하지만 같은 반복처리를 하는 과정에서 calculateEarningRate 에서
for문을 사용한 건 아쉽네요. reduce와 비슷한 방식의 다른 고차 함수를 찾아서
써보면 더 일관된 코드를 유지할 수 있을 거 같습니다."
- 리뷰를 위한 리뷰를 하지 마세요. 피드백 할 게 없으면 칭찬해 주세요.
코드량이 적당해서 읽기 편하네요.
많은 고민이 코드에서 엿보이네요.
성능에 아주 유리한 코드라고 생각되네요.
전에 코드보다 훨씬 좋아진 거 같네요.
예외 처리가 꽤 꼼꼼해서 좋네요.
함수, 변수명이 직관적이어서 좋네요.
내가 만들고 싶은 좋은 코드리뷰 문화
- 코드리뷰는 누구나 할 수 있습니다. 개발자가 아니어도 할 수 있습니다.
- 개발자가 아니어도 이해할 수 있는 코드를 작성할 수 있게 노력해보세요.
- 코드리뷰는 질책하거나 이거 왜 이렇게 했냐고 탓하는 자리가 아닙니다. 코드리뷰를 받았다고 책임이 회피되는 것도 아닙니다.
- 코드리뷰는 실수한 부분이 있는지 서로 확인하고, 개선할 부분이 있는지 같이 보는 겁니다.
- 코드리뷰는 즐거운겁니다. 짤같은걸 써도 됩니다. 쓰세요. 권장합니다. 즐거운 분위기로 만드세요.
- 나봐 잘하는 사람의 코드를 리뷰하게 되면 코드를 보고 배우는게 많습니다. 와 이런 방법도 있군요 같은 코멘트를 다셔도 됩니다.
활발한 코드리뷰문화를 만들어가요.
참고자료
https://hyeon9mak.github.io/code-review-know-how/(추천)