팀의 사기를 저하시키지 않고 레거시 프로젝트에서 정적 코드 분석기를 구현하는 방법

정적 코드 분석기를 사용해 보는 것은 쉽습니다. 그러나 이를 구현하려면, 특히 대규모의 오래된 프로젝트를 개발할 때 기술이 필요합니다. 잘못 수행할 경우 분석기는 작업을 추가하고 개발 속도를 늦추며 팀의 사기를 저하시킬 수 있습니다. 정적 분석을 개발 프로세스에 통합하는 데 올바르게 접근하는 방법과 이를 CI/CD의 일부로 사용하는 방법에 대해 간략하게 설명하겠습니다.

소개

최근에 "라는 출판물에 관심을 끌었습니다.팀에 부담을 주지 않고 정적 해석 시작하기". 한편으로는 알아갈 가치가 있는 좋은 기사입니다. 다른 한편으로는 많은 프로젝트에서 정적 분석을 고통 없이 구현하는 방법에 대한 완전한 답변을 아직 제공하지 못하는 것 같습니다. 기사에는 기술 부채를 받아들이고 새 코드에서만 작업할 수 있다고 나와 있지만 나중에 이 기술 부채를 어떻게 해야 하는지에 대한 답은 없습니다.

우리 PVS-Studio 팀은 이 주제에 대한 견해를 제시합니다. 정적 코드 분석기 구현 문제가 애초에 어떻게 발생하는지, 이 문제를 어떻게 극복하는지, 그리고 어떻게 점진적으로 기술적 부채를 고통 없이 해소할 수 있는지 살펴보겠습니다.

문제

일반적으로 정적 분석기를 시작하고 작동 방식을 확인하는 것은 어렵지 않습니다.1]. 코드에서 흥미로운 오류나 무서운 잠재적인 취약점을 발견할 수도 있습니다. 뭔가를 고칠 수도 있지만 그러면 많은 프로그래머가 포기합니다.

모든 정적 분석기는 거짓 긍정을 생성합니다. 이는 정적 코드 분석 방법론의 기능이며 이에 대해 수행할 수 있는 작업은 없습니다. 일반적인 경우 이는 라이스의 정리(Rice's theorem)로 확인된 바와 같이 풀 수 없는 문제이다.2]. 기계 학습 알고리즘은 [3]. 사람이 이 코드나 저 코드가 틀린지 항상 알 수 없더라도 프로그램에서 이것을 기 대해서는 안됩니다 :).

정적 분석기가 이미 구성되어 있으면 거짓 긍정은 문제가 되지 않습니다.

• 관련 없는 규칙 세트를 비활성화했습니다.
• 일부 관련 없는 진단이 비활성화되었습니다.
• C 또는 C++에 대해 이야기하는 경우 매크로가 사용되는 모든 위치에 쓸모없는 경고가 표시되도록 하는 특정 구성을 포함하는 매크로가 마크업됩니다.
• 시스템 기능과 유사한 작업을 수행하는 자체 기능이 표시됩니다(자체 아날로그 밈피 또는 printf)4];
• 주석을 사용하면 거짓양성을 특별히 비활성화할 수 있습니다.
• 등등.

이 경우 약 10~15%의 낮은 오탐률을 예상할 수 있습니다.5]. 즉, 분석기 경고 9개 중 10개는 코드의 실제 문제 또는 적어도 "냄새가 강한 코드"를 나타냅니다. 동의하세요. 이 시나리오는 매우 즐겁고 분석기는 프로그래머의 진정한 친구입니다.

실제로 대규모 프로젝트에서는 초기 그림이 완전히 다릅니다. 분석기는 레거시 코드에 대해 수백 또는 수천 개의 경고를 발행합니다. 이러한 경고 중 어떤 경고가 관련이 있고 어떤 경고가 관련이 없는지 빠르게 이해하는 것은 불가능합니다. 이 경우 주요 작업이 며칠 또는 몇 주 동안 중단되기 때문에 앉아서 이러한 모든 경고를 처리하기 시작하는 것은 비합리적입니다. 일반적으로 팀은 그러한 시나리오를 감당할 수 없습니다. 또한 변경 기록을 망치는 엄청난 수의 diff가 있을 것입니다. 그리고 코드의 너무 많은 조각을 빠르게 대량 편집하면 필연적으로 새로운 오타와 오류가 발생하게 됩니다.

