Como ser melhor na revisão de código?

Primeiro, acredito firmemente no processo de revisão de código e sempre quero que outra pessoa reveja meu código. Minha pergunta realmente gira em torno de como posso fazer um trabalho melhor executando uma revisão de código para outra pessoa?

Eu sei que, para executar uma revisão de código, você precisa ter conhecimento de como o código existente funciona e saber qual é o padrão local, o que eu sinto que conheço muito bem. Ainda sinto que nunca faço uma revisão de código suficientemente boa para outras pessoas. Também sei que certas pessoas parecem fazer um código de revisão de trabalho melhor do que outras, então estou me perguntando para aqueles que são ótimos revisores de código quais são as técnicas que você usa?

Não há como fazer uma melhor revisão de código. A única coisa que você pode fazer é continuar melhorando com o aprendizado e a experiência.

Normalmente as coisas que eu sigo

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Eu acho que há muito o que você pode adicionar.

pergunte a si mesmo o que torna os outros um bom revisor para você?

Além disso, conforme você percorre o código;

• pare com qualquer coisa que você não entende agora e escreva que é necessário um comentário
• identificar se está de acordo com os padrões de codificação: espaços, colchetes, camelCase..etc
• verifique se inclui todas as funcionalidades
• faça testes simples de lógica para ver se ela passa nas condições de contorno etc.

Eu apenas almejo

• explicando por que uma alteração sugerida é necessária. Garantir que eu entenda o motivo e não apenas a correção
• concordar com a formatação do código - para que o código de todos pareça o mesmo / familiar
• compartilhando uma lista de características de código que você deseja manter. Coloque-o em um wiki para que todo mundo não tenha que cometer todos os erros uma vez. Atualize-o com frequência.

Além disso, "saber o que procurar" vem apenas com experiência, prática e leitura.

Na minha experiência, a melhor maneira é deixar a equipe do buraco fazer a revisão do código. Usamos uma lista de emails de confirmação em cada projeto, onde você pode acompanhar todas as alterações de código no sistema de controle de versão. A maioria dos nossos desenvolvedores se inscreveu na lista de discussão específica de seu projeto porque está interessada em alterações de código.

Quando alguém percebe um mau caminho no novo código-fonte, ele explica ao colaborador como ele pode fazê-lo de uma maneira melhor, se o colaborador é um estagiário, ou inicia uma discussão sobre o assunto, se era um colaborador mais experiente.

É claro que esse método não garante que todo o novo código seja revisado, especialmente em momentos estressantes em que nenhum membro da equipe tem tempo para acompanhar cada alteração de código. Além disso, nem todo desenvolvedor é responsável por garantir que todo desenvolvedor faça seu trabalho ser bom, por si só, você não pode garantir que ele seja revisado. Mas, pelo menos em nossas equipes, sempre há um gerente técnico responsável pela qualidade técnica.

Sou um verdadeiro fã de análises de código, se estiverem em conformidade com as seguintes pontuações:

• todo desenvolvedor tem a possibilidade de revisar todo o código e argumento da sua opinião
• ninguém tem o direito de abusar do código de outros
• não apenas código ruim ativa uma discussão, mas também código bom
• as discussões terminam com felicidade para todas as pessoas envolvidas
• a revisão ocorre quase em tempo real, pelo menos antes da conclusão do recurso

O que eu aprendi é que, se você é alguém que analisa cada linha de código e acha que precisa controlar coisas como qualidade de código em termos de formatação ou eficiência de código, então você é ineficiente porque faz o que as máquinas podem fazer você. Seu objetivo deve ser o uso de um sistema de integração contínua que controla a qualidade de construção e código de cada contribuição de código. Se este sistema gerar relatórios e enviá-los aos colaboradores, tudo estará perfeito.

Devo admitir que, se você precisar revisar o código porque precisa controlar ou classificar a qualidade de um programador, minhas sugestões não farão sentido. Nesse caso, eu também não revisaria o código fonte linha por linha. Eu revisaria coisas como:

• existem problemas relevantes de segurança
• são APIs pretendidas usadas
• o código aplicou a arquitetura especificada
• ele escreveu testes úteis (mas somente se ele foi instruído implicitamente, eu tive que aprender)
• Documentação
• processo de construção
• ... e um pouco mais, provavelmente

Se você é um desenvolvedor experiente, com certeza encontrará sempre coisas como loops que você pode fazer com melhor desempenho. É claro que é útil explicar esse conhecimento a outras pessoas, mas isso não deve fazer parte da sessão de revisão. Se houver problemas significativos de desempenho, não porque ele (ou ela) usou uma variante menos eficiente de um tipo de lista.

Como a pergunta inicial era por que algumas pessoas parecem fazer uma revisão melhor do que outras, eu responderia que essas pessoas talvez façam uma prévia antes do início da revisão real, significa que provavelmente estão se preparando para que saibam exatamente o que querem revisar .

[Como] posso fazer um trabalho melhor executando uma revisão de código para outra pessoa?

Faça-lhes muitas perguntas

Eu sei que, para executar uma revisão de código, você precisa ter conhecimento de como o código existente funciona ...

Na verdade, não, você não precisa conhecer o código de antemão para ser um bom revisor.

Alguns empregos atrás, meu empregador começou a exigir que todos os check-ins de código fossem assinados por um revisor. Eu estava trabalhando principalmente com GUI em C, e um dos melhores revisores para mim foi meu amigo Bill. Ele era proficiente em C, mas nunca havia feito muito trabalho na GUI e, ao entrar nas revisões, não fazia ideia de como meu código deveria funcionar.

Mas ele fez muitas perguntas sobre isso e teve que explicar para entender o que meu código fazia e por que estimulou muito o meu pensamento. Isso me levou a encontrar muitos bugs estranhos com casos extremos, e também a considerar outras abordagens que eu poderia ter adotado. Além disso, embora eu estivesse escrevendo C há 22 anos naquele momento e pensasse que era bastante proficiente, rapidamente melhorou a qualidade do meu código.

Mesmo que eu não trabalhe mais lá, ainda reviso as diferenças antes do check-in e me pergunto: "Que perguntas Bill teria sobre isso?" E, muitas vezes, acabo mudando alguma coisa como resultado.