배우고 싶다면 코드리뷰

코드 리뷰를 시작하다

  최근 들어서 안드로이드와 관련된 프로젝트나 대외활동을 이것저것 하기 시작했다.

자연스럽게 따라 오던 부분은 코드리뷰를 하는 것. 말로만 듣던 코드리뷰를 직접하니 여간 어려운 일이 아니었다.

하지만 개발자라면 앞으로도 쭉 코드리뷰를 하지 않겠는가.

코드리뷰에 대해서 이것저것 찾아봤다.

 

코드 리뷰를 어떻게 해야 할까?

  일단 처음 코드리뷰를 시작했을 땐 무엇을 리뷰해야될 지 막막했다. 감히 내가 저 잘하는 사람의 코드를 리뷰한다니?

내가 보기엔 완벽하기만 한데 한 줄이라도 리뷰를 해야하니 막막하기만 했다. 보통은 코드리뷰를 하면 어떻게 효율적으로 더 코드를 줄이면서 할 수 있을지에 대해 논의하기도 하고, 코드의 작성 위치나, 함수로 묶으면 좋겠다는 등의 리뷰를 하는 것 같다.

그래도 코드리뷰에 대한 가이드 라인이 있지 않을까해서 찾아봤는데, zetlos님의 블로그에서 좋은 코드리뷰 가이드라인을 찾았다.

 

 

코드리뷰 필수 요소 2가지

1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.
2. 코드는 200라인 이상을 한 번에 검토하지 마라

기능에 대한 체크리스트

1. 시스템의 요구사항이 제대로 반영되었는가?
2. 시스템의 설계의 규격대로 구현되었는가?
3. 과도한 코딩을 하고 있지 않는가?
4. 같은 기능 구현을 더 단순하게 할 수 있는가?
5. 함수의 입출력 값은 명확한가?
6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?
7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?
8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?
9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?
10. 모든 변수는 사용 전에 초기화하고 있는가?
11. 사용하지 않는 변수가 있는가?
12. 하나의 함수는 하나의 기능만 수행하고 있는가?

스타일과 코딩 가이드에 대한 체크리스트

1. 코딩 스타일 가이드를 준수하고 있는가?
2. 각 파일의 헤더 정보가 존재하는가?
3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?
4. 주석은 적절하게 기술되어있는가?
5. 코드는 잘 구조화되어있는가? ( 가독성, 기능적 측면 )
6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?
7. 변수와 함수의 이름이 일관되게 기술되어 있는가?
8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?
9. 숫자의 경우 단위에 대해서 기술하고 있는가?
10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?
11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?
12. 수행되지 않는 코드는 없는가?
13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )
14. 간결하지만 너무 특이한 코드가 존재하는가?
15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?
16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?

아키텍처에 대한 체크리스트

1. 함수의 길이는 적당한가? ( 화면을 넘기면 안 된다. )
2. 이 코드는 재사용이 가능한가?
3. 전역 변수는 최소로 사용하였는가?
4. 변수의 범위는 적절하게 선언되었는가?
5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )
6. 관련된 함수들이 흩어져 있지 않는가?
7. 중복된 함수나 클래스가 있지 않는가?
8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )
9. 데이터에 맞게 타입이 구체적으로 선언되었는가?
10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라
11. Switch/case문이 중첩되었다면 이를 더 구분하라
12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?
13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?
14. 스택 변수를 반환하고 있는가?
15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.
16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?

몇가지 더 체크리스트가 있는데, 이에 대한 체크리스트는 아래 링크에서 참고해보자.

https://velog.io/@zetlos/%EC%86%8C%EC%8A%A4%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A7%A7%EC%9D%80-%EC%9D%B4%EC%95%BC%EA%B8%B0

 

결론

  결국 코드리뷰는 앞으로도 할 것이고 더 자주 해야 할 것이다. 코드리뷰의 장점은 어마어마하게 많지만 내게 가장 와닿았던 것은

잘하는 사람들의 코드를 보고 배울 수 있다는 것이고 나의 코드를 더 개선할 수 있다는 것이다. 앞으로 코드리뷰를 더 자주 적극적으로 하는 개발자가 되고 싶다.