그리고 가장 중요한 것은 경고에 맞서 싸우는 그러한 위업이 거의 의미가 없다는 것입니다. 프로젝트가 수년 동안 성공적으로 진행되었기 때문에 프로젝트의 심각한 오류 중 대부분이 이미 수정되었다는 점에 동의하십시오. 예, 이러한 수정 사항은 매우 비용이 많이 들고 디버깅해야 했으며 버그에 대한 부정적인 사용자 피드백을 받았습니다. 정적 분석기는 코딩 단계에서 이러한 많은 오류를 빠르고 저렴하게 수정하는 데 도움이 됩니다. 그러나 현재 어떤 식으로든 이러한 오류는 수정되었으며 분석기는 주로 이전 코드에서 중요하지 않은 오류를 감지합니다. 이 코드는 사용되지 않을 수도 있고 매우 드물게 사용될 수도 있으며 오류가 있어도 눈에 띄는 결과가 발생하지 않을 수 있습니다. 버튼의 그림자가 어딘가에 잘못된 색상일 수도 있지만 이는 제품 사용에 지장을 주지 않습니다.

물론 사소한 실수라도 여전히 실수입니다. 때로는 실수로 인해 실제 취약점이 숨겨질 수도 있습니다. 그러나 모든 것을 포기하고 거의 나타나지 않는 결함을 처리하는 데 며칠 또는 몇 주를 소비하는 것은 모호한 생각처럼 보입니다.

프로그래머는 이전 작업 코드에 대한 이러한 모든 경고를 보고, 보고, 살펴봅니다. 그리고 그들은 정적 분석 없이도 할 수 있다고 생각합니다. 새롭고 유용한 기능을 작성해 보겠습니다.

나름대로 그들은 옳습니다. 그들은 먼저 이 모든 경고를 어떻게든 제거해야 한다고 생각합니다. 그래야만 코드 분석기를 정기적으로 사용하여 이점을 얻을 수 있습니다. 그렇지 않으면 새로운 경고가 기존 경고에 묻혀버리고 아무도 이에 주의를 기울이지 않을 것입니다.

이는 컴파일러 경고와 동일한 비유입니다. 컴파일러 경고 수를 0으로 유지하도록 권장하는 것은 이유가 없습니다. 경고가 1000개이고 1001개가 있으면 아무도 이에 주의를 기울이지 않을 것이며 이 최신 경고를 어디에서 찾아야 할지 명확하지 않습니다.

이 이야기에서 최악의 상황은 지금 위에서 누군가가 정적 코드 분석을 사용하도록 강요하는 경우입니다. 이는 팀의 의욕을 떨어뜨릴 뿐입니다. 왜냐하면 팀의 관점에서는 방해가 되는 추가적인 관료적 복잡성이 있을 것이기 때문입니다. 누구도 분석기의 보고서를 보지 않으며 모든 사용은 "종이"로만 이루어집니다. 저것들. 공식적으로 분석은 DevOps 프로세스에 내장되어 있지만 실제로는 누구에게도 도움이 되지 않습니다. 부스에서 컨퍼런스 참석자들의 자세한 이야기를 들었습니다. 그러한 경험은 프로그래머가 영원히는 아니더라도 오랫동안 정적 분석 도구를 사용하는 것을 방해할 수 있습니다.

기술 부채 구현 및 제거

사실, 오래된 대규모 프로젝트에도 정적 분석을 도입하는 데에는 어렵거나 두려운 것이 없습니다.

CI / CD

또한 분석기는 지속적인 개발 프로세스의 일부로 즉시 포함될 수 있습니다. 예를 들어, PVS-Studio 배포판에는 필요한 형식으로 보고서를 편리하게 볼 수 있는 유틸리티와 문제가 있는 코드 섹션을 작성한 개발자에게 보내는 알림이 포함되어 있습니다. CI/CD 시스템에서 PVS-Studio를 시작하는 데 더 관심이 있는 분들은 해당 내용을 숙지하시기 바랍니다. 부분 문서 및 일련의 기사:

• PVS-Studio가 클라우드로 이동: Azure Devops
• PVS-Studio가 클라우드로 이동합니다: Travis CI
• PVS-Studio가 클라우드로 이동: GitLab CI/CD
• PVS-Studio가 클라우드로 이동합니다: CircleCI

하지만 코드 분석 도구 구현의 첫 번째 단계에서 발생하는 다수의 오탐 문제로 돌아가 보겠습니다.

기존 기술 부채 해결 및 새로운 경고 처리

최신 상용 정적 분석기를 사용하면 새 코드 또는 변경된 코드에 나타나는 새로운 경고만 연구할 수 있습니다. 이 메커니즘의 구현은 다양하지만 본질은 동일합니다. PVS-Studio 정적 분석기에서는 이 기능이 다음과 같이 구현됩니다.

