⏪ 👌🏼 🌉 Por que você deve escolher o estático analisador PVS-Studio para integrar no seu processo de desenvolvimento ⏪ ❔ 💃🏻

O PVS-Studio é uma ferramenta para detectar bugs e possíveis vulnerabilidades no código-fonte de programas gravados em C, C ++, C # ou Java, e também é uma ferramenta de teste de segurança de aplicações estáticas (SAST). Ele deve ser usado como parte da prática do IC e permite ao usuário detectar erros nos estágios iniciais de desenvolvimento, onde eles custam quase nada para corrigir.

Análise de código estático

À medida que os projetos de software se desenvolvem, eles aumentam de tamanho. Compare:

Kernel do Linux 1.0.0: 176.000 LOC
Linux kernel 5.0: 26.000.000 LOC
Photoshop 1.0: 128.000 LOC
Photoshop CS 6: 10.000.000 LOC

À medida que o projeto cresce, sua complexidade cresce mais rapidamente do que linearmente. Isso explica por que a densidade de erros aumenta junto com a base de código. Uma das maneiras de compensar a crescente complexidade é usar ferramentas de análise de código estático.

Um analisador estático é uma ferramenta de software que executa uma revisão preliminar do código e aponta fragmentos de código que provavelmente contêm erros. Isso permite que os desenvolvedores corrijam a maioria dos bugs no estágio inicial de desenvolvimento, onde eles são mais baratos de corrigir.

A análise estática não substitui - mas complementa - outras práticas de detecção de erros, como revisão de código, teste de unidade, análise dinâmica, teste de regressão, teste manual e assim por diante.

Veja a revisão do código , por exemplo. Um cenário muito melhor é fazer com que um analisador de software encontre os bugs mais triviais para você, para que você possa se concentrar em verificações de alto nível mais úteis do algoritmo, em vez de descobrir funções de comparação - tanto mais que, conforme nossa experiência prova, o olho humano é ruim em perceber muitos dos bugs e é muito provável que sejam ignorados durante a revisão do código.

Outra vantagem das ferramentas de análise estática é a extensa base de padrões de erros. Eles podem encontrar defeitos que muitos programadores podem nem conhecer, como V698 , V718 , V1023 .

PVS-Studio

Recomendamos escolher o PVS-Studio, um analisador de código estático desenvolvido por nossa equipe. É executado nos sistemas Windows, Linux e macOS de 64 bits e pode verificar o código-fonte dos programas para plataformas ARM de 32 bits, 64 bits e incorporadas.

No momento da redação deste documento, o analisador suporta os seguintes idiomas e compiladores:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, Compilador C / C ++ para ARM C, C ++
Windows Momentics QNX, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, Compilador ARM 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Ferramentas de geração de código ARM C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, compilador Arm Embedded GCC, C, C ++
Windows / Linux / macOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / macOS. Java

O analisador vem com documentação detalhada em inglês e russo. As descrições das regras de diagnóstico incluem exemplos de código correto e incorreto. Eles também incluem links para trechos de código de programas reais de código aberto.

Para os especialistas que usarão o PVS-Studio como ferramenta SAST , os diagnósticos são mapeados para a Enumeração de Fraqueza Comum, os Padrões de Codificação SEI CERT e o padrão MISRA. Aqui estão as tabelas de mapeamento dos diagnósticos do PVS-Studio para diferentes padrões:

O analisador pode ser usado como uma ferramenta independente e como um plug-in para o Visual Studio e o IntelliJ IDEA. Alguns de nossos clientes também usam o PVS-Studio como parte do SonarQube recentemente. Quando usado como um plug - in para o SonarQube, o analisador fornece mensagens de diagnóstico adicionais.

Desenvolvemos vários cenários de uso do PVS-Studio com sistemas de CI. Como a observação de todos os cenários está fora do escopo deste artigo, consulte a documentação. Aqui estão apenas alguns links para lhe dar uma idéia geral:

O PVS-Studio detecta efetivamente uma ampla variedade de falhas, desde erros de digitação até vazamentos de memória . Isso é possível graças à análise do fluxo de dados, execução simbólica, correspondência de padrões e anotação de método (incluindo anotação automática). Para saber mais sobre os princípios de trabalho por trás do analisador, consulte o artigo " Tecnologias usadas no analisador de código PVS-Studio para encontrar erros e possíveis vulnerabilidades ".

Por que você deve usar o PVS-Studio

A integração do PVS-Studio ao seu processo de desenvolvimento tornará muitos bugs mais baratos de corrigir, ajudando assim a economizar tempo, o que você poderá investir na implementação de um novo recurso ou na realização de testes de alto nível mais detalhados.

