본문 바로가기
Development/SoftwareTech

[프로젝트관리] 코드리뷰 항목

by 푸민 2015. 8. 11.
반응형

 

 

안녕하세요 푸민입니다.

 

코드 리뷰 관련하여 항목 정리합니다.

 

지켜야할 원칙

 

- 코드리뷰는 1시간 이내에 끝낼수 있는 분량을 선정할 것

 

- 코드는 200개 이상의 라인을 한 번에 검토하지 말 것

 

 

기능 체크리스트

 

- 시스템의 요구사하잉 제대로 반영됐는가?

 

- 시스템의 설계 규격대로 구현됐는가?

 

- 과도한 코딩을 하고 있지 않은가?

 

- 같은 기능 구현을 더 단순하게 할 수는 없는가?

 

- 함수의 입출력 값을 명확한가?

 

- 빌딩블록들(알고리즘, 자료구조, 데이터타입, 템플릿, 라이브러리, API 등)이 적절하게 사용됐는가?

 

- 좋은 태펀과 추상화(상태도, 묘듈화) 등을 사용해서 구현하고 있는가?

 

- 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해 별도로 기술하고 있는가?

 

- 함수의 반환(exit)은 한 곳에서 이뤄지고 있는가?

 

- 모든 변슈는  사용전에 초기화하고 있는가?

 

- 사용하지 않는 변수가 있는가?

 

- 하나의 함수가 하나의 기능만을 수행하고 있는가?

 

 

코딩 스타일 체크리스트

 

- 코딩 스타일가이드를 준수하고 있는가?

 

- 각 파일의 헤더정보가 존재하는가?

 

- 각 함수의 정보는 코드를 설명하기에 충분한가?

 

- 주석은 적절하게 기술돼 있는가?

 

- 코드가 잘 구조화돼 있는가? (가독성, 기능적 측면)

 

- 헤더, 함수 정보를 도구를 추출해서 자동으로 문서화할 수 있는 구조인가?

 

- 변수와 함수의 이름이 일관되게 기술돼 있는가?

 

- 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?

 

- 숫자의 경우 단위에 대해서 기술하고 있는가?

 

- 숫자를 직접 서술하지 않고 상수를 사용하고 있는가?

 

- 어셈블리 코드를 사용했다면 이를 대체할 방법은 없는가?

 

- 수행되지 않는 코드는 없는가?

 

- 주석처리된 코드는 삭제됐는가? (버전 체크가 됐는가?)

 

- 간결하긴 하지만 지나치게 독특한 코드가 존재하지 않는가?

 

- 설명을 보거나 작성자에게 물어봐야만 이해할 수 있는 코드는 없나?

 

- 구현 예정인 기능이 ToDo 주석으로 표시돼 있는가?

 

 

아키텍처 체크리스트

 

- 함수의 길이는 적당한가? (화면을 넘기면 안됨)

 

- 코드의 재사용이 가능한가?

 

- 전역변수를 최소화 했는가?

 

- 변수의 범위는 적절하게 선언됐는가?

 

- 클래스와 함수가 관련된 기능 끼리 그룹으로 묶여 있는가? (응집도는 어떤가?)

 

- 관련된 함수들이 흩어져 있지 않는가?

 

- 중복된 함수나 클래스가 있지 않는가?

 

- 이식성을 고려해 코드가 작성됐는가? (프로세스의 특성을 받는 변수타입이 고려됐는가?)

 

- 데이터에 맞게 타입이 구체적으로 선언됐는가?

 

- if/else 구분이 2단계 이상 중첩됐다면 이를 함수로 더 구분하라.

 

- switch/case 문이 중첩됐다면 이를 함수로 더 구분하라.

 

- 리소스에 lock 이 있다면 unlock은 반드시 이루어지는가?

 

- 힙메모리 할당과 해제는 항상 짝을 이루는가?

 

- 스택변수를 반환하고 있는가?

 

