다음을 통해 공유


고품질 코드 체크 인 지침

업데이트: 2007년 11월

다음 목록에서는 여러 가지 고품질 코드 체크 인 지침을 제공합니다.

필수 사항

  • 반드시 고품질 체크 인을 수행합니다.

    나중에 제품 주기에 문제가 발생할 수 있으므로 코드를 체크 인하는 동안 낮은 품질은 허용하지 마십시오. 대개 팀에서는 지나치게 복잡하거나 모호하거나 제품 주기에서 너무 늦게 발견되는 문제는 해결하지 않습니다.

  • 검사 목록을 사용합니다.

    일반적으로 발생하는 실수의 종류를 추적하여 이후의 코드에 대한 검사 목록으로 사용합니다. 해당 그룹이나 부서에서 발생하는 일반적인 오류로 검사 목록을 만든 후 용도에 맞게 검사 목록을 사용자 지정할 수 있습니다.

  • 코드 검토를 진행합니다.

    코드를 검토하면 해당 코드를 설명하고 쉽게 이해할 수 있을 뿐 아니라 다른 사용자들이 이 코드를 다시 한번 확인할 수 있습니다.

  • 단위 테스트를 작성합니다.

    품질을 보장하는 가장 좋은 방법은 데이터와 알고리즘의 유효성을 검사하는 테스트를 작성하고 이전의 실수가 반복되지 않도록 하는 것입니다. 다음과 같은 네 가지의 단위 테스트가 있습니다.

    • 긍정적 단위 테스트에서는 코드를 의도한 대로 실행하여 올바른 결과가 나오는지 확인합니다.

    • 부정적 단위 테스트에서는 코드를 일부러 잘못 사용하여 코드가 견고한지, 오류 처리가 적절한지 확인합니다.

    • 스트레스 테스트에서는 코드를 해당 한계까지 실행하여 미묘한 리소스, 타이밍 또는 재진입 오류에 노출시킵니다.

    • 오류 삽입 테스트에서는 오류 처리에 이상이 없는지 확인합니다.

    자세한 내용은 방법: 단위 테스트 작성을 참조하십시오.

  • 코드 분석 도구를 사용합니다.

    버그를 일찍 찾아내는 가장 간단한 방법은 컴파일러의 경고 수준을 높이고 코드 분석 도구를 사용하는 것입니다. 경고를 무시하지 말고 코드를 수정하는 것이 중요합니다.

    자세한 내용은 C/C++ 코드 오류 검색 및 수정관리 코드 오류 검색 및 수정을 참조하십시오.

  • 소스 코드에 부적절한 언어를 사용하지 않습니다.

    소스 코드에 부적절한 언어와 참조가 포함되면 안 됩니다. 전 세계의 많은 고객들은 특정 단계나 이름, 특히 지위가 문제시될 수 있는 정치적 실체에 대한 참조를 매우 중요하게 여깁니다. 소스 코드에 정치적으로 민감한 참조와 언어가 있는지 검색한 다음 오류를 보고하도록 합니다.

  • 작업 항목을 만듭니다.

    끝내지 않은 작업이 있는지 확인하고 TODO, REVIEW, BUG 및 UNDONE 주석에 대한 작업 항목을 만들어야 합니다. 자세한 내용은 방법: 새 작업 항목 추가를 참조하십시오.

금지 사항

  • 사양이 없는 기능

    사양 없이 코드를 작성하지 않도록 합니다. 먼저 사양을 작성하여 검토합니다. 사양이 없으면 테스트 팀에서 올바르게 작동하는 항목과 그렇지 않은 항목을 알 수 없습니다. 코드에 사양이 없으면 서로 오해의 소지가 있으며 고객의 요구를 파악하기 어렵고 제품의 품질이 저하될 수 있습니다. 자세한 내용은 Team Foundation 팀 프로젝트를 참조하십시오.

  • 제품을 제대로 설치하지 않고 첫 번째 과정 진행

    테스트 팀은 프로토타입 설치에 불과하더라도 컴퓨터에 제품을 설치할 수 있는 방법을 갖고 있어야 합니다. 자세한 내용은 Team Foundation Build 개요를 참조하십시오.

