Ao nos comunicarmos com as pessoas em conferências e nos comentários de artigos, nos deparamos com a seguinte objeção: a análise estática reduz o tempo gasto na busca de erros, mas consome tempo dos programadores, o que elimina o benefício de seu uso e até atrasa o processo de desenvolvimento. Vamos analisar essa objeção e mostrar que ela não tem fundamento.
A afirmação "a análise estática ocupará parte do tempo de trabalho" isoladamente do contexto é verdadeira. A revisão regular de avisos do analisador estático emitidos para código novo ou alterado realmente leva tempo. No entanto, o pensamento deve ser continuado: mas o tempo gasto com isso é muito menor do que o gasto na identificação de erros por outros métodos. Pior ainda é aprender sobre erros dos clientes.
Aqui, testes de unidade podem ser uma analogia muito boa. Os testes de unidade também levam tempo para os desenvolvedores, mas esse não é um motivo para não usá-los. O benefício de escrever códigos melhores e mais confiáveis ao usar testes de unidade excede o custo de escrevê-los.
Outra analogia: avisos do compilador. Geralmente, esse é um tópico muito próximo, pois os avisos das ferramentas de análise estática podem ser vistos como uma primeira aproximação como uma extensão dos avisos do compilador. Naturalmente, quando um programador vê um aviso do compilador, passa um tempo nele. Ele deve alterar o código ou gastar tempo explicitamente suprimindo o aviso, por exemplo, usando #pragma. No entanto, esse tempo não é um motivo para desativar os avisos do compilador. E se alguém fizer isso, será inequivocamente interpretado por outros como inadequação profissional.
No entanto, de onde vem o medo da necessidade de gastar tempo avisando os analisadores de código estático?
Tudo é muito simples. Programadores que ainda são novos nessa metodologia confundem execuções de teste e uso regular. No início, qualquer analisador fornece uma lista enorme de avisos, o que é assustador de se olhar. O motivo é que o analisador ainda não está configurado. Um analisador ajustado gera um pequeno número de falsos positivos durante lançamentos regulares. Em outras palavras, a maioria dos avisos revela defeitos reais ou um código de odor. É importante apenas fazer essa configuração. Esse é o truque que transforma um analisador estático do mal, que leva tempo, em um amigo e ajudante.
Qualquer analisador estático primeiro produzirá muitos falsos positivos. Há muitas razões para isso, e este tópico merece um artigo separado. Naturalmente, nós e os desenvolvedores de outros analisadores
lutamos com falsos positivos. Mas ainda haverá muitos pontos positivos se, sem preparação, você pegar e executar o analisador de repente em algum projeto. A mesma imagem, a propósito, com avisos do compilador. Suponha que você tenha um projeto grande que você sempre criou, por exemplo, usando o compilador Visual C ++. Suponha que o projeto fosse milagrosamente portátil e compilado usando o GCC. Mesmo assim, você receberá uma montanha de avisos do GCC. Qualquer pessoa que tenha experimentado uma mudança de compiladores em um grande projeto entende do que se trata.
No entanto, ninguém obriga a cavar constantemente nas montanhas de lixo a partir de avisos depois de trocar o compilador ou depois de iniciar o analisador. O próximo passo natural é configurar o compilador ou analisador. Aqueles que dizem que “a análise de avisos é demorada” avalia a complexidade da implementação da ferramenta, pensando apenas em todos esses avisos que precisam ser superados no início, mas não pensam no uso regular e calmo.
A configuração de analisadores e compiladores não é tão complicada e trabalhosa quanto os programadores gostam de assustar. Se você é um gerente, não os ouça. Eles são apenas preguiçosos. O programador pode dizer com orgulho como passou 3 dias procurando o bug encontrado pelo testador / cliente. E isso é normal para ele. No entanto, do ponto de vista dele, é inaceitável passar um dia ajustando a ferramenta, após o que um erro semelhante será detectado antes de entrar no sistema de controle de versão.
Sim, alarmes falsos estarão presentes após o ajuste. Mas o número deles é exagerado. É bem possível configurar o analisador para que a porcentagem de falsos positivos seja de 10% a 15%. I.e. para 9 defeitos encontrados, apenas 1 aviso exigirá a supressão como falsa. Então, onde está o "desperdício de tempo" aqui? Ao mesmo tempo, 15% é um valor muito real, que pode ser encontrado em mais detalhes neste
artigo .
Mais uma coisa permanece. O programador pode objetar:
Bem, suponha que execuções regulares de análise estática sejam realmente eficazes. Mas o que fazer com o ruído inicial? Em nosso grande projeto, não poderemos configurar a ferramenta para 1 dia prometido. Apenas uma recompilação para verificar o próximo lote de configurações leva várias horas. Não estamos prontos para passar algumas semanas em tudo isso.E isso não é um problema, mas uma tentativa de encontrar uma razão para não introduzir algo novo. Obviamente, tudo não é fácil em um projeto grande. Mas, primeiro, fornecemos suporte e ajudamos a integrar o PVS-Studio no processo de desenvolvimento. E segundo, não é necessário começar a classificar todos os avisos.
Como seu aplicativo funciona, significa que os erros não são tão críticos e provavelmente residem no código raramente usado. Erros evidentes graves já foram encontrados e corrigidos usando métodos mais lentos e mais caros. Mas sobre isso abaixo em uma
nota . Agora algo mais é importante para nós. Não faz sentido se envolver em edições massivas no código, corrigindo muitos erros menores. Com tanta refatoração, algo é fácil de quebrar e haverá mais mal do que bem.
É melhor considerar os avisos existentes como uma dívida técnica. Será possível voltar a endividar mais tarde e trabalhar gradualmente com avisos antigos. Usando
o mecanismo de supressão de alerta em massa , você pode começar a usar rapidamente o PVS-Studio em um projeto grande. Muito brevemente, acontece assim:
- Você exclui diretórios explicitamente redundantes (bibliotecas de terceiros) da análise. De qualquer forma, essa configuração é melhor executada desde o início para reduzir o tempo de análise.
- Você tenta o PVS-Studio e estuda os avisos mais interessantes . Você gosta dos resultados e mostra a ferramenta para colegas e superiores. A equipe decide iniciar seu uso regular.
- O projeto está sendo verificado. Todos os avisos encontrados são desativados usando o mecanismo de supressão em massa. Em outras palavras, todos os avisos disponíveis no momento são considerados uma dívida técnica, que pode ser devolvida posteriormente.
- O arquivo resultante com avisos suprimidos é estabelecido no sistema de controle de versão. Este arquivo é grande, mas não é assustador. Você faz essa operação uma vez (ou, pelo menos, faz muito raramente). E agora esse arquivo aparecerá em todos os desenvolvedores.
- Agora, todos os desenvolvedores veem avisos que se aplicam apenas ao código novo ou alterado. A partir deste momento, a equipe começa a se beneficiar da análise estática. Configure gradualmente o analisador e faça dívidas técnicas.
A propósito, o sistema para armazenar avisos desinteressantes é inteligente o suficiente. Os hashes são armazenados para uma sequência com um erro em potencial, assim como para o anterior e o próximo. Por esse motivo, se uma linha for adicionada ao início de um dos arquivos, nada "corroerá" e o analisador continuará silencioso sobre o código considerado um dever técnico.
Espero que tenhamos conseguido dissipar um dos preconceitos em relação à análise estática. Venha, faça o
download e experimente o nosso analisador de código estático PVS-Studio. Ele detectará muitos erros nos estágios iniciais e tornará seu código como um todo mais confiável e de alta qualidade.
NotaAo desenvolver qualquer projeto, novos erros aparecem constantemente e são corrigidos. Erros não detectados "se estabelecem" no código por um longo tempo e, em seguida, muitos deles podem ser detectados ao executar a análise de código estática. Por esse motivo, às vezes há uma falsa sensação de que os analisadores estáticos encontram apenas alguns erros desinteressantes em seções de código raramente usadas. Obviamente, esse é o caso se você usar o analisador incorretamente e executá-lo apenas de tempos em tempos, por exemplo, pouco antes do lançamento do release. Mais sobre este tópico
aqui . Sim, ao escrever artigos, nós mesmos realizamos verificações únicas de projetos abertos. Mas temos um objetivo diferente. Queremos demonstrar os recursos de um analisador de código para detectar defeitos. Essa tarefa tem pouco a ver com melhorar a qualidade do código do projeto como um todo e reduzir os custos associados à correção de erros.
Links adicionais:- ROI do PVS-Studio .
- A análise estática melhorará a base de código de projetos complexos em C ++ .
- Heisenbug 2019. Relatório de Ivan Ponomarev " Análise Contínua de Código Estático ".
- Ivan Ponomarev. Incorpore a análise estática ao processo, não procure bugs .
Se você deseja compartilhar este artigo com um público que fala inglês, use o link para a tradução: Andrey Karpov.
Manipulação de objeções: a análise estática ocupará parte do tempo de trabalho .