메뉴 건너뛰기

이 문서는 카네기 멜론 대학의 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 

Atachment
첨부 '1'
?

 


  1. TOP4 테스트 자동화(Test Automation) 플랫폼

    요즘 소프트웨어는 고객의 요구에 민첩하게 대응하고 고객 니즈를 반영하여 짧은 주기의 배포 사이클을 중요하다. 이러한 배포 주기와 함께 반드시 보장해야할 것이 바로 소프트웨어 품질이다. 소프트웨어 품질 보장을 위해 CI, CD, DevOps의 꽃은 테스트 자동...
    Date2018.07.13 ByTom Reply0 Views2973
    Read More
  2. 소프트웨어 품질 문제 해결을 위한 지속적인 코드 인스펙션

    소개소프트웨어 품질은 모든 기업의 관심사가 되고 있다. 비즈니스 핵심 가치를 실행하는데 소프트웨어의 역할이 점차 확대되고 있기 때문이다. 일반적으로 소프트웨어 품질은 외부 혹은 내부 품질로 구성된다. 외부 품질 즉 기능적 품질은 소프트웨어가 ...
    Date2018.01.30 ByTom Reply0 Views2336
    Read More
  3. No Image

    AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z

    웹 서핑하다가 괜찮은 글이 있어서 링크 공유 합니다. :) https://aws.amazon.com/ko/blogs/korea/how-to-loading-test-based-on-aws/
    Date2017.01.31 ByPSEG Reply0 Views2280
    Read More
  4. No Image

    유용한 오픈 소스 테스트 관리 도구들

    이 문서는 무료로 사용할 수 있는 오픈 소스 테스트 관리를 소개한다. 테스트 관리 도구는 팀에게 아주 중요한 역할을 한다. 이러한 툴들은 팀 내에서 요구사항 수집하고 이 수집된 요구사항을 기반으로 테스트 케이스 설계를 지원하고 요구사항과 테스트 케이...
    Date2016.05.31 ByTom Reply0 Views5299
    Read More
  5. 오픈소스 Java 테스트 프래임웍 7선

    오픈소스 Java 테스트 프래임웍 7선 1. Arquillian Integration, acceptance 테스트 자동화에 적합한 도구이다. 빌드, 테스트 할 때 tun-rime을 관리해주기 때문에 개발자가 run-time을 별도로 관리하지 않도도 된다. 컨테이너, 테스트케이스, 클래스와 ...
    Date2016.04.09 ByPSEG Reply1 Views5989
    Read More
  6. 대시보드를 위한 오픈소스(Open Source) 차트(Chart) 라이브러리

    이 게시물은 무료로 사용할 수 있는 오픈 소스 차트 라이브러리(Open Source Chart Library)에 대해서 소개합니다. 최근 ALM 관련 컨설팅을 하면서, 고객사에서 ALM 관련 데이터 수집과 데이터 표현에 즉 품질 대시보드대에 대한 관심이 많은 편인데, 오...
    Date2015.12.04 ByTom Reply1 Views25848
    Read More
  7. 임베디드 시스템 코드리뷰 체크리스트

    이 문서는 카네기 멜론 대학의 Gautam Khattak, Philip Koopman 문서인 Embedded System Code Review Checklist 버전 1.01을 번역하였습니다. 오역이 있을 수 있으니, 아래 링크를 통해 원문을 확인해 보시기 바랍니다. http://users.ece.cmu.edu/~koopman/ess...
    Date2015.09.01 ByTom Reply0 Views6472
    Read More
  8. RedmineCRM 무료 Theme 5종 비교

    이번 게시글은 RedmineCRM에서 제공하는 무료 Theme 5종을 Preview합니다. 예전에 RedmineCRM의 Theme는 로그인 없이 다운로드 했던것 같은데, 이번에 다운로드를 할려고 하니 회원가입을 했기에, 한번 모든 Theme를 다운로드 받고 실제 Redmine 프로젝트...
    Date2015.08.24 ByTom Reply0 Views6136
    Read More
  9. 미항공우주국이 밝힌 필수안전 코드 개발을 위한 열 가지 원칙

    미항공우주국이 밝힌 필수안전 코드 개발을 위한 열 가지 원칙 NASA는 지난 수십 년 간 우주탐사를 위한 매우 중대한(mission-critical) SW개발 프로젝트를 수행해 왔는데, 그 간의 개발경험을 기반으로 2015년 1월 신뢰성 있는 소프트웨어 확보를 위한 ...
    Date2015.03.17 BySW공학센터 Reply0 Views6045
    Read More
  10. 2014년도 공개소프트웨어 기업 편람

    2014년도 공개소프트웨어 기업 편람이 발간되었습니다. 한국공개소프트웨어활성화포럼에서 발간한 본 편람에는 공개SW의 개념 및 특징과 함께 2014년도 기준, 공개SW 기업들의 기본 정보와 주요 제품 및 서비스, 특기사항 등이 수록되어 있습...
    Date2015.03.11 BySW공학센터 Reply0 Views3572
    Read More
Board Pagination Prev 1 2 3 4 Next
/ 4