버그를 찾는 데 사용하는 대신 프로세스에 정적 분석을 구현합니다.

점점 더 주목을 받고 있는 정적 분석에 관한 수많은 자료를 보고 이 글을 쓰게 되었습니다. 첫째로, 이 PVS 스튜디오 블로그, 오픈 소스 프로젝트에서 도구에서 발견한 오류에 대한 검토를 통해 Habré에서 적극적으로 홍보하고 있습니다. 최근 PVS-studio 구현 자바 지원, 그리고 물론 현재 Java용으로 가장 발전된 분석기가 내장된 IntelliJ IDEA의 개발자도 마찬가지입니다. 멀리 있을 수 없었어.

이러한 리뷰를 읽으면 마법의 비약에 대해 이야기하고 있다는 느낌을 받게 됩니다. 버튼을 누르면 여기에 결함 목록이 눈앞에 나타납니다. 분석기가 향상됨에 따라 자동으로 더 많은 버그가 발견될 것으로 보이며, 이러한 로봇이 스캔하는 제품은 우리 측의 노력 없이도 점점 더 좋아질 것입니다.

그러나 마법의 비약은 없습니다. 저는 "여기에 우리 로봇이 찾을 수 있는 것들이 있습니다"와 같은 게시물에서 일반적으로 이야기되지 않는 것에 대해 이야기하고 싶습니다. 즉, 분석기가 할 수 없는 것이 무엇인지, 소프트웨어 제공 프로세스에서 분석기가 실제 역할과 위치는 무엇인지, 이를 올바르게 구현하는 방법은 무엇입니까? .

래칫(출처: 위키피디아).

정적 분석기가 절대 할 수 없는 일

실용적인 관점에서 소스 코드 분석이란 무엇입니까? 우리는 일부 소스 코드를 입력 및 출력으로 제공하며 짧은 시간(테스트를 실행하는 것보다 훨씬 짧음)에 시스템에 대한 일부 정보를 얻습니다. 근본적이고 수학적으로 극복할 수 없는 한계는 우리가 이런 방식으로 상당히 좁은 종류의 정보만을 얻을 수 있다는 것입니다.

정적 분석으로 해결할 수 없는 문제의 가장 유명한 예는 다음과 같습니다. 종료 문제: 이는 프로그램의 소스 코드에서 유한한 시간 내에 반복될 것인지 종료될 것인지를 판단할 수 있는 일반적인 알고리즘을 개발하는 것이 불가능함을 증명하는 정리입니다. 이 정리의 확장은 다음과 같습니다. 라이스의 정리, 이는 계산 가능한 함수의 사소하지 않은 속성에 대해 임의의 프로그램이 그러한 속성을 가진 함수를 평가하는지 여부를 결정하는 것이 알고리즘적으로 다루기 힘든 문제임을 나타냅니다. 예를 들어, 분석 중인 프로그램이 정수의 제곱을 계산하는 알고리즘의 구현인지 여부를 소스 코드에서 확인할 수 있는 분석기를 작성하는 것은 불가능합니다.

따라서 정적 분석기의 기능에는 극복할 수 없는 한계가 있습니다. 정적 분석기는 예를 들어 null 값을 허용하는 언어에서 "널 포인터 예외"의 발생이나 모든 경우에 " 동적 유형 언어에서는 속성을 찾을 수 없습니다." 가장 발전된 정적 분석기가 할 수 있는 일은 특수한 사례를 강조하는 것뿐입니다. 소스 코드에서 발생할 수 있는 모든 문제 중에서 그 수는 과장 없이 극소수에 불과합니다.

정적 분석은 버그를 찾는 것이 아닙니다

위에서 결론은 다음과 같습니다. 정적 분석은 프로그램의 결함 수를 줄이는 수단이 아닙니다. 나는 감히 말하고 싶습니다: 프로젝트에 처음으로 적용하면 코드에서 "흥미로운" 위치를 찾을 수 있지만 대부분 프로그램 품질에 영향을 미치는 결함은 찾지 못할 것입니다.

분석기가 자동으로 발견한 결함의 예는 인상적이지만 이러한 예는 대규모 코드베이스 세트를 스캔하여 발견되었다는 사실을 잊지 말아야 합니다. 동일한 원칙에 따라 다수의 계정에 대해 여러 가지 간단한 비밀번호를 시도할 기회가 있는 해커는 결국 간단한 비밀번호가 있는 계정을 찾아냅니다.

