Como lidar com objeções: a análise estática ocupará parte do tempo de trabalho

Conversando com pessoas em conferências e em comentários a artigos, enfrentamos a seguinte objeção: a análise estática reduz o tempo para detectar erros, mas consome o tempo dos programadores, o que nega os benefícios de usá-lo e até atrasa o processo de desenvolvimento. Vamos esclarecer essa objeção e tentar mostrar que ela não tem fundamento.

A afirmação "a análise estática retira parte do tempo de trabalho" retirada do contexto está correta. Definitivamente, leva algum tempo para revisar regularmente os avisos do analisador emitidos para código novo ou modificado. No entanto, devemos continuar a ideia: mas o tempo gasto com isso é muito menor que o tempo necessário para encontrar erros por outros métodos. É ainda pior descobrir erros dos usuários.

Os testes de unidade podem ser uma analogia muito boa aqui. Os testes de unidade também levam tempo dos desenvolvedores, mas não é o motivo para não usá-los. Os benefícios de um código mais seguro e de melhor qualidade ao usar testes de unidade superam o custo de escrevê-los.

Outra analogia: avisos do compilador. Este é geralmente um tópico muito próximo, pois os avisos das ferramentas de análise estática podem ser considerados como uma extensão dos avisos do compilador, até certo ponto. Naturalmente, quando um programador vê um aviso do compilador, passa algum tempo lidando com ele. Ele precisa alterar o código ou claramente passar algum tempo suprimindo avisos, por exemplo, usando #pragma. No entanto, esse compromisso de tempo nunca foi o motivo para desativar os avisos do compilador. E se alguém fizer isso, será inequivocamente interpretado por outros como incapacidade profissional.

No entanto, de onde vem o medo de perder tempo com avisos de analisadores de código estático?

A resposta é muito simples. Programadores que ainda não estão familiarizados com essa metodologia confundem lançamentos de teste e uso regular. Na primeira execução, qualquer analisador fornece uma lista enorme de avisos, o que é assustador de se olhar. O motivo é que o analisador ainda não está configurado. Enquanto um analisador configurado emite um pequeno número de falsos positivos sendo usado regularmente. Em outras palavras, a maioria dos avisos indica defeitos reais ou odores de código. É apenas importante fazer essa configuração. Esse é o truque que transforma um analisador estático de um mal que desperdiça tempo em um amigo e um assistente.

Qualquer analisador estático emitirá primeiro muitos falsos positivos. Há muitas razões para isso, e este tópico merece um artigo separado. Naturalmente, os desenvolvedores de outros analisadores e nossa equipe estão lutando contra falsos positivos. Mas ainda haverá muitos avisos, se você apenas pegar e executar o analisador em um projeto pela primeira vez. A propósito, a mesma situação ocorre com os avisos do compilador. Suponhamos que você tenha um projeto grande que sempre o construiu, por exemplo, com o compilador Visual C ++. Digamos que o projeto milagrosamente acabou sendo portátil e compilado usando o GCC. Mesmo assim, você receberá vários avisos do GCC. Pessoas que sofreram alterações de compiladores em um grande projeto entendem do que estou falando.

No entanto, ninguém está forçando você a cavar constantemente as pilhas de avisos depois de mudar o compilador ou depois de executar o analisador. O próximo passo óbvio é configurar um compilador ou analisador. Aqueles que dizem que "a análise de avisos é demorada" avaliam a complexidade da adoção da ferramenta, pensando apenas em todos esses avisos que precisam ser superados no início, mas não pensam no uso regular e sem pressa.

A configuração de analisadores e compiladores não é tão difícil e exige muito trabalho quanto os programadores gostam. Se você é gerente, não ouça. Eles estão apenas sendo preguiçosos. O programador pode dizer com orgulho como estava procurando por um erro encontrado pelo testador / cliente por 3 dias. E isso é bom para ele. No entanto, do ponto de vista dele, não é aceitável passar um dia configurando a ferramenta, após o que esse erro será detectado antes de entrar no sistema de controle de versão.

Sim, falsos positivos estarão presentes após a instalação. Mas o número deles é exagerado. É bem possível configurar um analisador para que a porcentagem de falsos positivos seja de 10% a 15%. Ou seja, 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; você pode ler mais sobre isso neste artigo .