- 외부/공개 라이브러리를 사용했을 경우 MIT 라이선스를 확인했는가? (GPL의 경우 관련된 영역에서만 사용해야 한다.)

 

- 블로킹 API 호출 시에 비동기적인 방식으로 처리하고 있지는 않는가?

 

 

예외처리 체크리스트

 

- 입력 파라미터의 유효범위는 체크하고 있는가?

 

- 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?

 

- 호출함수가 에러와 예외처리 코드를 가지고 있는가?

 

- Null 포인트와 음수가 처리되는 구조인가?

 

- 에러코드에 대해 명쾌하게 선언하고 처리하는가?

 

- switch 문에 default가 존재하며, 예외처리하고 있는가?

 

- 배열을 사용할 때 index 범위를 체크하는가?

 

- 포인트 사용 시에 유효한 범위를 체크하는가?

 

- 가비지 컬렉션(garbage collection)을 제대로 수행하고 잇는가?

 

- 수학계산 시에 오버플로우(overflow)나 언더플로우(underflow)가 발생할 가능성은 없는가?

 

- 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?

 

- 에러메시지와 에러코드가 에러의 의미를 잘 전달하는가?

 

- try/catch 에러 핸들링 사용방법은 적절하게 구현됐는가?

 

 

시간 흐름 체크리스트

 

- 최악의 조건에 대해 고려했는가?

 

- 무한루프와 재귀함수는 특이사항이 아니라면 없어야 한다.

 

- 견쟁조건이 존재하는가?

 

- 스레드는 정상적으로 생성되고 종작하는 코드를 가지고 있는가?

 

- 불필요한 최적화를 위해 코드의 가독성을 희생하지 않았는가? ( 임베디드의 경우에도 최적화가 매우 중요한 사항이 아니라면 가독성을 더 중시해야 한다.)

 

 

테스트 체크리스트

 

- 코드는 시험하기 쉽게 작성 됐는가?

 

- 단위 테스트를 쉽게 할 수 있는가?

 

- 에러 핸들링 코드도 잘 테스트됐는가?

 

- 컴파일, 링크 체크 시에 경고메시지도 100% 처리했는가?

 

- 경계값 음수값 0/1 등의 가독성이 떨어지는 코드에 대해 충분히 경계하고 있는가?

 

- 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?

 

- 모든 인터페이스와 예외 조건에 대한 테스트 코드가 있는가?

 

- 최악의 조건에서 리소스를 사용할 때 문제는 없는가?

 

- 런타임 시의 오류와 로그에 대비한 시스템이 있는가?

 

- 테스트를 위한 주석 코드가 존재하는가?

 

 

하드웨어 체크리스트

 

- I/O 오퍼레이션 코드에 대한 테스트로 하드웨어의 정상적인 동작을 보장하는가?

 

- 최소/최대 타이밍 요구사항에 대해 하드웨어 인터페이스가 충족하는가?

 

- 멀티바이트 하드웨어 레지스터가 read/write 오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?

 

- 시스템이 잘 정외된 하드웨어 상태로 리셋하는 것을 소프트웨어가 보장하는가?

 

- 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우 이를 잘 처리하는가?

 

- 대기모드 진입과 퇴장 시 시스템이 옳게 동작하는가?

 

- 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결돼 있는가?

 

- EEPROM 손상( 데이터 깨짐)을 막기 위한 메커니즘이 있는가? (쓰기 동작 중 power loss 등)

 

 

 

코드 인스펙션

 

1. Planning : 계획 수립

 

2. Overview : 교육과 역활 정의

 

3. Preparation : 인터뷰와 필요한 문서 습득, 툴 환경 구축

 

4. Meeting(Inspection) : 각자의 역할대로 임무 수행

 

5. Rework : 보고된 Defect 수정

 

6. Follow-up : 보고된 Defect가 수정됐는지 확인

 

 

코드 리뷰 쉽지 않네...

 

출처 : 마이크로소프트 잡지

반응형

댓글