Se usado regularmente, o analisador acabará por ajudá-lo a melhorar a qualidade do seu código, facilitando a manutenção. A correção regular de bugs e a prática de escrever código de alta qualidade o tornarão menos suscetível a vulnerabilidades do dia zero. Este assunto é discutido em mais detalhes no artigo " Como o PVS-Studio pode ajudar na detecção de vulnerabilidades? ".

O PVS-Studio é mais econômico quando usado por equipes de cinco membros ou mais. A estimativa de ROI é fornecida no artigo " PVS-Studio ROI ".

A integração do PVS-Studio em projetos desenvolvidos por alguns entusiastas provavelmente seria impraticável, mas até pequenos projetos podem se beneficiar disso - tanto mais que fornecemos opções de licenciamento gratuitas para estudantes, desenvolvedores de código aberto etc.

Nossos novos clientes geralmente adquirem uma licença de um ano. Quando expirar, eles já estarão satisfeitos com os recursos do nosso analisador e o serviço de suporte ao usuário e renovarão a licença por dois ou três anos, o que é muito mais barato que a licença de um ano. Você pode solicitar os preços e solicitar conselhos sobre licenciamento aqui .

Torne-se nossos clientes e deixe o PVS-Studio tornar seu processo de desenvolvimento mais maduro, a correção de erros mais barata e o seu código melhor.

Por sua vez, forneceremos suporte rápido e competente. Suas perguntas serão respondidas diretamente pelos programadores que desenvolvem os módulos específicos em questão. Isso garante uma resposta mesmo nas situações mais complicadas. Aqui está um exemplo: " Falsos positivos no PVS-Studio: quão profunda é a toca do coelho ".

Respondendo a críticas

Às vezes, os programadores são negativos quanto à idéia de incluir a análise de código estático em seu processo de desenvolvimento e criticam o método de análise estática em geral ou o PVS-Studio em particular. Quando você começa a se aprofundar, as críticas deles são infundadas e são simplesmente o produto de sua relutância em mudar qualquer coisa no processo de desenvolvimento estabelecido. Vamos ver quais argumentos típicos para não mudar a situação em que eles recorrem e o que há de errado com eles.

"A análise estática ocupará uma certa quantidade do seu tempo de trabalho"

Fora de contexto, a afirmação "a análise estática estará ocupando uma parte do seu tempo de trabalho" é verdadeira. Leva algum tempo para examinar regularmente os avisos emitidos pelo analisador em busca de código recém-escrito ou modificado. Mas essa idéia precisa ser continuada: "mas levará muito menos tempo do que outros métodos de detecção de erros".

Por que as pessoas acreditam que o exame do relatório de um analisador estático é demorado?

Os programadores que ainda não estão familiarizados com o método de análise de código confundem execuções de teste únicas e uso regular. Quando executado pelas primeiras vezes, qualquer analisador gera uma lista enorme de avisos, com uma alta taxa de falsos positivos. Isso acontece porque a ferramenta ainda não foi personalizada. Com as configurações ajustadas para atender às suas necessidades exatas, você não verá muitos falsos positivos se executar o analisador regularmente. Em outras palavras, com o uso regular, a maioria dos diagnósticos do analisador detectará falhas genuínas ou código de odor. Você só precisa fazer isso.

O artigo " Lidando com objeções: a análise estática ocupará parte do tempo de trabalho " é elaborado sobre o assunto.

“Analisadores estáticos produzem muito ruído (isto é, muitos falsos positivos)”

Novamente, essa afirmação é verdadeira quando você não personalizou adequadamente a ferramenta. Depois de ajustar as configurações do PVS-Studio conforme necessário, você pode esperar que a taxa de falsos positivos caia para 10-20%. Ou seja, de cada cinco avisos, quatro apontam para erros ou códigos genuínos que provavelmente se tornarão a fonte de erros no futuro. O artigo " Características do PVS-Studio Analyzer pelo exemplo de bibliotecas principais do EFL, 10 a 15% de falsos positivos " mostra um exemplo de personalização do analisador.

Outra fonte de conceitos errôneos é a tentação de ativar o maior número possível de diagnósticos, sem conhecer seu objetivo exato. Por exemplo, se você ativar o conjunto de regras MISRA, projetado para sistemas incorporados, ao verificar um aplicativo clássico do Windows, o analisador gerará centenas de milhares de avisos, nenhum dos quais lhe será útil. Diagnósticos irrelevantes são especialmente prejudiciais quando você está começando a usar a ferramenta, pois pode ter uma impressão errada sobre seus recursos de diagnóstico. O artigo " Como verificar rapidamente avisos interessantes fornecidos pelo analisador PVS-Studio para códigos C e C ++? " O ajudará a evitar a decepção.

