네이버 테크톡 15. Code Review is Horse(코드리뷰는 말이야)(feat.Latte)-요약

<1. 코드를 읽지 않고 할 수 있는 리뷰>

0단계는 기계적으로 고칠 수 있다.

1. prettier 으로 공백을 없앤다.

2. code spell checker: 오타를 하이라이팅해준다

3. Lint : 체크 및 기계적으로 고쳐준다.

4. husky: 커밋의 훅을 쉽게 쓸수 있도록  하는 라이브러리.

->이 분의 팀: 린트로 체크하고 프리티어로 포맷팅을 한 다음 TS를 쓰고있어 TS 검증과 커밋 메세지 convention에 일치하게 commit message를 썼는가를 확인. pull/push hook은 마스터나 디벨롭에 직접 push할 수 없도록 하여 리뷰를 통한 머지를 강제하고 있음.

 

리뷰할 수 있는 부분을 나누고 아래와 같이 문서화

 

<2, 코드를 읽고 할 수 있는 리뷰>

1단계. 기능 구현이 잘되었는가?

주어진 스펙이 구현이 잘되었는가?

버그 찾기, 나아가 디버깅하기(코드상 보이는 명백한 버그 찾기 vs 실행 시킨 후 나타나는 버그 찾기)

 

2단계. 확장성이 좋은 코드인가?

반복을 줄일 수 있는가?

재사용이 가능한 함수인가?

불필요한 코드가 있는가?

 

3단계. 유지 보수가 좋은 코드인가?

가독성이 좋은가?

성능적으로 개선할 수 없을까?

가독성과 성능을 모두 개선시킬 수 있는 방법은 없을까?

 

<더  높은 단계의 코드 리뷰를 받기 위한 내 코드 이해시키기>

1. 코드 단위를 작게 하라

코드 단위가 크면 리뷰하기 어려워짐 리팩토링을 기약하고 머지될 수 있음. 

코드 단위가 작으면 코드 전체적으로 리뷰를 받을 수 있음(오타까지)

 

작은단위, 어떻게??

신입에게 작은 단위를 나누는 것(판단) 어렵다.

처음부터 하긴 당연히 어렵다. 코드 단위는 개발자가 느끼는 주관적인 영역이기 때문.

하지만 작은것>>>>>>>>>>큰것.

 

 

1. git diff 적극 활용하기.

불필요한 변경은 diff에 잡히지 않도록 함. 

eslint comma-dangle도 불필요한 diff와 관련된 룰임. diff를 적게 하려는 방법 중에서 끝에 콤마를 남겨서 diff을 줄임.

로직과 단순 파일이름 변경 삭제 커밋을 분리하기.

 

2. 코드를 예상 가능하게 하라

커밋 잘 하기: 커밋 메세지 잘 쓰기 기능과 관련된 커밋 메시지!

PR(Pull Request) 잘하기

실제 어떻게 쓰고 있나요?

 

코드가 복잡하다면? 가끔 그림도 그린다.

 

코드에도 , pr에도 있지만 내가 생각했던 내용을 점검받고싶을때?

 

좋은 리뷰이 되기

내 코드 != 나 : 많은 리뷰에 상처받지 말자. 리뷰를 모두 반영하면 분명 성장해있을  것

핑프는 되지 말자. 리뷰가 간단하더라도 리뷰어가 리뷰한 내용에  대한 근거는 있을거다. 찾아보자, 테스트해보자

"이부분, 이렇게 바꾸면 좋을 것 같습니다" -> 무슨 말이지? -> 현재 구현부와 리뷰의 차이점을 찾아본다 -> 검색, 테스트 해본다 -> 그래도 모르겠으면 얼마나 찾아봤는지 어필해야한다.

피드백을 하자 : 리뷰 반영만 피드백이 아니다.

좋은 리뷰는 '이 부분을 알려줘서 좋았다!'라는 피드백을 주자

리뷰 반영 시 시간이 오래 걸릴 경우는 리뷰어에게 알려주자

 

신입의 경우: 반영해야 할 리뷰 vs 반영 했으면 하는 리뷰를 구분하여 리뷰해주기.