O que contém uma revisão de código padrão?

Na minha empresa, é uma discussão por e-mail sobre qual recurso é implementado e que tipo de bug é corrigido, enviado por quem escreve o código. E o revisor, que recebe o correio, revisará o código e discutirá a qualidade e como editar o código em sua opinião. O que contém uma revisão de código padrão?

Na minha experiência, a maioria das revisões formais de código se transforma em verificação de estilo porque é fácil. Mesmo quando você fornece uma lista de itens a serem examinados, é muito fácil para os olhos começarem a vitrificar.

Descobri que a análise do teste de unidade oferece mais benefícios. A maioria dos desenvolvedores com quem trabalhei realmente não sabe como fazer o teste de unidade corretamente, e assim que obtém o "Aha!" No momento, o restante do código também começa a melhorar. Aqui está uma dica: não é um teste de unidade se você exigir que o usuário inspecione algo, e não é um teste de unidade se você está apenas iniciando algo para executar em um depurador.

Tende a variar de acordo com o problema. Muitas vezes é um simples carimbo de borracha. "Aqui está qual era o problema, olhe para esta linha aqui, é óbvio o que está errado, e é aqui que eu a consertei". "Sim, isso é bastante óbvio. Vá em frente e verifique."

Mas quando algo mais envolvido está acontecendo, geralmente é assim:

• Execute Verificar modificações no TortoiseSVN e obtenha uma lista dos arquivos alterados.
• Traga revisor para o seu escritório.
• Explique o problema, com o CR do sistema de rastreamento de bugs aberto para referência.
• Desça a lista de arquivos no TortoiseSVN, abrindo cada um deles no BeyondCompare para visualizar as alterações.
• Se o revisor não entender as alterações, explique o que você fez e por quê.
• O revisor pode perceber algo que não parece bom. Nesse caso, discuta-o até chegar a um acordo sobre se deve ou não ser alterado. (Se forem necessárias alterações simples, você poderá editar o arquivo dentro do BeyondCompare.)
• Se você fez alguma alteração, recompile e verifique se ele foi compilado!
• Execute o programa para demonstrar ao revisor que sua correção realmente funciona.
• Faça o check-in.

IMO, Uma revisão de código não tem nada a ver com recursos ou bugs, mas se concentra na qualidade do código e nos testes escritos para ele.

Então, sente-se ao lado do colega e peça que ele explique o código, ou pegue o código e passe por ele, seja qual for a situação.

Ajuda quando todos programam de acordo com os mesmos padrões e se você emprega ferramentas como o fxCop para automatizar parte do processo.

Eu prefiro a revisão de código em que o desenvolvedor fica com o revisor e passa pela linha de código por linha, explicando-o. Freqüentemente, o desenvolvedor encontrará um problema ao fazer a explicação que o revisor talvez ainda não tenha visto, e é por isso que essa é a minha preferência. Também faço revisões de código onde recebo o código, leio por conta própria e faço comentários, mas acho que elas tendem a demorar mais tempo (reviso e rascunho comentários e envio para o desenvolvedor que os lê e segue WTF, ela quer dizer e e-mails eu volto e explico e, duas ou três rodadas depois, nos reunimos e aponto na tela o que quero dizer e o desenvolvedor diz: "ah, sim, agora eu vejo".) e seja menos produtivo, pois há discussões e discussões menos genuínas. mais, "Você fez isso errado."

Também é essencial impor padrões em uma revisão de código, mas não torná-los o único foco.

No entanto, o código não é enviado para produção até que o revisor de código esteja satisfeito ou o gerente (e não o desenvolvedor) o tenha anulado (os revisores de código também estão errados). Isso é crítico ou a revisão de código é apenas um processo burocrático sem valor agregado, a menos que o revisor de código precise aprovar o código final antes de ser enviado.

Primeiro você precisa ter padrões de codificação e estes são mais do que mera sintaxe. Quando as pessoas começam na sua empresa, elas devem aprender as diretrizes da sua empresa o máximo possível antes de começarem a codificar . Se no processo de revisão forem encontrados todos os tipos de violações, é provável que:

• não ser corrigido devido a restrições de tempo
• encontrado para ser mais irritante do que o que as diretrizes valem

As diretrizes devem fazer sentido e deve haver ferramentas adequadas para encontrar violações e refatorar o mais fácil possível. Sempre observe o objetivo das diretrizes e a revisão de código

O objetivo em minha mente é tornar o código o mais uniforme possível e encontrar problemas com facilidade de manutenção e legibilidade. Um objetivo secundário pode ser obter mais pessoas atualizadas com um determinado software.

As diretrizes em minha mente poderiam, por exemplo, existir de:

• diretrizes gerais de sintaxe e de codificação (escolha uma que já exista e use ferramentas que verificam automaticamente)
• Manuseio de exceção adequado
• Registro adequado
• Bom uso dos paradigmas para a linguagem (SOLID for OO languages)
• Dependências óbvias e bem pensadas entre componentes (use ferramentas como o NDepend)
• Script de construção de trabalho
• Documentação presente (inicialização do desenvolvedor, manual de instalação)
• bibliotecas internas para usar
• políticas da empresa
• ferramentas de terceiros que não são permitidas
• Testes de unidade presentes e sem falhas
• cobertura de código de 90%
• ...

Com isso, a revisão do código consiste no software sendo verificado em relação às diretrizes e:

• discutir violações com o programador
• corrigir violações desnecessárias
• comentar violações necessárias