권장 사항

  • 일관된 코딩 스타일을 사용합니다.

    전체 팀 코드를 같은 스타일로 작성하면 제품의 가독성, 일관성, 유지 관리 편의성 및 전체적인 품질이 향상됩니다. 지침 자체의 세부 사항은 그리 중요하지 않으며, 지침을 세우고 팀에서 이 지침을 충실히 따르는 것이 중요합니다. 스타일을 선택하면 일관성을 유지하고 코딩 패턴을 쉽게 인식할 수 있는 이점이 있으므로 스타일을 선택하여 사용하십시오.

  • 코드를 작성하기 전에 단위 테스트를 작성합니다.

    테스트 우선 개발은 신속한 개발과 최고의 프로그래밍에 있어 핵심적인 방법입니다. 단위 테스트를 먼저 작성하면 여러 품질 목표를 달성할 수 있습니다.

    • 단위 테스트를 작성했는지 확인합니다.

    • 코드를 쉽게 테스트할 수 있어야 합니다. 그러면 대개 코드 결합은 향상되고 모듈 간의 결합은 느슨해집니다.

    • 디자인을 테스트할 방법을 먼저 결정하면 종종 작업에 맞는 적절한 디자인을 알 수 있습니다.

    자세한 내용은 방법: 단위 테스트 작성을 참조하십시오.

  • 코드를 다른 플랫폼으로 이식할 수 있게 만듭니다.

    실제로 코드를 다른 플랫폼에 옮기지 않더라도 이식 가능하도록 디자인하고 코딩하면 코드가 더욱 견고해집니다. 다음을 참조하여 코드를 이식 가능하게 만듭니다.

    • 적합한 가정을 세웁니다.

    • 데이터 형식과 디자인 의도를 분명히 이해합니다.

    • 새로 나오는 플랫폼을 지원할 수 있도록 코드를 만듭니다.

  • 기존의 코드를 작은 함수로 리팩터링합니다.

    리팩터링을 통해 기존의 코드를 새롭게 만들 수 있습니다. 일부 코드는 상호 작용이 너무 복잡하여 주석조차 변경하는 것이 번거롭기 때문에 크고 오래된 시스템은 수정하기 어려울 수 있습니다

    제대로 리팩터링하려면 먼저 강력한 단위 테스트를 통합하여 리팩터링으로 인해 새로운 오류가 발생하지 않도록 해야 합니다. 그런 다음 기능을 전혀 변경하지 않고 큰 함수를 작은 함수의 컬렉션으로 분리합니다. 다음 지침을 따릅니다.

    • 작은 함수는 각각 사용자 인터페이스, 데이터베이스 액세스, 단일 인터페이스에 대한 COM 상호 작용 등과 같은 한 가지 유형의 작업을 수행해야 합니다.

    • 하위 시스템의 모든 함수를 완전히 리팩터링한 후에는 전체 시스템에 영향을 주지 않고 작은 함수들을 개별적으로 변경할 수 있습니다. 한 번에 함수 하나씩 기능을 추가, 제거 또는 향상시킬 수 있습니다.

    자세한 내용은 클래스 및 형식 리팩터링을 참조하십시오.

  • 기존 코드를 검사합니다.

    종종 특정 모듈에 버그가 모여 있습니다. 새 코드에 문제가 없지만 이전 코드의 특정 모듈에 버그가 있으면 해당 모듈만 검사합니다. 새 코드가 이전 코드와 너무 섞여 있을 경우 리팩터링을 수행하면 문제 해결에 도움이 될 수 있습니다. 자세한 내용은 C/C++ 코드 오류 검색 및 수정관리 코드 오류 검색 및 수정을 참조하십시오.

  • 디버거에서 모든 코드 경로를 단계별로 실행합니다.

    코드를 확인하는 가장 좋은 방법 중 하나는 디버거에서 코드를 단계별로 실행하는 것입니다. 각 줄에서 예상되는 동작이 실제로 발생하고 있는지 확인합니다. 디버거에서 모든 코드 경로를 단계별로 실행하는 것은 한 줄씩 단위 테스트를 수행하는 것과 같습니다. 이 과정은 지루하지만 예상 동작을 효율적으로 확인할 수 있습니다.

권장되지 않는 사항

  • 요구 사항 문서를 사양으로 사용

    요구 사항 문서의 사양을 해석하지 마십시오. 본인의 해석이 프로그램 관리자나 테스터의 해석과 다를 수 있습니다. 해석이 다르면 다른 사람들이 예상하는 대로 구현할 수 없게 됩니다.