반응형

출처: SOFTWARE TESTING by Yogesh Singh, 2012

5Software Verification, 241~243페이지

 

5.4 소스 코드 검토(SOURCE CODE REVIEWS)

소스 코드 검토는 한 명 이상의 검토자가 소스 코드를 검사하고 개발자에게 긍정적인 피드백과 부정적인 피드백을 제공하는 것이다. 검토자는 그 개발팀 소속이 아니어야 한다. Robert Bogue는 소스 코드 검토에 대한 자신의 견해를 다음과 같이 밝혔다.

 

“대부분의 조직에서 코드 검토는 관련된 모든 사람에게 고통스러운 경험이다. 개발자들은 종종 이것이 그들의 의지를 꺾기 위해 고안된 공격 세션이라는 느낌을 받는다. 개발 리더는 지적해야 할 중요한 것과 그렇지 않은 것에 대해 종종 혼동한다. 관련된 다른 개발자는 종종 이것을 다른 사람의 코드에서 발생할 수 있는 문제를 지적함으로써 자신이 얼마나 더 우월한지 보여주는 기회로 사용한다.”

 

구문(syntax), 정의된 표준(standards defined), 가독성(readability), 유지보수성(maintainability) 등에 대해 소스 코드를 검토할 수 있다. 일반적으로 검토를 위한 표준 체크리스트가 있는 데, 이것이 자주 하는 실수를 찾고 확립된 코딩 표준에 대해 소스 코드를 검증하기 위한 지침 역할을 한다. 소스 코드 검토는 항상 품질을 개선하고 여러 유형의 오류를 찾는다. 오류는 잘못된 구조, 비즈니스 규칙 위반, 단순 누락 등으로 인해 발생할 수 있다. 소스 코드 검토는 오류를 찾는 효과적인 방법으로 입증되었으며 소프트웨어 개발의 좋은 관행으로 간주된다.

 

 

합리적인 비용으로 시간 내에 양질의 유지 관리 가능한 소프트웨어를 생산하기 위해서는 좋은 소프트웨어 엔지니어링 관행을 따라야 한다. 소스 코드 검토는 이 목표를 달성하는 데 도움이 된다. 권장되는 소프트웨어 엔지니어링 관행 중 일부가 다음과 같다.

 

  1. 항상 의미 있는 변수를 사용한다.
  2. 이름에 혼동을 주는 단어를 피한다. 예를 들어, 'Number'를 'No'로 축약하지 마라. 'Num'이 더 나은 선택이다.
  3. 지역 변수(local variables)를 선언하고 가능한 한 전역 변수(global variables)를 피한다. 즉, 변수의 범위를 최소화하라.
  4. 변수의 가시성(visibility)을 최소화한다.
  5. 여러 의미로 변수를 오버로드하지 마라.
  6. 모든 변수를 의미 있고 일관되며 명확한 이름으로 정의한다.
  7. 불필요하게 변수를 선언하지 않는다.
  8. 주석(comments)을 사용하여 소스 코드의 가독성(readability)을 높인다.
  9. 일반적으로 주석은 소스 코드가 어떻게 작동하는지가 아니라 소스 코드가 무엇을 수행하는지를 설명해야 한다.
  10. 소스 코드를 변경하는 동안 항상 주석을 업데이트한다.
  11. TABS가 아닌 스페이스를 사용하라.
  12. 모든 나눗수(divisor)는 0 또는 쓰레기 값인지 테스트해야 한다.
  13. 소스 코드에서 사용하지 않는 줄은 항상 제거하라.
  14. 모듈 결합(module coupling)을 최소화하고 모듈 강도(module strength)를 최대화한다.
  15. 파일 이름은 A~Z, a~z, 0~9, '_', 그리고 '.'만 포함해야 한다.
  16. 소스 코드 파일 이름은 모두 소문자여야 한다.
  17. 모든 루프(loops), 분기(branches), 논리 구성물(logic constructs)이 완전하고 정확하며 적절하게 중첩되어야 한다. 깊은 중첩(deep nesting)은 피한다.
  18. 복잡한 알고리즘은 충분히 설명되어야 한다.
  19. 정적 변수(static variables)를 선언하는 이유를 제시해야 한다.
  20. 루프가 올바른 횟수만큼 반복되는지 항상 확인해야 한다.
  21. 메모리가 필요하지 않을 때는 그것을 해제(free)하는 것이 필수적이다.
  22. 사용 후 할당된 모든 메모리와 리소스를 해제한다.
  23. 재귀 함수(recursive function)는 그 실행을 위한 스택 공간(Stack space)이 있어야 한다. 일반적으로 반복 함수(iterative functions)를 작성하는 편이 더 좋다.
  24. (이미 있는 것을 다시 만드느라) 쓸데없이 시간을 낭비하지 마라. 가능한 한 기존 소스 코드를 사용하라. 그러나 테스트 동안 이 소스 코드에 지나치게 의존하지 마라. 이 부분도 철저히 테스트해야 한다.

 

 

반응형

+ Recent posts