Revisões de Código Eficazes

As revisões de código são uma parte essencial de qualquer equipe de desenvolvimento de software, pois ajudam a reduzir as chances de ter códigos com erros.

Eu mesmo faço revisões de código há mais de 6 anos e, nesse período, revisei mais de 600 solicitações pull. Agora estou escrevendo este post para compartilhar meus aprendizados, com a esperança de que ajude tanto o Avaliador quanto o Avaliado.

Antes de entrarmos na toca do coelho sobre o que e o que não fazer durante as revisões de código, quero destacar a importância das revisões de código.

As pessoas geralmente pensam em revisões de código como uma tarefa servil que apenas aumenta o tempo entre “Dev Done” e “Ready for QA”. A afirmação acima é “verdadeira” quando as revisões do Código estão sendo feitas “ Não com as intenções corretas ”.

Aqui estão alguns cenários que se agregam à revisão de código sendo feita, mas não ajudando ninguém —

1. O Revisor está fazendo a revisão do código apenas por fazer. Ele está aprovando pedidos sem olhar ou apenas rolar por eles uma vez.
   Esses tipos de revisores logo são rotulados como revisores fáceis e, em seguida, são direcionados para obter o código mais rapidamente.
2. O revisor está fazendo a revisão do código sem entender os requisitos da tarefa
3. O revisor está adicionando comentários sem o motivo real por que a alteração é necessária
4. O Revisor está verificando apenas a sintaxe e não a lógica real.
   Se um revisor pensa que o avaliado sabe mais do que ele, isso está prestes a acontecer.
5. O Avaliado não está tentando entender o raciocínio por trás de um comentário. Então, ou ele está apenas seguindo os comentários cegamente ou ignorando

Por que devo revisar o código de outra pessoa?
Alguém pode pensar que não há vantagens em revisar o código de outra pessoa, pois eles podem acreditar que não estão aprendendo nada novo. Pelo contrário-

1. Os revisores entendem as tarefas que estão acontecendo dentro da equipe.
2. Eles conhecem os serviços que existem dentro do sistema. O que melhora a reutilização
3. Eles aprendem novas sintaxes ou formas de codificar e fazer coisas

No entanto, eu ainda estaria listando algumas coisas que as pessoas geralmente perdem ao fazer revisões de código.

Diretrizes Gerais

1. Atenção especial deve ser dada à “legibilidade do código” e à “reutilização do código”.
   Os nomes de variáveis ​​e funções são descritivos e significativos. Nomes como i, anão devem ser usados.
2. O código não deve ser redundante (ferramentas de qualidade de código como “sonarlint” são muito úteis nesses casos)
3. Os casos de teste de unidade são obrigatórios para as funções utilitárias
4. O trabalho de cada função deve ser claramente definido e deve seguir o princípio da responsabilidade única
5. Verifique os níveis de registro. O conteúdo do log deve ter informações acionáveis
   ​​Algo como — “obteve erro do cache” não possui nenhuma informação acionável
6. Devemos ter métricas em vigor sempre que necessário
7. Verifique se o processo (logging, chamadas externas, banco de dados, cache) precisa ser sincronizado ou assíncrono
8. As pessoas geralmente não prestam muita atenção aos casos de teste de unidade. Deve-se pensar se todos os cenários são cobertos ou não
9. Para um recurso crucial que pode impactar a jornada do usuário, deve-se sempre ter um fallback para voltar ao fluxo anterior
10. O avaliado deve tentar dividir as alterações em vários componentes menores e criar solicitações pull para eles de forma independente e o mais cedo possível. Isso não apenas dá ao revisor mais tempo, mas também garante que os problemas (se houver) ou cenários de borda sejam detectados antecipadamente
11. Não acredite em ninguém. Questionar tudo. Às vezes, se confiarmos no autor, não nos aprofundaremos em seu código.
12. O avaliado deve revisar seu pull request pelo menos uma vez antes de compartilhá-lo para revisão. Isso garante que coisas básicas como - código comentado, TODOs pendentes, alterações em espaços em branco etc. sejam corrigidas antes mesmo de compartilhar o PR
13. Verifique os ramos de origem e destino, se estão corretos ou não.

1. Se a chamada externa é altamente acoplada ou não (altamente acoplada significa — um erro na chamada externa causará um erro neste fluxo)
2. Mecanismos de tempo limite e repetição
3. Requisitos de amostragem e limitação de taxa
4. Métricas para chamadas externas (latência, taxa de sucesso)

1. Verifique o TTL padrão e a lógica de atualização do cache
2. Também devemos estimar o número de novas entradas e a taxa de acertos do cache ao adicionar um cache
3. O que acontece em caso de erro do cache
4. No caso de um novo cluster de cache — se existe conectividade do servidor para a instância de cache
5. Métricas para a taxa de acerto do cache
6. Uma estimativa do número de chaves de cache, o tamanho médio do valor e a certeza de que o Infra tem capacidade suficiente.

1. Verifique se um índice correto está presente no banco de dados para a nova consulta
2. No caso de um novo banco de dados - se a conectividade existe ou não
3. Política de limpeza de tabelas, para evitar tabelas grandes ao longo do tempo, em caso de inserções de dados
4. Métricas para as novas consultas

1. Remova as alterações de espaço em branco da solicitação pull
   Como? Você pode se referir a isso
2. Se não estou ciente do requisito, geralmente verifico a tarefa ou sincronizo com o desenvolvedor uma vez para entender o requisito
3. Abra o Pull Request no GitHub/BitBucket e no Editor de código local simultaneamente.
   Ter o código localmente tem várias vantagens —
   - Você pode usar ferramentas de varredura de código estático para encontrar alguns dos problemas comuns
   - A navegação no código é muito mais fácil
   - Se necessário, você pode executar o código para ver como ele se comporta
4. Comece do ponto em que o fluxo de negócios é afetado e, em seguida, passe pelo código a partir daí. Sempre que eu mover para um arquivo diferente, verifique se esse arquivo foi alterado ou não na solicitação Pull no Github.
5. Em caso de qualquer problema, adicione esse comentário no GitHub enquanto menciona o que precisa ser alterado e por quê? Junto com algum material de referência
6. Caso você tenha terminado de revisar um arquivo - marque-o como visualizado, para que você também tenha clareza sobre o andamento da revisão e também possa evitar o arquivo durante a segunda revisão de código (se não houver alterações )
7. Se as mudanças no diff forem pequenas, eu reviso de uma só vez. Caso contrário, divido a revisão em pequenas fases. Isso garante que a qualidade da revisão não seja afetada. Geralmente o que acontece é que, se a diferença for grande, depois de um ponto, começamos a aceitar as mudanças sem pensar muito nelas

Espero que haja pelo menos uma coisa que você aprendeu com isso. Se sim, vote positivo e também mencione pontos que eu possa ter perdido. Vou adicioná-los ao post também.

Felicidades e revisão feliz!