"A integração da análise estática no processo de desenvolvimento é muito cara em termos de esforço, tempo e dinheiro"

Essa preocupação é vividamente ilustrada pelo seguinte comentário:

Infelizmente, os próprios analisadores estáticos nada mais são do que brinquedos. É um trabalho árduo tentar torná-los parte do seu processo de trabalho de rotina e exige a designação de alguns funcionários para examinar e filtrar os resultados da análise. Qualquer tentativa de colocar esse fardo em desenvolvedores comuns geralmente não tem sucesso.

Não é tão horrível. Existem pelo menos três práticas para integrar suavemente a análise estática, mesmo em grandes projetos antigos.

Prática 1. "Catraca", que é bem explicada por Ivan Ponomarev em seu artigo " Introduzir análise estática no processo, não basta procurar bugs com ela ".

Prática 2. Para ajudar nossos usuários a começar rapidamente, recomendamos o uso da " base de supressão ". Em poucas palavras, a idéia é que você execute o analisador e receba vários avisos. Como o projeto está em desenvolvimento há muitos anos e ainda está vivo, evoluindo e lucrativo, é improvável que você receba muitos avisos apontando para defeitos críticos. Em outras palavras, a maioria dos erros críticos já foram corrigidos usando outros meios - mais caros - ou em resposta ao feedback dos usuários. Nesse caso, quaisquer que sejam os bugs encontrados durante a primeira verificação, eles podem ser vistos como dívida técnica, o que não seria razoável se apressar em corrigir imediatamente.

Você pode dizer ao PVS-Studio para tratar esses avisos como irrelevantes (adiando a resolução da dívida técnica até mais tarde) e não mostrá-los novamente. O analisador criará um arquivo especial armazenando as informações sobre os bugs irrelevantes no momento e emitirá avisos apenas para códigos modificados ou gravados recentemente. O mecanismo é bastante inteligente. Por exemplo, se você adicionar uma linha vazia no início de algum arquivo .cpp, o analisador entenderá que essa linha não faz diferença e permanecerá em silêncio. O arquivo de supressão pode ser controlado por versão. É grande, mas não importa, porque você não precisa controlá-lo com frequência.

Depois disso, todos os programadores da sua equipe receberão apenas os avisos acionados por um código recém-escrito ou modificado. A partir do dia seguinte, você poderá usar o analisador como parte de seu trabalho de rotina. Quanto à dívida técnica, você poderá alcançá-la mais tarde, corrigir gradualmente os erros e ajustar as configurações do analisador conforme necessário.

Prática 3. Você pode delegar a tarefa de configurar e integrar o PVS-Studio à nossa equipe, estabelecendo um contrato conosco. Um exemplo dessa prática é descrito no artigo " Como a equipe do PVS-Studio melhorou o código do Unreal Engine ".

"Executamos o analisador, mas não encontramos nada de interessante"

Esse cenário é bem possível, mas ainda não significa que o analisador não será útil. O problema é que os erros já foram encontrados e corrigidos usando outros meios mais caros. É como alimentar um texto já verificado por vários revisores no Microsoft Word para ver se a verificação ortográfica interna pode encontrar alguma coisa. Encontraria apenas alguns erros, se houver algum, mas isso não significa que a verificação ortográfica do Word seja inútil ao escrever novos textos.

Este assunto é discutido em mais detalhes no artigo " Filosofia da análise de código estático: temos 100 desenvolvedores, o analisador encontrou poucos erros, o analisador é inútil? ".

"Um analisador estático é uma ferramenta cara; é melhor contratar um programador / testador adicional »

O que esse argumento realmente diz é que a pessoa não quer mudar nada. Afinal, sua equipe vem crescendo e contratando novos programadores e testadores há algum tempo, mas isso não ajudou a alcançar um processo de desenvolvimento mais maduro. Dito isto, ainda devemos elaborar esse argumento.

Primeiro, contratar outra pessoa para pesquisar bugs é muito mais caro do que comprar um analisador estático. Basta calcular a folha de pagamento anual do novo funcionário e adicionar os impostos e despesas na configuração de um novo espaço de trabalho. Considerando os números resultantes, o argumento sobre um analisador de software ser muito caro não parece ser um argumento. Além disso, um analisador estático, diferentemente dos humanos, não tira férias nem licença médica ou deixa a empresa por completo. Para uma equipe grande, digamos, 100 pessoas, você precisaria contratar não um, mas vários novos funcionários para alcançar qualquer resultado perceptível. Nesse caso, a compra de um analisador estático se torna uma solução ainda mais favorável.

