como lidar com um analisador estático de saída

StackOverflow https://stackoverflow.com/questions/2070397

  •  20-09-2019
  •  | 
  •  

Pergunta

Começamos usando um analisador estático (Coverity) em nossa base de código.Fomos prontamente estupefata pela enorme quantidade de avisos que recebemos (seu centenas de milhares) , vai levar toda a equipe de alguns meses para limpar todos eles (obliviously impossível).

as opções que temos discutido até agora são

1) contratar um empreiteiro para classificar o aviso e corrigi - los- ele desvantagem:provavelmente vamos precisar muito de experiências de pessoas para fazer todas essas modificações, e não empreiteiro terá necessário o entendimento do código.

2) filtrar o aviso e lidar somente com as perigosas - o problema aqui é que a nossa análise estática de saída será sempre cheia de aviso, tornando difícil isolar problemas.também a filtragem do aviso é também um grande esforço.

de qualquer forma, trazendo o nosso código para um estado quando o analisador estático pode ser uma ferramenta útil para nós parece uma tarefa monumental.

então, como é possível trabalhar com o analisador estático, sem braining atuais esforços de desenvolvimento em uma completa ficar parado?

Foi útil?

Solução

A primeira coisa a fazer é ajustar as configurações de sua análise; O suporte à cobertura provavelmente o deixou com uma configuração bastante genérica.

  • Triagem Uma amostra representativa dos defeitos e, se um verificador não parece estar produzindo muito mais sinal do que ruído, desligue -o por enquanto. (A maioria dos damas da cobertura é boa, mas ninguém é perfeito, e parece que você precisa fazer uma priorização implacável.)
    • A longo prazo, ligue alguns desses verificadores, mas marque -os em seus relatórios como baixa prioridade. (Isso é mais difícil do que deveria; há muito tempo argumentei que a cobertura precisa ler alguns papéis sobre classificação de defeitos por alguém chamado Dawson Engler. :-)
    • Na execução ainda mais longa, tente os damas que são desativados por padrão; Alguns deles encontram insetos impressionantes. E os avisos de Parse são surpreendentemente úteis, embora você precise desligar alguns falsos.
  • Seja cinicamente realista sobre qual parte da sua base de código você realmente corrigirá em breve. Use componentes para pular a análise no código em que você não consertará defeitos, pelo menos por enquanto. (Por exemplo, em teoria, se o seu produto incluir código de terceiros, você é responsável por sua qualidade e deve corrigir bugs nele. Na prática, esses bugs raramente são corrigidos. E se for um código de terceiros maduros, o falso A taxa positiva será alta.)
    • Configurar componentes e exclusão é complicado, mas uma vez feito, eles funcionam bem-um dos meus regexes negativos e seguintes tinham mais de cem disjunções.
    • Os componentes também ajudam a atribuir a responsabilidade individual por defeitos, que achei crucial para corrigi -los.
  • Configure um relatório para apenas novos defeitos e peça às pessoas que assistem esse URL. Novos defeitos estão em código ativo e é mais fácil começar com uma política de não avisos.

