임베디드 시스템 코드리뷰 체크리스트

by Tom posted Sep 01, 2015
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄
이 문서는 카네기 멜론 대학의 Gautam Khattak, Philip Koopman 문서인 Embedded System Code Review Checklist 버전 1.01을 번역하였습니다. 오역이 있을 수 있으니, 아래 링크를 통해 원문을 확인해 보시기 바랍니다.

http://users.ece.cmu.edu/~koopman/essays/code_review_checklist.html

1.추천되는 사용법(Recommended Usage):

  • 댜음 각 섹션을 특정 리뷰어에게 할당하고 각 리뷰어 별로 2 혹은 3개의 섹션을 주어라.
  • 모든 코드의 조각이 각 질문을 고려하고 있는지 확인해라.
  • 리뷰어 당 1~2 시간 동안 100~400라인을 리뷰해라.

2.체크리스트

기능성 FUNCTION

  • F-1. 코드는 디자인과 시스템 요구사항을 반영하였는가?
  • F-2. 코드는 자신이 해야하는 일을 하고 있는가?
  • F-3. 코드에 불필요한 코드가 포함되지 않았는가?
  • F-4. 더 심플하게 코드를 만들 수 없는가? 그것이 필요한 무엇을 하는 동안
  • F-5. 알고리즘, 데이터 스트럭처, 타입, 템플릿, 라이브러리 등은 적절하게 사용되었는가?
  • F-6. 코드는 좋은 패턴과 추상화(Abstractions)를 사용하는가(예로, state charts, copy & paste 금지)?
  • F-7. 함수는 단일 반환점으로 작성되었는가?
  • F-8. 모든 변수들은 사용하기 전에 초기화 되었는가?
  • F-9. 사용하지 않는 변수가 있는가?
  • F-10. 각 함수는 하나의 일만 수행하는가?

스타일 STYLE

  • S-1. 프로젝트의 스타일 가이드를 준수하고 있는가?
  • S-2. 각 파일, 각 함수를 위한 헤더 정보가 충분히 기술되었는가?
  • S-3. 주석은 적절하게 작성되었는가?(충분함, 위치, 세부레벨)
  • S-4. 코드는 잘 구조화되었는가?(표기법, 기능성)
  • S-5. 변수와 함수명은 일간성있는 스타일로  작성되었는가?
  • S-6. 매직 넘버를 피하고 있는가?(숫자보다 constants를 사용하라)
  • S-7. 데드코드(dead code)가 남아 있는가?(주석처리된 코드)
  • S-8. Is it possible to remove any of the assembly language code, if present?
  • S-9. 코드가 이해하기 어렵지는 않는가?(이해하기 쉬워야 한다)
  • S-10. 코드를 이해하기 위해 Author에게 설명을 들어야 하는가?(코드는 스스로를 설명할 수 있어야 한다)

아키텍처 ARCHITECTURE

  • A-1. 함수의 길이가 너무 길지 않은가?
  • A-2. 코드는 재사용 가능한가?
  • A-3. 전역변수의 사용을 최소화하였는가? 변수의 범위는 최소 범위로 적절히 정의되었는가?
  • A-4. 클래스와 함수들은 관련있는 것 기능끼리 적절하게 그룹핑되었는가?(응집성)
  • A-5. 코드는 휴대(portable)할 수 있는가?(예 변수사이즈 long 되신 int32)
  • A-6. 가능한 구체적은 타입을 선언하였는가?(예 unsigned )
  • A-7. if/else를 두 단계 이상 중첩되어 사용하였는가?
  • A-8. switch/case문이 중첩되어 사용되었는가?

예외처리 EXCEPTION HANDLING

  • E-1. 입력 파라미터의 유효범위를 체크하였는가?
  • E-2. 오류 리턴 코드/예외가 생성 및 호출한 함수까지 전달되는가?
  • E-3. 오류 리턴 코드/예외가 호출한 함수로부터 처리되는가?
  • E-4. NULL 포인터들과 음수가 적절히 처리되는가?
  • E-5. Switch 문에 에러를 처리하는 default 절이 있는가?
  • E-6. 인덱스 범위를 벋어나는 배열은 체크되는가? 포인터도 비슷하게 체크되는가?
  • E-7. Garbage Collection이 적절하게 이뤄지고 있는가? 특히 에러와 예외처리의 경우
  • E-8. 수학적인 오버플로우와 언더플로우가 이뤄지는가?
  • E-9. 에러 상태가 점검되고 로그를 남기는가? 에러 메시지와 코드는 의미를 가지는가?
  • E-10. try/catch와 같은 에러 핸들링 구조가 사용되는가?

타이밍 TIMING

  • T-1. Is the worst case timing bounded? (no unbounded loops, no recursion)
  • T-2. Are there any race conditions? (especially multi-byte variables modified by an interrupt)
  • T-3. Is appropriate code thread safe and reentrant?
  • T-4. Are there any long-running ISRs? (no loops inside ISRs; should be half-page of code)
  • T-5. Are interrupts masked for more than a few clocks?
  • T-6. Is priority inversion avoided or handled by the RTOS?
  • T-7. Is the watchdog timer turned on? Is the watchdog kicked only if every task is executing?
  • T-8. Has code readability been sacrificed for unnecessary optimization?

확인과 테스트 VALIDATION & TEST

  • V-1. 코드는 쉽게 테스트할 수 있는가?(코드에 얼마나 많은 패쓰가 있는지?)
  • V-2. 유닛테스트 브랜치 커버리지는 100%인가?(코드는 브랜치 커버리지를 달성하기 쉽게 작성되어야 한다) 
  • V-3. 컴파일 경고가 없는가?
  • V-4. 중요한 코드의 경우, 경계, 음수에 대한 테스트를 하는가?
  • V-5. 코드는 테스트를 위해 결함 조건을 주입할 수 있는 편리한 방법을 제공하는가?
  • V-6. 예외를 포함한 모든 인터페이스는 테스트 되는가?
  • V-7. 최악의 경우 자원 사용을 검증했는가?(스택 공간, 메모리 할당)
  • V-8. Run-time Assertion이 사용되는가? Assertion 위반이 기록되는가?
  • V-9. 테스트를 위해 주석처리된 코드들이 제거되었는가?

하드웨어 HARDWARE

  • H-1. Do I/O operations put the hardware in correct state?
  • H-2. Are min/max timing requirements met for the hardware interface?
  • H-3. Are you sure that multi-byte hardware registers can't change during read/write?
  • H-4. Does the software ensure that the system resets to a well defined hardware system state?
  • H-5. Have brownout and power loss been handled?
  • H-6. Is the system correctly configured for entering/leaving sleep mode (e.g. timers)?
  • H-7. Have unused interrupt vectors been directed to an error handler?
  • H-8. Has care been taken to avoid EEPROM corruption? (e.g., power loss during write)

Who's Tom

profile

저는 2009년 ALM의 세계에 뛰어 들었습니다. 

지금은 ALM, DevOps, 공학 프로세스, 요구공학, 테스트 엔지니어링 등 다양한 영역에 관심이 많습니다.

http://www.curvc.com