Há mais uma coisa. Um programador pode objetar:

Bem, digamos que análises regulares de estática sejam realmente eficazes. Mas o que fazer com o barulho que recebo na primeira vez? Em nosso grande projeto, não poderemos configurar a ferramenta para um dia prometido. Apenas a recompilação para verificar o próximo lote de configurações leva várias horas. Não estamos prontos para passar algumas semanas nisso.

E isso não é um problema, mas uma tentativa de encontrar uma razão para não introduzir algo novo. Obviamente, em um grande projeto, tudo é sempre difícil. Mas, primeiro, fornecemos suporte e ajudamos a integrar o PVS-Studio ao processo de desenvolvimento. E em segundo lugar, não é necessário começar imediatamente a classificar todos os avisos.

Se o seu aplicativo funcionar, os bugs existentes no site não são tão críticos e provavelmente residem no código raramente usado. Erros óbvios graves já foram encontrados e corrigidos usando métodos mais lentos e mais caros. Vou escrever sobre isso abaixo na nota . Não é isso que é de grande importância agora. Não faz sentido fazer edições massivas no código, corrigindo muitos erros insignificantes. Com uma refatoração tão grande, é fácil quebrar alguma coisa e o dano será mais que bom.

É melhor considerar a dívida técnica dos avisos existentes. Você pode retornar à dívida posteriormente e trabalhar gradualmente com os avisos antigos. Usando o mecanismo de supressão de avisos em massa, você pode começar a usar o PVS-Studio rapidamente em um projeto grande. Aqui está uma breve descrição do que está acontecendo:

1. Você exclui diretórios obviamente redundantes (bibliotecas de terceiros) da análise. É melhor fazê-lo desde o início, a fim de reduzir o tempo de análise.
2. Você tenta o PVS-Studio e investiga os avisos mais interessantes . Você gosta dos resultados e mostra a ferramenta para colegas e chefes. A equipe decide começar a usá-lo regularmente.
3. O projeto está sendo verificado. Todos os avisos suprimidos são desativados usando o mecanismo de supressão em massa. Em outras palavras, todos os avisos que você tem neste momento agora são considerados como dívida técnica que pode ser revisada posteriormente.
4. O arquivo resultante com avisos suprimidos entra no sistema de controle de versão. Este arquivo é grande, mas está tudo bem. Você executa essas ações apenas uma vez (ou, pelo menos, muito raramente). E agora todos os desenvolvedores terão esse arquivo.
5. Agora, todos os desenvolvedores veem avisos relacionados apenas ao código novo ou modificado. A partir desse momento, a equipe começa a se beneficiar da análise estática. Em seguida, você gradualmente configura o analisador e lida com a dívida técnica.

A propósito, o sistema de armazenamento para avisos desinteressantes é bastante inteligente. Os hashes são salvos para a linha com um erro em potencial, bem como para a linha anterior e a próxima. Como resultado, se você adicionar uma linha no início de um dos arquivos, nada se perderá e o analisador permanecerá em silêncio pelo código, que é considerado uma dívida técnica.

Espero ter conseguido dissipar um dos preconceitos sobre 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 geralmente mais confiável e melhor.

Nota

Ao desenvolver qualquer projeto, novos erros aparecem constantemente e são corrigidos. Erros não encontrados "se estabelecem" no código por um longo tempo e, em seguida, muitos deles podem ser detectados quando a análise de código estática é aplicada. Às vezes, isso dá a falsa impressão de que os analisadores estáticos encontram apenas alguns erros desinteressantes em partes de código raramente usadas. Bem, é verdade - se você usar o analisador incorretamente e executá-lo apenas de tempos em tempos, por exemplo, pouco antes do lançamento. Mais sobre este tópico está escrito aqui . Sim, nós mesmos fazemos verificações únicas de projetos de código aberto ao escrever artigos. Mas temos um propósito diferente. Nosso foco é demonstrar as habilidades do analisador de código para detectar defeitos. De um modo geral, essa tarefa tem pouco a ver com melhorar a qualidade do código do projeto e reduzir o custo de correção de erros.

Links adicionais

1. ROI do PVS-Studio .
2. Por que a análise estática pode melhorar uma base de código C ++ complexa .
3. Ivan Ponomarev. Introduzir análise estática no processo, não basta procurar por erros com ele .