Compartilhar via

Diretrizes para verificar no código de qualidade

  • Artigo

A lista a seguir fornece várias diretrizes para verificação da qualidade do código.

Necessário

  • Insistir na qualidade no check-in.

    Não aceitar baixa qualidade durante o check-in do código; isso posteriormente leva a problemas no ciclo do produto. Constatar que equipes normalmente não corrigem problemas que são muito complexos, muito pouco conhecidos, ou descobertos muito tarde no ciclo do produto.

  • Usar listas de verificação.

    Controlar os tipos de erros que você normalmente comete e usá-los como uma lista de verificação para futuros códigos. Você pode iniciar sua lista de verificação com erros comuns que seu grupo ou divisão cometeram e depois personalizar essa lista para seu uso.

  • Conduzir revisões do código.

    Revisões do código oferecem a você uma oportunidade para explicar e melhor compreender seu próprio código, e dá a outros usuários a oportunidade para exibir seu código de uma nova maneira.

  • Compor testes de unidade.

    A melhor maneira para garantir qualidade é compor testes que validam dados e algoritmos e verificar que erros anteriores não são recorrentes. Existem quatro tipos de testes de unidade:

    • Testes positivos de unidade executam o código como desejado e verificam o resultado correto.

    • Testes negativos de unidade intencionalmente fazem mau uso do código e testam a robustez e o tratamento de erros apropriados.

    • Testes de estresse levam o código aos seus limites, esperando expor um discreto recurso, temporização, ou erros reentrantes.

    • Testes de falha de injeção expõem anomalias de tratamento de erros.

    Para obter mais informações, consulte Criando e executando testes de unidade para o código existente.

  • Usar ferramentas de análise de código.

    A maneira mais simples de detectar erros com antecedência é aumentar o nível de aviso no seu compilador e usar ferramentas de análise de código. Os pontos críticos são nunca ignorar um aviso e corrigir o código.

    Para mais informações, consulte Analisando qualidade de código gerenciado usando a análise de código.

    Analisar a qualidade do código C/C++ usando a análise de código e Analisando o código do banco de dados para melhorar a qualidade do código.

  • Não use linguagem inapropriada no seu código-fonte.

    Você não deve ter qualquer linguagem e referências inadequadas em seu código-fonte. Muitos clientes em todo o mundo são altamente confidenciais para determinadas fases ou nomes, particularmente referências a entidades políticas cujo status podem estar em questão. Procure em seu código-fonte por referências e linguagem politicamente confidenciais e então depois relate quaisquer erros.

  • Criar itens de trabalho.

    Não esquecer trabalho incompleto; certifique-se em criar itens de trabalho para comentários TODO, REVIEW, BUG, e UNDONE. Para obter mais informações, consulte Criar um Item de trabalho.

Evitar

  • Recursos sem uma especificação.

    Não escrever código sem uma especificação. Primeiro, compor uma especificação e revisá-la. Sem uma especificação, é impossível para a equipe de teste saber o que está funcionando direito e o que não está. Se você codifica sem uma especificação, você pode se confundir mutuamente, confundindo o que seu cliente deseja, e enviar um produto de qualidade ruim. Para obter mais informações, consulte Planejando e acompanhando projetos.

  • Acessando o meio da primeira etapa sem a instalação do produto no local.

    A equipe de teste deve ter alguma maneira de configurar o produto em seus computadores, mesmo que somente seja uma instalação protótipo. Para obter mais informações, consulte Construção do aplicativo.

Recomendável

  • Use um estilo consistente de codificação.

    Quando sua equipe inteira codifica no mesmo estilo, o produto obtém legibilidade, consistência, sustentabilidade, e qualidade em geral. As especificações das próprias diretrizes não são tão importantes. O que é importante é estabelecer algumas diretrizes e tornar que sua equipe siga as orientações fielmente. As vantagens principais que resultam da escolha de qualquer estilo são a consistência e a facilidade de reconhecer padrões de codificação. Escolha um estilo e use-o.

  • Compor testes de unidade antes de você escrever o código.

    Desenvolvimento de primeiro teste é uma metodologia chave de desenvolvimento ágil e programação extrema. Você realiza várias metas de qualidade escrevendo primeiro testes de unidade:

    • Você garante que testes de unidade sejam escritos.

    • Você garante que seu código possa ser testado facilmente, no qual frequentemente leva a melhor coesão de código e interdependência entre módulos.

    • Você frequentemente descobre o design adequado para seu trabalho através determinando primeiro como o design deve ser testado.

    Para obter mais informações, consulte Criando e executando testes de unidade para o código existente.

  • Tornar seu código portátil para outras plataformas.

    A criação e codificação para portabilidade torna seu código mais robusto, mesmo se você nunca pretender realmente enviar seu código para outra plataforma. Quando você faz código portátil, você:

    • Faz melhores suposições.

    • É mais claro sobre os tipos de dados e a intenção de design.

    • Certifica que seu código é mais capaz de oferecer suporte a novas plataformas no futuro.

  • Refatorar um código existente em funções menores.

    A refatoração pode trazer nova vida ao código antigo. Tentar corrigir grandes sistemas antigos pode ser difícil, porque alguns são tão complexos em suas interações que você será relutante em alterar mesmo um comentário.

    Para refatorar com êxito, primeiro você deve incorporar um forte teste de unidade para garantir que a refatoração não introduzirá novos erros. Em seguida, separe as grandes funções em coleções de funções menores sem alterar a funcionalidade a todo momento. As diretrizes são:

    • Cada função menor deve executar apenas um tipo de tarefa, como a interface do usuário, acesso de banco de dados, interação COM para uma única interface, e assim por diante.

    • Após você ter completamente refatorado todas as funções em um subsistema, você pode alterar funções pequenas individuais sem afetar o sistema inteiro. Você pode adicionar, remover, ou aperfeiçoar a funcionalidade de uma função ao mesmo tempo.

    Para obter mais informações, consulte Refatoração de Classes e tipos (Designer de classe).

  • Revise o código existente.

    Erros geralmente congregam-se em módulos específicos. Quando o novo código está limpo mas são determinados módulos do seu código antigo que abrigam " bugs ", revise apenas esses módulos. Se o novo código está muito entrelaçado com o antigo código, a refatoração poderá frequentemente ajudar a resolver problemas.

    Para mais informações, consulte Analisando qualidade de código gerenciado usando a análise de código.

    Analisar a qualidade do código C/C++ usando a análise de código e Analisando o código do banco de dados para melhorar a qualidade do código.

  • Percorrer todos os caminhos do código em um depurador.

    Uma das melhores maneiras de se verificar código é percorrê-lo em um depurador. Em cada linha, verifique se o que você pretende executar realmente está acontecendo. Percorrer todos os caminhos do código em um depurador é como um teste de unidade linha por linha. O procedimento é tedioso, mas ele efetivamente verifica o comportamento esperado.

Não Recomendado

  • Um documento de requisitos como uma especificação.

    Não tente interpretar a especificação de um documento de requisitos. A interpretação pode ser diferente da interpretação do gerente do programa ou do testador. Se a implementação for diferente, sua implementação não irá estar à altura do que os outros esperam.