코드 리뷰

 

코드리뷰

 

 

 

- 코드를  읽지 않고 가능한 리뷰

0단계 : 한 눈에 오류가 보이는가?

 

공백

오타 

줄바꿈

변수명

코드 컨벤션

 

0단계는 여러가지 도구를 이용해 스킵할 수 있다!

 

1. 도구사용

prettier

Vs Code - Code Spell Checker

Lint

eslint

JsLint/JSHint

husky

 

2. 컨벤션  문서 정리

 

 

코드를 읽고 하는  리뷰

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

 

1. 주어진 스펙이 구현이  잘 됬는가?

-  기능의 정상동작여부

2. 버그 찾기 나아가 디버깅 하기

 - 코드 상 보이는 명백한 버그 찾기 & 실행 시킨 후 버그 찾기

 

 

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

 

1. 반복을 줄일 수 있는가?

 - 예시 : 자주 쓰는 부분이니 공통 유틸 할수로 만드는게 좋을 것 같습니다.

 - 만든 모듈을 모두가 기억하는건 쉽지 않습니다. 코드  리뷰를 통해 재사용 가능한 모듈이 중복개발되는 것을 막을 수 있습니다.

 

2. 재사용  가능한 함수인가?

 - 예시 : number | string 모두 받게 하면 A에서도 쓸  수 있을 것 같습니다.

 

3. 불필요한 코드가 있는가?

 - 예시 : z기능을 쓰기 위해 A함수를 불러 불필요한 분기가 많은데요 A함수보다 Y가 기능을 분리해 B함수를 만들고 Z,Y에서 공통으로 쓰게하면 될 것 같습니다.

 

 

3단계 : 가독성과 유지 보수가좋은 코드인가?

 

1. 가독성이 좋은가

 - 들여쓰기(indent)의 크기나, 코드 한 줄의 최대 길이, 메소드 호출의 깊이(depth)등의 표준을 정해두면 좀 더 객관적인 기준으로 코드리뷰를 수행할 수 있습니다.

 

2. 개발 표준이  지켜지는가?

 -  기본적인 표준으로는 들여쓰기의 크기, 코드 한 줄의 최대 길이, 파일과 변수의 명명규칙 등이 있고, 형상관리 도구를 사용 한다면 커밋 메시지에 대한 규칙도 추후에 변경사항을 추적할 때 용이하게 사용될 수 있습니다. 

 

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

 

4. 성능과 가독성이 충돌할 때

 

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

 

6. 테스트 코드는 작성 되는가?

 

 

 

코드리뷰시 주의점

 

1. 코드의맥락을 이해할수있는  설명을 추가하자

2. 하나의 이슈당 하나의 코드리뷰

3. 리뷰 받는 코드는 한번에 500줄 이하

4. 주관적인 의견을 표현하는 방식

 - 컨밴션을 통해 어느정도 일관된 스타일을 유지할 수  있지만 각자의 스타일을 배제하는  것은 힘듭니다. 서로의 견해차이가 발생했을때 "나의 의견은 이러한데 당신은어떻게 생각하시나요?"와 같이 의견을 묻는것이 좋습니다.

5. 리뷰를 너무 미루지 말자