Deixe -me terminar com algumas isenções de responsabilidade:

  • Você pode querer realizar novamente esta pergunta no fórum de suporte à cobertura (http://forums.coverity.com/), que não é muito ativo, mas onde não precisamos nos preocupar em violar o NDA. Eu tenho uma lista dos damas que achei que vale a pena permitir.

  • Eu faço isso para viver, e talvez você queira nos contratar (http://codeintegritysolutions.com/); Estou dando uma palestra sobre esse assunto em Stanford hoje. Contratar um consultor para fazer o ajuste faz muito sentido; Ter alguém fora da empresa fazendo o triplo é mais complicado. Ter um estranho a fazer as correções ainda é mais complicado; Aprender com seus erros é ainda mais importante do que consertá -los.

Outras dicas

Um dia por semana: ligue a análise; Escolha os 100 avisos mais irritantes; Consertá-los; Desligue a análise. Em resumo: não entre em pânico; Seu código funciona como está (não é?); Trabalhe através dos avisos em pedaços pequenos.

Se você achar que os mesmos tipos de avisos continuam reaparecendo (más práticas de codificação), eduque sua equipe para evitá -los no futuro.

Fiz isso com uma antiga base de código: eu entrava de manhã cedo (antes do resto da equipe), aumentava o nível de aviso/análise no compilador, conserte alguns avisos e depois o colocou de volta aos padrões.

  1. Para código legado. Priorize esses insetos de Leagcy e faça um plano para lidar com eles. Balance a correção de bugs e o desenvolvimento de novos recursos. O novo recurso é sempre mais importante.
  2. Para novo código. Faça parte do seu processo de integração: antes de verificar no novo código, verifique se eles estão livres de cobertura.

Para a opção do seu contratante, você pode seguir uma rota mais moderada e fazer com que eles corram apenas os problemas claros, locais e não precisam de um entendimento completo do seu código. Eu acho que um grande número de hits de cobertura são coisas como possíveis desreferências de ponteiro nulo ou possíveis gravações após o final de um buffer que pode ser corrigido com verificações simples que são completamente locais para o código em questão e não precisam de entender o Big Picture.

Vou admitir - eu trabalhei assim antes de usar o pré -rápido/prefixo ou qualquer que seja a ferramenta chamada da Microsoft, e muito disso foi um tipo de alteração mecânica. Bem adequado para um empreiteiro ou talvez até um estagiário. Mas haverá coisas que precisam de mais análises - apenas certifique -se de que está claro para o (s) contratado (s) que eles não devem tentar se aprofundar nas coisas.

E seja legal com eles - é um trabalho de trabalho, então faça o que mais puder agradável.

O pessoal da cobertura nos disse para 'ignorar' todos os avisos na primeira vez em que você o usa. Então, na próxima compilação diferencial, terá avisos incrementalmente novos: que você deve corrigir. Depois de usar a ferramenta por alguns meses e você se sente confortável com ela, volta e começa a consertar os avisos antigos.

Experimente outros analisadores estáticos. Eu costumava trabalhar com o teste C ++ da Parasoft e ele tinha uma maneira conveniente de filtrar avisos de acordo com suas severidades.

Isso significa que você tem problemas em personalizá -lo para suas necessidades?
Como

"Análise personalizável

A análise estática da cobertura fornece a capacidade de ajustar as análises, modificando o número de damas implantados ou as configurações específicas para um verificador individual, como o limite para as desreferências do ponteiro nulo. A capacidade de configurar a cobertura para um bloco de código ou aplicativo específico permite que os desenvolvedores selecionem o nível de desempenho mais apropriado para seu aplicativo e leva a resultados mais precisos e confiáveis. O kit de desenvolvimento de software de cobertura permite detectar tipos exclusivos de defeitos no código C e C ++, criando verificadores personalizados. Além de criar verificadores personalizados para encontrar simultaneidade, manipulação de exceções e outros problemas críticos. ""
http://www.coverity.com/products/static-analysis.html

Típico de fora-da-caixa-análise de configuração para Coverity tendem a dar-se entre um e três defeitos por mil linhas de código.Se você tem centenas de milhares de defeitos, e você tem significativamente menos do que 100 milhões de linhas de código, eu posso garantir que a sua análise de configuração é incorreto ou com qualidade inferior para a sua organização.

Além de ajuste de análise de configuração de si mesmo, você pode priorizar por impacto - padrão "alta", "média" e "baixa" mapeamento deve ser bom o suficiente para você começar até obter uma sensação para a qual subcategorias tendem a ser mais prejudicial para a sua aplicação.

Terceiro, se a sua base de código é grande (e quem não é) dividi-la em componentes para que cada equipe ou grupo de desenvolvedores pode dar uma olhada somente o código diretamente manter - isso permite que os dois mais pedaços gerenciáveis de trabalho para lidar com, e ele também permite que você prioriza na peça (defeitos no código do servidor são mais críticos do que os defeitos no código do cliente, ou de código de teste, ou código de terceiros, etc.).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top