이는 정적 분석을 사용하면 안 된다는 뜻인가요? 당연히 아니지! 그리고 각각의 새 비밀번호를 확인하여 해당 비밀번호가 "간단한" 비밀번호 중지 목록에 포함되어 있는지 확인하는 것과 똑같은 이유입니다.

정적 분석은 버그를 찾는 것 이상입니다.

실제로 분석을 통해 실질적으로 해결되는 문제는 훨씬 더 광범위합니다. 결국, 일반적으로 정적 분석은 소스 코드가 출시되기 전에 수행되는 모든 검증입니다. 다음과 같은 작업을 수행할 수 있습니다.

• 가장 넓은 의미에서 코딩 스타일을 확인합니다. 여기에는 서식 확인, 빈/추가 괄호 사용 찾기, 줄 수/메서드의 순환적 복잡성과 같은 측정항목에 대한 임계값 설정 등 코드의 가독성과 유지 관리성을 잠재적으로 방해하는 모든 작업이 포함됩니다. Java에서 이러한 도구는 Python의 Checkstyle - flake8입니다. 이 클래스의 프로그램을 일반적으로 "린터"라고 합니다.
• 실행 가능한 코드만 분석할 수 있는 것은 아닙니다. JSON, YAML, XML, .properties와 같은 리소스 파일은 자동으로 유효성을 검사할 수 있습니다. 결국, 테스트 실행이나 실행 시간보다 자동 Pull Request 검증의 초기 단계에서 페어링되지 않은 일부 인용문으로 인해 JSON 구조가 손상되었음을 알아내는 것이 더 낫습니까? 적절한 도구를 사용할 수 있습니다. YAML린트, JSONLint.
• 컴파일(또는 동적 프로그래밍 언어의 구문 분석)도 정적 분석의 한 유형입니다. 일반적으로 컴파일러는 소스 코드 품질 문제를 나타내는 경고를 생성할 수 있으므로 무시해서는 안 됩니다.
• 때때로 컴파일은 실행 가능한 코드를 컴파일하는 것 이상입니다. 예를 들어, 다음 형식의 문서가 있는 경우 Ascii의사, HTML/PDF로 변환하는 순간 AsciiDoctor 핸들러(Maven 플러그인)는 예를 들어 깨진 내부 링크에 대한 경고를 발행할 수 있습니다. 그리고 이는 문서 변경 사항이 포함된 Pull Request를 수락하지 않는 좋은 이유입니다.
• 맞춤법 검사도 정적 분석의 한 유형입니다. 공익사업 주문 문서뿐만 아니라 C/C++, Java 및 Python을 포함한 다양한 프로그래밍 언어의 프로그램 소스 코드(주석 및 리터럴)에서도 철자를 검사할 수 있습니다. 사용자 인터페이스나 문서의 철자 오류도 결함입니다!
• 구성 테스트(그 내용에 대해 - 참조) 이 и 이 보고서)는 pytest와 같은 단위 테스트 런타임에서 실행되기는 하지만 실제로는 실행 중에 소스 코드를 실행하지 않기 때문에 일종의 정적 분석이기도 합니다.

보시다시피, 이 목록에서 버그를 검색하는 것은 가장 덜 중요한 역할을 하며, 다른 모든 것은 무료 오픈 소스 도구를 사용하여 사용할 수 있습니다.

다음 중 프로젝트에 어떤 유형의 정적 분석을 사용해야 합니까? 물론, 많을수록 좋습니다! 가장 중요한 것은 이를 올바르게 구현하는 것입니다. 이에 대해서는 나중에 설명하겠습니다.

다단계 필터로서의 전달 파이프라인과 첫 번째 단계인 정적 분석

지속적인 통합에 대한 고전적인 비유는 소스 코드 변경부터 전달, 프로덕션까지 변경 사항이 흐르는 파이프라인입니다. 이 파이프라인의 표준 단계 순서는 다음과 같습니다.

1. 정적 분석
2. 편집
3. 단위 테스트
4. 통합 테스트
5. UI 테스트
6. 수동 확인