정적 분석을 빠르게 시작하려면 PVS-Studio 사용자가 경고 대량 억제 메커니즘을 사용하는 것이 좋습니다.6]. 일반적인 아이디어는 다음과 같습니다. 사용자가 분석기를 시작하고 많은 경고를 받았습니다. 수년 동안 개발되어 온 프로젝트가 살아 있고 개발되고 돈을 벌고 있기 때문에 보고서에 심각한 결함을 나타내는 경고가 많지 않을 가능성이 높습니다. 즉, 중요한 버그는 더 비싼 방법을 사용하거나 고객의 피드백 덕분에 어떤 식으로든 이미 수정되었습니다. 따라서 분석기가 현재 발견한 모든 것은 기술적 부채로 간주될 수 있으며 즉시 제거하려고 시도하는 것은 비현실적입니다.

PVS-Studio에 현재 이러한 경고를 관련 없는 것으로 간주하도록 지시할 수 있으며(나중에 기술 부채를 아껴두기) 더 이상 해당 경고가 표시되지 않습니다. 분석기는 아직 관심이 없는 오류에 대한 정보를 저장하는 특수 파일을 생성합니다. 이제 PVS-Studio는 새 코드 또는 변경된 코드에 대해서만 경고를 발행합니다. 게다가 이 모든 것이 영리하게 구현되었습니다. 예를 들어, 소스 코드 파일의 시작 부분에 빈 줄이 추가되면 분석기는 실제로 아무것도 변경되지 않았음을 이해하고 계속 침묵할 것입니다. 이 마크업 파일은 버전 제어 시스템에 포함될 수 있습니다. 파일 용량이 크긴 하지만 자주 저장해도 소용이 없기 때문에 문제가 되지 않습니다.

이제 모든 프로그래머는 새 코드 또는 변경된 코드와 관련된 경고만 볼 수 있습니다. 따라서 다음 날부터 분석기를 사용할 수 있습니다. 그리고 나중에 기술 부채로 돌아가 점진적으로 오류를 수정하고 분석기를 구성할 수 있습니다.

따라서 대규모 오래된 프로젝트에서 분석기 구현과 관련된 첫 번째 문제가 해결되었습니다. 이제 기술 부채로 무엇을 해야할지 알아 보겠습니다.

버그 수정 및 리팩토링

가장 간단하고 자연스러운 것은 대량으로 억제된 분석기 경고를 분석하고 점진적으로 처리하는 데 시간을 할애하는 것입니다. 코드의 오류를 수정해야 하는 곳, 리팩터링하여 코드에 문제가 없음을 분석기에게 알려야 하는 곳입니다. 간단한 예:

if (a = b)

대부분의 C++ 컴파일러와 분석기는 실제로 코드를 작성하고 싶을 가능성이 높기 때문에 그러한 코드에 대해 불평합니다. (a == b). 그러나 무언의 합의가 있으며 이는 일반적으로 문서에 언급되어 있습니다. 추가 괄호가 있으면 프로그래머가 의도적으로 그러한 코드를 작성한 것으로 간주되므로 맹세할 필요가 없습니다. 예를 들어 진단을 위한 PVS-Studio 문서에서 V559 (CWE-481) 다음 줄은 정확하고 안전한 것으로 간주된다는 것이 명확하게 기록되어 있습니다.

if ((a = b))

다른 예시. 이 C++ 코드에서 잊어버렸나요? 하다 안 그래?

case A:
  foo();
case B:
  bar();
  break;

PVS-Studio 분석기는 여기서 경고를 표시합니다. V796 (CWE-484). 이는 오류가 아닐 수 있습니다. 이 경우 속성을 추가하여 구문 분석기에 힌트를 제공해야 합니다. [[실패로 끝나다]] 또는 예를 들어 __속성__((폴스루)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

이러한 코드 변경으로는 버그가 수정되지 않는다고 할 수 있습니다. 네, 맞습니다. 하지만 두 가지 유용한 일을 합니다. 첫째, 분석기 보고서는 오탐지를 제거합니다. 둘째, 코드 유지 관리에 참여하는 사람들이 코드를 더 쉽게 이해할 수 있습니다. 그리고 이것은 매우 중요합니다! 이것만으로도 코드를 더 명확하고 유지 관리하기 쉽게 만들기 위해 사소한 리팩토링을 수행할 가치가 있습니다. 분석기는 "break"가 필요한지 여부를 이해하지 못하므로 동료 프로그래머에게도 불분명합니다.

버그 수정 및 리팩토링 외에도 명백히 잘못된 분석기 경고를 구체적으로 억제할 수 있습니다. 일부 관련 없는 진단은 비활성화될 수 있습니다. 예를 들어 경고가 무의미하다고 생각하는 사람이 있습니다. V550 float/double 값 비교에 대해 알아보세요. 그리고 어떤 사람들은 그것들을 중요하고 연구할 가치가 있는 것으로 분류합니다.7]. 어떤 경고가 관련성이 있다고 간주되고 어떤 경고가 그렇지 않은지 결정하는 것은 개발 팀에 달려 있습니다.