Segundo, o melhor resultado é alcançado através da sinergia entre várias técnicas de detecção de erros usadas em combinação. Alguns erros são melhor diagnosticados através de testes de unidade, outros através de testes manuais e assim por diante. Imagine ter 10 programadores trabalhando em um projeto, com muitos testes de unidade, mas não um único testador. Os usuários não estão satisfeitos com a qualidade do projeto; portanto, é necessário contratar um testador, mas você não o faz porque "é melhor contratar um programador adicional, para que haja ainda mais testes de unidade!" não é uma decisão sábia, pode? Nesse cenário, o processo de controle de qualidade é obviamente unilateral e só ganharia com a adição de testes manuais. O mesmo se aplica à análise estática.

"A análise dinâmica é melhor que a análise estática"

Alguns erros são melhor diagnosticados por analisadores estáticos, outros por analisadores dinâmicos. Esses tipos de ferramentas se complementam , para que você não precise escolher apenas uma.

Por exemplo, analisadores dinâmicos não conseguem detectar códigos inacessíveis e muitos dos erros causados por erros de digitação. Alguns dos tipos de análise dinâmica de erros são difíceis de encontrar, descritos no artigo " Verificando o código do analisador dinâmico Valgrind por um analisador estático ".

"O teste de unidade é melhor que a análise estática"

Se você escolher entre escrever testes de unidade e usar análise estática, eu diria que os testes são mais importantes e valiosos. Mas você não precisa escolher; você deve usar o teste de unidade e a análise estática. Essas técnicas funcionam muito bem juntas.

Aqui estão os argumentos para usar a análise estática junto com o teste de unidade:

Os testes em si não são testados e geralmente contêm erros. Em nossos artigos, mostramos muitos exemplos de erros encontrados em testes de unidade em projetos reais. A análise estática pode encontrar erros nos testes, os quais, por sua vez, podem encontrar erros no código principal.
É difícil cobrir todo o código com testes, especialmente as partes que lidam com o tratamento de exceções. Ao contrário deles, os analisadores estáticos verificam todo o código.
Alguns erros são extremamente difíceis, se possível, de serem detectados através de testes de unidade. V597 (CWE-14) é um exemplo.
Alguns erros se manifestam apenas quando o programa trabalha com grandes quantidades de dados, por isso é impraticável simular essas situações em testes de unidade. Um exemplo é o estouro de uma variável de 32 bits em um programa de 64 bits ( V108 , V127 ).
Quando um teste não passa, o erro pode ser encontrado com mais facilidade e rapidez executando o analisador estático do que depurando. Certamente, os testes de unidade encontrariam mais erros, mas quando você pode pegá-los usando uma técnica mais barata (ou seja, análise estática), por que não fazer isso?
Encontramos pilhas de bugs em vários projetos. Muitos deles estão muito cobertos de testes, mas, como você pode ver, eles não ajudam muito. Portanto, não há razão para você não adotar a análise estática, além dos testes de unidade, para aprimorar a qualidade e a confiabilidade do seu código.

"Compiladores gratuitos contemporâneos podem encontrar os mesmos erros que o PVS-Studio"

Certamente, os compiladores estão evoluindo e adquirindo novos avisos, que podem detectar bugs. Mas você não pode esperar muitos compiladores em comparação com soluções proprietárias profissionais, como o PVS-Studio.

Razões para escolher o PVS-Studio:

Suporte eficiente ao usuário
Infraestrutura altamente desenvolvida (integração com outros produtos)
Poderosos recursos de diagnóstico

Os dois primeiros motivos já são suficientes para mudar a escala para a escolha do PVS-Studio, mas vamos falar sobre o diagnóstico também. Estamos constantemente aprimorando nosso produto para ficar à frente de outros fornecedores. Por exemplo, nossa ferramenta pode detectar um bug interessante descrito no artigo " 31 de fevereiro ".

Sabendo que tudo o que foi dito acima não é suficiente para fazer os céticos mudarem de idéia, verificamos os compiladores de vez em quando para mostrar que eles também têm bugs, que o PVS-Studio pode detectar:

PS

Se você ainda duvida se deve usar o PVS-Studio, basta olhar para esta lista de erros encontrados em vários projetos .

Por que você deve escolher o estático analisador PVS-Studio para integrar no seu processo de desenvolvimento