파이프라인의 N번째 단계에서 거부된 변경 사항은 N+1 단계로 전송되지 않습니다.

왜 정확히 이런 식이고 그렇지 않은 이유는 무엇입니까? 파이프라인의 테스트 부분에서 테스터는 잘 알려진 테스트 피라미드를 인식하게 됩니다.

테스트 피라미드. 원천: 기사 마틴 파울러.

이 피라미드의 맨 아래에는 작성하기 쉽고 실행 속도가 빠르며 실패할 가능성이 없는 테스트가 있습니다. 따라서 더 많은 코드가 있어야 하며 더 많은 코드를 포함하고 먼저 실행되어야 합니다. 피라미드의 꼭대기에는 그 반대가 성립하므로 통합 및 UI 테스트 횟수를 필요한 최소한으로 줄여야 합니다. 이 체인에 있는 사람은 가장 비싸고 느리고 신뢰할 수 없는 리소스이므로 맨 끝에 있으며 이전 단계에서 결함이 발견되지 않은 경우에만 작업을 수행합니다. 하지만 테스트와 직접적인 관련이 없는 부분에서도 파이프라인을 구축하는 데에는 동일한 원칙이 사용됩니다!

나는 다단계 물 여과 시스템의 형태로 비유를 제시하고 싶습니다. 더러운 물(결함이 있는 변화)이 입력으로 공급되고, 출력에서는 원치 않는 오염 물질이 모두 제거된 깨끗한 물을 받아야 합니다.

다단계 필터. 원천: 위키 미디어 공용

아시다시피, 청소 필터는 이후의 각 단계에서 점점 더 미세한 오염 물질을 걸러낼 수 있도록 설계되었습니다. 동시에, 더 거친 정화 단계는 더 높은 처리량과 더 낮은 비용을 제공합니다. 우리의 비유에서 이것은 입력 품질 게이트가 더 빠르고, 시작하는 데 더 적은 노력이 필요하며, 작동 시 더 소박하다는 것을 의미합니다. 이것이 게이트가 구축되는 순서입니다. 우리가 지금 이해하고 있듯이 가장 심각한 결함만 제거할 수 있는 정적 분석의 역할은 필터 캐스케이드의 시작 부분에 있는 "머드" 그리드의 역할입니다.

"머드 필터"가 물을 마실 수 있게 만들지 않는 것처럼 정적 분석 자체로는 최종 제품의 품질이 향상되지 않습니다. 그러나 파이프라인의 다른 요소와 함께 그 중요성은 분명합니다. 다단계 필터에서 출력 단계는 잠재적으로 입력 단계가 수행하는 모든 것을 캡처할 수 있지만 입력 단계 없이 미세 정제 단계만으로 수행하려는 시도로 인해 어떤 결과가 발생할지는 분명합니다.

"머드 트랩"의 목적은 후속 캐스케이드에서 심각한 결함이 발견되는 것을 완화하는 것입니다. 예를 들어, 최소한 코드 검토를 수행하는 사람은 형식이 잘못된 코드와 확립된 코딩 표준 위반(예: 추가 괄호 또는 너무 깊게 중첩된 분기)으로 인해 주의가 산만해져서는 안 됩니다. NPE와 같은 버그는 단위 테스트로 잡아야 하지만, 테스트 전에도 분석기가 버그가 발생할 것이라고 우리에게 알려주면 수정 속도가 크게 빨라집니다.

이제 정적 분석을 가끔 사용하면 제품 품질이 향상되지 않으며, 총 결함이 있는 변경 사항을 필터링하기 위해 지속적으로 사용해야 하는 이유가 분명해졌습니다. 정적 분석기를 사용하면 제품의 품질이 향상되는지 여부에 대한 질문은 "더러운 연못에서 가져온 물을 소쿠리에 통과시키면 식수 품질이 향상됩니까?"라고 묻는 것과 대략 동일합니다.

레거시 프로젝트로 구현