잘못된 경고를 억제하는 다른 방법이 있습니다. 예를 들어 매크로 마크업은 앞에서 언급했습니다. 이 모든 내용은 문서에 더 자세히 설명되어 있습니다. 가장 중요한 것은 오탐지 작업에 점진적이고 체계적으로 접근하면 아무런 문제가 없다는 것을 이해하는 것입니다. 흥미롭지 않은 경고의 대부분은 구성 후에 사라지고, 실제로 신중한 조사가 필요한 부분과 코드의 일부 변경 사항만 남습니다.

또한, 어려움이 발생할 경우 항상 고객이 PVS-Studio를 설정할 수 있도록 도와드립니다. 또한, 허위 경고를 자체적으로 삭제하고 오류를 수정한 사례도 있었습니다.8]. 만일을 대비해, 확장된 협력을 위한 이 옵션도 가능하다는 점을 언급하기로 결정했습니다. :).

래칫 방식

정적 분석기 경고를 제거하여 코드 품질을 점진적으로 향상시키는 또 다른 흥미로운 접근 방식이 있습니다. 결론은 경고 횟수가 줄어들 수 있다는 것입니다.

정적 분석기에서 발생한 경고 수가 기록됩니다. 품질 게이트는 이제 작업 수를 늘리지 않는 코드만 입력할 수 있도록 구성되었습니다. 결과적으로, 분석기를 조정하고 오류를 수정하는 것부터 점차적으로 알람 수를 줄이는 프로세스가 시작됩니다.

어떤 사람이 약간의 부정 행위를 원하고 새 코드에서 경고를 제거하는 것이 아니라 이전 타사 코드를 개선하여 품질 게이트를 통과하기로 결정하더라도 이것은 두렵지 않습니다. 마찬가지로 래칫은 한 방향으로 회전하며 점차적으로 결함 수가 감소합니다. 어떤 사람이 자신의 새로운 결함을 고치고 싶지 않더라도 여전히 이웃 코드에서 뭔가를 개선해야 합니다. 어떤 시점에서는 경고 횟수를 줄이는 쉬운 방법이 종료되고 실제 버그가 수정되는 시점이 옵니다.

이 방법론은 Ivan Ponomarev의 매우 흥미로운 기사에 자세히 설명되어 있습니다.버그를 찾는 데 사용하는 대신 프로세스에 정적 분석을 구현합니다.", 코드 품질 향상에 관심이 있는 모든 사람에게 읽어볼 것을 권장합니다.

기사의 저자도 이 주제에 대한 보고서를 가지고 있습니다: "지속적인 정적 분석".

결론

이 기사를 읽고 나면 독자들이 정적 분석 도구를 더 많이 받아들이고 이를 개발 프로세스에 구현하기를 원하게 되기를 바랍니다. 궁금한 점이 있으시면 언제든지 준비되어 있습니다. 권하다 정적 분석기 PVS-Studio 사용자 및 구현에 도움을 드립니다.

정적 분석이 실제로 편리하고 유용할 수 있는지에 대한 또 다른 일반적인 의구심이 있습니다. 나는 "PVS-Studio 정적 코드 분석기를 개발 프로세스에 도입하는 이유"라는 출판물에서 이러한 의심의 대부분을 없애려고 노력했습니다.9].

많은 관심과 방문 부탁드립니다 다운로드 PVS-Studio 분석기를 사용해 보세요.

추가 링크

1. 안드레이 카르포프. PVS-Studio 분석기가 C 및 C++ 코드에 대해 생성하는 흥미로운 경고를 어떻게 빨리 볼 수 있습니까?
2. 위키 백과 (Wikipedia). 라이스의 정리.
3. 안드레이 카르포프, 빅토리아 카니에바. 프로그램 소스 코드의 정적 분석에 기계 학습 사용.
4. PVS-스튜디오. 선적 서류 비치. 추가 진단 설정.
5. 안드레이 카르포프. EFL 핵심 라이브러리의 예를 사용한 PVS-Studio 분석기의 특성, 10-15% 오탐률.
6. PVS-스튜디오. 선적 서류 비치. 분석기 메시지의 대량 억제.
7. 이반 안드리아신. X선 혈관내 수술 교육용 시뮬레이터 프로젝트에서 정적 분석을 테스트한 방법에 대해.
8. Pavel Eremeev, Svyatoslav Razmyslov. PVS-Studio 팀이 Unreal Engine 코드를 개선한 방법.
9. 안드레이 카르포프. 개발 프로세스에 정적 코드 분석기 PVS-Studio를 도입하는 이유.

이 기사를 영어권 청중과 공유하려면 번역 링크인 Andrey Karpov를 사용하십시오. 레거시 프로젝트에 정적 코드 분석기를 도입하고 팀을 낙담시키지 않는 방법.

출처 : habr.com