정적 코드 분석의 실제 이점은 무엇입니까?

pc-lint 또는 QAC 와 같은 도구를 사용하여 코드 기반에서 정적 코드 분석을 수행 할 수 있습니다.

내 경험상 정적 분석은 종종 엄청난 양의 소음, 즉 실제 버그는 아니지만 주어진 규칙 세트의 규칙 중 하나를 위반하는 것에 대한 경고를 생성합니다. 특정 규칙을 해제하면 (규칙 세트에서 또는 코드의 특수 주석을 통해) 실제로 번거로운 프로세스가 될 수 있습니다.

정적 코드 분석의 실제 이점은 무엇입니까?

Coverity Prevent라는 상용 정적 코드 분석 시스템을 사용하는 곳에서 근무했는데 놀라웠습니다! 정말 정교하고 지능적입니다.

우리는 약 18GB의 오픈 소스와 독점적 인 C 및 C ++ 코드를 모두 던졌으며 코드 경로를 추적하고 사람을 영원히 추적하는 미묘한 버그를 신속하게 찾을 것입니다. 또한 일반적으로 Heisenbugs가 될 것들을 정확하게 찾아내는 데에도 도움이되었습니다.

코드베이스에 대해 며칠마다 실행되었으며, "이것은 실제로 버그가 아닙니다."라고 말할 수 있다는 좋은 기능이 있었으며 앞으로는이를 기억할 것입니다.

문제는 Coverity가 정말 비싸다는 것입니다. 그들은 비용을 공개하지 않지만 상업 프로젝트의 경우 매년 수십만 달러에서 시작한다는 것을 알게되었습니다. 그러나 아마도 많은 개발자와 QA 직원을 고용해야 할 필요가 있었으므로 전체적으로 우리 경영진은 그것이 좋은 구매라고 생각하는 것처럼 보였습니다.

그런 경험이 있었기 때문에 정적 코드 분석에 상당히 유리합니다.

새로운 언어로 시작할 때 코치를 갖는 것이 좋습니다. 이것이 정적 분석 도구에 대한 생각입니다. 나는 많은 자바 스크립트를 작성하고 처음에는 주로 초기 언어에서 일부를 전송했기 때문에 몇 가지 나쁜 습관을 선택했습니다. 자바 스크립트는 매우 유연하므로 거의 모든 것을 벗어날 수 있지만 특정 패턴에 대해 jslint에게 경고하면 나중에 물건을 다시 배우지 않고 처음부터 더 나은 코딩 패턴을 선택했을 것입니다.

정적 분석기는 기본적으로 기계 보조 코드 검토입니다. 정기적 인 테스트 중에 놓칠 수있는 의심스러운 영역을 지적합니다.

예를 들어, 저자는이 조건부에서 과제를 작성한다는 의미입니까?

if (x = 1) {
    ...
}

또는 신인이 어휘 캐스팅을 혼란스럽게 할 수도 있습니다.

char* number = "123";
int converted = number;

확실히 정적 분석기는 조정이 필요합니다. 그런 다음 개정판 제어, 위키, 버그 추적기, 예쁜 프린터 및 기타 도구도 일부 설정이 필요합니다. 프로젝트가 클수록 초기 노동에 대한 보상이 향상됩니다.

컨설턴트의 관점에서 볼 때 모든 정적 분석 도구에는 약간의 노이즈가 있지만 모든 정적 분석기가 동일한 것은 아닙니다. Coverity, Klocwork, Grammatech와 같은 정적 분석 도구에는보다 정확한 결과를 생성하는 우수한 분석 기술이 있습니다. 더 많은 것을 조정하고 조정하면 일반적으로 더 나은 결과를 얻을 수 있습니다 (결국 정적 분석기는 소형 의료 기기에서 네트워크 운영 체제에 이르기까지 모든 유형의 코드에서 실행될 수 있어야합니다). "노이즈"정의는 수정 가능한 보고서를 구성하는 기준에 따라 달라집니다. 스펙트럼의 한쪽 끝에서 일부 개발자는 수정하지 않은 모든 보고서를 "거짓"(고칠 시간이없는 잘못 작성된 코드조차도)으로 표시하고 다른 쪽 끝에서는

이러한 도구 중 일부는 중앙 집중식 분석에 중점을두고 있으며 다른 도구는 데스크톱 중심에 있습니다. @Bob이 언급했듯이 비용이 들었습니다.

이전 회사에서는 Parasoft의 정적 분석기를 사용했습니다. 또한 팀 내에서 런타임 버그의 60 % 이상이 컴파일 전에 발견되었다고 믿었습니다.

소프트웨어 코드에 대한 수동 검토를 수행하여 도구없이 정적 분석을 수행 할 수도 있습니다. 이것은 종종 코드 품질을 향상시키는 가장 비용 효율적인 방법입니다.

두 번째로 가장 좋은 방법은 하나 이상의 고급 정적 분석 도구 (앞서 언급 한 Coverity 또는 KLOCwork)에 투자하는 것입니다. 예를 들어 이러한 도구는 보푸라기보다 훨씬 심도있는 분석을 수행하므로 신호 대 잡음비가 훨씬 좋습니다.

노이즈 수준이 높기 때문에 보푸라기를 세 번째 옵션으로 사용하는 것이 좋습니다. 기존 프로젝트에 보푸라기를 적용하는 것은 어려운 작업이 될 수 있습니다.

일반적으로 정적 프로그램 분석은 최근 몇 년 동안 많이 진행되었습니다. 현재 정적 분석 도구는 심도 깊은 절차 분석을 수행 할 수 있으며, 예를 들어 절차 사전 및 사후 조건을 자동으로 식별 할 수 있습니다. 이것은 나중에 코드 검토에 큰 도움이 될 수 있습니다.

오 탐지율이 높기 때문에 각 컴파일에 정적 분석 도구 (예 : lint 또는 FindBugs)를 사용해서는 안됩니다.

오히려 버그가 있고 알아낼 수 없으면 상담하는 것이 좋은 위생 검사 입니다. 이 경우, 오 탐지를 즐길 수 있으며 이미 가능한 오류의 원인을 좁 혔을 수 있습니다. 예를 들어, 일부 모듈을 실행하지 않고 버그를 재현하면 FindBugs의 버그를 무시할 수 있습니다. 이것은 당신이 코드의 조각을보고 할 때 특히 유용합니다 생각 (당신이있을 때 자바에서와 같이 컴파일러가 문자 그대로 그것을 읽는 반면,이 한 가지를 말한다 equals하여 클래스의 타입 대신에 걸리는 방법 Object).

정적 분석 도구를 개발 프로세스의 일부로 만들 수도 있습니다. 개발자가 코드 검토를 받으면 FindBugs도 실행해야합니다. 간단히 말해서 유용하지만 컴파일러 나 텍스트 편집기만큼 자주 사용하지는 않습니다.