중요한 실제 질문: "품질 게이트"로서 지속적인 통합 프로세스에 정적 분석을 구현하는 방법은 무엇입니까? 자동 테스트의 경우 모든 것이 분명합니다. 일련의 테스트가 있으며 그 중 하나라도 실패하면 어셈블리가 품질 게이트를 통과하지 못했다고 믿을 충분한 이유가 됩니다. 정적 분석 결과를 바탕으로 동일한 방식으로 게이트를 설치하려는 시도가 실패합니다. 레거시 코드에 분석 경고가 너무 많아서 완전히 무시하고 싶지 않지만 제품 배송을 중단하는 것도 불가능합니다. 분석기 경고가 포함되어 있기 때문입니다.

처음 사용할 때 분석기는 모든 프로젝트에서 수많은 경고를 생성하며, 그 중 대부분은 제품의 올바른 기능과 관련이 없습니다. 이러한 모든 주석을 한 번에 수정하는 것은 불가능하며 많은 수정이 필요하지도 않습니다. 결국, 우리는 정적 분석을 도입하기 전에도 우리 제품이 전체적으로 작동한다는 것을 알고 있습니다!

결과적으로 많은 경우 정적 분석을 가끔 사용하는 것으로 제한되거나 분석기 보고서가 어셈블리 중에 간단히 발행되는 정보 모드에서만 사용됩니다. 이는 분석이 없는 것과 동일합니다. 왜냐하면 이미 많은 경고가 있는 경우 코드를 변경할 때 (아무리 심각하더라도) 또 다른 경고가 발생하더라도 눈에 띄지 않게 되기 때문입니다.

품질 게이트를 도입하는 다음과 같은 방법이 알려져 있습니다.

• 총 경고 수 또는 경고 수를 코드 줄 수로 나눈 값에 대한 제한을 설정합니다. 이러한 게이트는 제한을 초과하지 않는 한 새로운 결함이 있는 변경 사항이 자유롭게 통과하도록 허용하기 때문에 이는 제대로 작동하지 않습니다.
• 특정 순간에 코드의 모든 오래된 경고를 무시하도록 수정하고 새로운 경고가 발생할 때 빌드를 거부합니다. 이 기능은 PVS-studio 및 Codacy와 같은 일부 온라인 리소스에서 제공됩니다. Codacy에 대한 내 경험에 따르면 PVS-studio에서 일할 기회가 없었습니다. Codacy의 주요 문제는 "오래된" 오류와 "새로운" 오류가 무엇인지 결정하는 것이 항상 작동하지 않는 다소 복잡한 알고리즘이라는 것입니다. 특히 파일이 많이 수정되거나 이름이 변경된 경우에는 더욱 그렇습니다. 내 경험에 따르면 Codacy는 풀 요청의 새로운 경고를 무시하는 동시에 특정 PR 코드의 변경과 관련되지 않은 경고로 인해 풀 요청을 전달하지 않을 수 있습니다.
• 제 생각에는 가장 효과적인 해결책은 책에 설명된 것입니다. 연속 배달 "래칫 방식". 기본 아이디어는 정적 분석 경고 수는 각 릴리스의 속성이며 총 경고 수를 늘리지 않는 변경만 허용된다는 것입니다.

래칫 휠 장치

다음과 같은 방식으로 작동합니다.

1. 초기 단계에서는 분석기가 발견한 코드의 경고 수 공개에 대한 기록이 메타데이터에 생성됩니다. 따라서 업스트림을 빌드할 때 저장소 관리자는 "릴리스 7.0.2"뿐만 아니라 "7.0.2개의 체크스타일 경고가 포함된 릴리스 100500"를 작성합니다. Artifactory와 같은 고급 저장소 관리자를 사용하는 경우 릴리스에 대한 메타데이터를 쉽게 저장할 수 있습니다.
2. 이제 각 끌어오기 요청은 빌드 시 결과 경고 수를 현재 릴리스에서 사용할 수 있는 경고 수와 비교합니다. PR로 인해 이 숫자가 증가하면 코드는 정적 분석을 위한 품질 게이트를 통과하지 못합니다. 경고 수가 감소하거나 변경되지 않으면 통과합니다.
3. 다음 릴리스에서는 다시 계산된 경고 수가 릴리스 메타데이터에 다시 기록됩니다.

