고품질 코드 체크 인 지침
다음 목록에서는 여러 가지 고품질 코드 체크 인 지침을 제공합니다.
필수
반드시 고품질 체크 인을 수행합니다.
나중에 제품 주기에 문제가 발생할 수 있으므로 코드를 체크 인하는 동안 낮은 품질은 허용하지 마십시오. 대개 팀에서는 지나치게 복잡하거나 모호하거나 제품 주기에서 너무 늦게 발견되는 문제는 해결하지 않습니다.
검사 목록을 사용합니다.
일반적으로 발생하는 실수의 종류를 추적하여 이후의 코드에 대한 검사 목록으로 사용합니다. 해당 그룹이나 부서에서 발생하는 일반적인 오류로 검사 목록을 만든 후 용도에 맞게 검사 목록을 사용자 지정할 수 있습니다.
코드 검토를 진행합니다.
코드를 검토하면 해당 코드를 설명하고 쉽게 이해할 수 있을 뿐 아니라 다른 사용자들이 이 코드를 다시 한번 확인할 수 있습니다.
단위 테스트를 작성합니다.
품질을 보장하는 가장 좋은 방법은 데이터와 알고리즘의 유효성을 검사하는 테스트를 작성하고 이전의 실수가 반복되지 않도록 하는 것입니다. 다음과 같은 네 가지의 단위 테스트가 있습니다.
긍정적 단위 테스트에서는 코드를 의도한 대로 실행하여 올바른 결과가 나오는지 확인합니다.
부정적 단위 테스트에서는 코드를 일부러 잘못 사용하여 코드가 견고한지, 오류 처리가 적절한지 확인합니다.
스트레스 테스트에서는 코드를 해당 한계까지 실행하여 미묘한 리소스, 타이밍 또는 재진입 오류에 노출시킵니다.
오류 삽입 테스트에서는 오류 처리에 이상이 없는지 확인합니다.
자세한 내용은 기존 코드에 대한 단위 테스트 생성 및 실행을 참조하십시오.
코드 분석 도구를 사용합니다.
버그를 일찍 찾아내는 가장 간단한 방법은 컴파일러의 경고 수준을 높이고 코드 분석 도구를 사용하는 것입니다. 경고를 무시하지 말고 코드를 수정하는 것이 중요합니다.
자세한 내용은 코드 분석을 사용하여 관리 코드 품질 분석을 참조하십시오.
소스 코드에 부적절한 언어를 사용하지 않습니다.
소스 코드에 부적절한 언어와 참조가 포함되면 안 됩니다. 전 세계의 많은 고객들은 특정 단계나 이름, 특히 지위가 문제시될 수 있는 정치적 실체에 대한 참조를 매우 중요하게 여깁니다. 소스 코드에 정치적으로 민감한 참조와 언어가 있는지 검색한 다음 오류를 보고하도록 합니다.
작업 항목을 만듭니다.
끝내지 않은 작업이 있는지 확인하고 TODO, REVIEW, BUG 및 UNDONE 주석에 대한 작업 항목을 만들어야 합니다. 자세한 내용은 작업 항목 만들기를 참조하십시오.
금지 사항
사양이 없는 기능
사양 없이 코드를 작성하지 않도록 합니다. 먼저 사양을 작성하여 검토합니다. 사양이 없으면 테스트 팀에서 올바르게 작동하는 항목과 그렇지 않은 항목을 알 수 없습니다. 코드에 사양이 없으면 서로 오해의 소지가 있으며 고객의 요구를 파악하기 어렵고 제품의 품질이 저하될 수 있습니다. 자세한 내용은 프로젝트 계획 및 추적을 참조하십시오.
제품을 제대로 설치하지 않고 첫 번째 과정 진행
테스트 팀은 프로토타입 설치에 불과하더라도 컴퓨터에 제품을 설치할 수 있는 방법을 갖고 있어야 합니다. 자세한 내용은 응용 프로그램 빌드를 참조하십시오.
권장
일관된 코딩 스타일을 사용합니다.
전체 팀 코드를 같은 스타일로 작성하면 제품의 가독성, 일관성, 유지 관리 편의성 및 전체적인 품질이 향상됩니다. 지침 자체의 세부 사항은 그리 중요하지 않으며, 지침을 세우고 팀에서 이 지침을 충실히 따르는 것이 중요합니다. 스타일을 선택하면 일관성을 유지하고 코딩 패턴을 쉽게 인식할 수 있는 이점이 있으므로 스타일을 선택하여 사용하십시오.
코드를 작성하기 전에 단위 테스트를 작성합니다.
테스트 우선 개발은 신속한 개발과 최고의 프로그래밍에 있어 핵심적인 방법입니다. 단위 테스트를 먼저 작성하면 여러 품질 목표를 달성할 수 있습니다.
단위 테스트를 작성했는지 확인합니다.
코드를 쉽게 테스트할 수 있어야 합니다. 그러면 대개 코드 결합은 향상되고 모듈 간의 결합은 느슨해집니다.
디자인을 테스트할 방법을 먼저 결정하면 종종 작업에 맞는 적절한 디자인을 알 수 있습니다.
자세한 내용은 기존 코드에 대한 단위 테스트 생성 및 실행을 참조하십시오.
코드를 다른 플랫폼으로 이식할 수 있게 만듭니다.
실제로 코드를 다른 플랫폼에 옮기지 않더라도 이식 가능하도록 디자인하고 코딩하면 코드가 더욱 견고해집니다. 다음을 참조하여 코드를 이식 가능하게 만듭니다.
적합한 가정을 세웁니다.
데이터 형식과 디자인 의도를 분명히 이해합니다.
새로 나오는 플랫폼을 지원할 수 있도록 코드를 만듭니다.
기존의 코드를 작은 함수로 리팩터링합니다.
리팩터링을 통해 기존의 코드를 새롭게 만들 수 있습니다. 일부 코드는 상호 작용이 너무 복잡하여 주석조차 변경하는 것이 번거롭기 때문에 크고 오래된 시스템은 수정하기 어려울 수 있습니다
제대로 리팩터링하려면 먼저 강력한 단위 테스트를 통합하여 리팩터링으로 인해 새로운 오류가 발생하지 않도록 해야 합니다. 그런 다음 기능을 전혀 변경하지 않고 큰 함수를 작은 함수의 컬렉션으로 분리합니다. 다음 지침을 따릅니다.
작은 함수는 각각 사용자 인터페이스, 데이터베이스 액세스, 단일 인터페이스에 대한 COM 상호 작용 등과 같은 한 가지 유형의 작업을 수행해야 합니다.
하위 시스템의 모든 함수를 완전히 리팩터링한 후에는 전체 시스템에 영향을 주지 않고 작은 함수들을 개별적으로 변경할 수 있습니다. 한 번에 함수 하나씩 기능을 추가, 제거 또는 향상시킬 수 있습니다.
자세한 내용은 클래스 및 형식 리팩터링(클래스 디자이너)을 참조하십시오.
기존 코드를 검사합니다.
종종 특정 모듈에 버그가 모여 있습니다. 새 코드에 문제가 없지만 이전 코드의 특정 모듈에 버그가 있으면 해당 모듈만 검사합니다. 새 코드가 이전 코드와 너무 섞여 있을 경우 리팩터링을 수행하면 문제 해결에 도움이 될 수 있습니다.
자세한 내용은 코드 분석을 사용하여 관리 코드 품질 분석을 참조하십시오.
디버거에서 모든 코드 경로를 단계별로 실행합니다.
코드를 확인하는 가장 좋은 방법 중 하나는 디버거에서 코드를 단계별로 실행하는 것입니다. 각 줄에서 예상되는 동작이 실제로 발생하고 있는지 확인합니다. 디버거에서 모든 코드 경로를 단계별로 실행하는 것은 한 줄씩 단위 테스트를 수행하는 것과 같습니다. 이 과정은 지루하지만 예상 동작을 효율적으로 확인할 수 있습니다.
권장되지 않는 사항
요구 사항 문서를 사양으로 사용
요구 사항 문서의 사양을 해석하지 마십시오. 본인의 해석이 프로그램 관리자나 테스터의 해석과 다를 수 있습니다. 해석이 다르면 다른 사람들이 예상하는 대로 구현할 수 없게 됩니다.