그래서 조금씩이지만 꾸준하게(래칫이 작동할 때처럼) 경고 횟수가 XNUMX이 되는 경향이 있습니다. 물론 새로운 경고를 도입하고 다른 사람의 경고를 수정함으로써 시스템을 속일 수 있습니다. 장거리에 걸쳐 결과를 제공하기 때문에 이것은 정상적인 현상입니다. 경고는 일반적으로 개별적으로 수정되지 않고 특정 유형의 그룹에서 한 번에 수정되며 쉽게 제거 가능한 모든 경고는 매우 빠르게 제거됩니다.

이 그래프는 XNUMX개월 동안 이러한 "래칫"을 작동한 동안 발생한 Checkstyle 경고의 총 횟수를 보여줍니다. 우리 오픈소스 프로젝트 중 하나. 경고 횟수가 대폭 감소했는데, 이는 제품 개발과 병행하여 자연스럽게 발생한 현상입니다!

저는 이 방법의 수정된 버전을 사용하여 프로젝트 모듈과 분석 도구별로 경고를 별도로 계산하여 다음과 같은 빌드 메타데이터가 포함된 YAML 파일을 생성합니다.

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

모든 고급 CI 시스템에서 플러그인 및 타사 도구에 의존하지 않고 모든 정적 분석 도구에 대해 래칫을 구현할 수 있습니다. 각 분석기는 분석하기 쉬운 간단한 텍스트 또는 XML 형식으로 자체 보고서를 생성합니다. 남은 것은 CI 스크립트에 필요한 로직을 작성하는 것뿐입니다. Jenkins 및 Artifactory를 기반으로 한 오픈 소스 프로젝트에서 이것이 어떻게 구현되는지 확인할 수 있습니다. 여기에 또는 여기에. 두 예제 모두 라이브러리에 따라 다릅니다. 래칫립: 방법 countWarnings() Checkstyle 및 Spotbugs가 생성한 파일의 xml 태그를 일반적인 방식으로 계산합니다. compareWarningMaps() 동일한 래칫을 구현하여 카테고리의 경고 수가 증가하면 오류를 발생시킵니다.

aspell을 사용하여 주석, 텍스트 리터럴 및 문서의 철자를 분석하기 위해 "래칫"의 흥미로운 구현이 가능합니다. 아시다시피 맞춤법 검사를 할 때 표준 사전에 알려지지 않은 모든 단어가 틀린 것은 아니며 사용자 사전에 추가할 수 있습니다. 프로젝트 소스 코드의 사용자 정의 사전 부분을 만들면 철자 품질 게이트는 다음과 같이 공식화될 수 있습니다: 표준 및 사용자 정의 사전을 사용하여 aspell을 실행 해서는 안된다. 철자 오류를 발견하지 마십시오.

분석기 버전 수정의 중요성에 대해

결론적으로 주목해야 할 점은 딜리버리 파이프라인에 분석을 어떻게 구현하든 분석기 버전을 고정해야 한다는 것입니다. 분석기가 자발적으로 업데이트되도록 허용하면 다음 끌어오기 요청을 조합할 때 코드 변경과 관련이 없지만 새 분석기가 단순히 더 많은 결함을 찾을 수 있다는 사실과 관련된 새로운 결함이 "팝업"될 수 있습니다. 그러면 끌어오기 요청을 수락하는 프로세스가 중단됩니다. 분석기 업그레이드는 의식적인 조치여야 합니다. 그러나 각 어셈블리 구성 요소 버전의 견고한 고정은 일반적으로 필요한 요구 사항이며 별도의 논의 주제입니다.

조사 결과

• 정적 분석은 버그를 찾아주지 않으며 단일 애플리케이션의 결과로 제품 품질을 향상시키지 않습니다. 품질에 대한 긍정적인 효과는 배송 과정에서 지속적으로 사용해야만 얻을 수 있습니다.
• 버그를 찾는 것은 분석의 주요 작업이 아니며 유용한 기능의 대부분은 오픈 소스 도구에서 사용할 수 있습니다.
• 레거시 코드에 대한 "래칫"을 사용하여 전달 파이프라인의 첫 번째 단계에서 정적 분석 결과를 기반으로 품질 게이트를 구현합니다.

참조

1. 연속 배달
2. A. Kudryavtsev: 프로그램 분석: 자신이 훌륭한 프로그래머인지 이해하는 방법 다양한 코드 분석 방법에 대해 보고합니다(정적 분석뿐만 아니라!)

출처 : habr.com