A revisão de código ou também chamado (code-review) é um processo que hoje em dia faz parte da construção de um software, no qual há mais de uma pessoa desenvolvendo. O princpipal objetivo é que membros da equipe analisam e examinam o código fonte desenvolvido visando identificar erros, melhorar a qualidade do código, aumentar o engajamento entre o time.
Através desse processo, é possível evitar a introdução de bugs no código-base, garantindo uma base sólida e confiável para o software.
Buscando identificar erros lógicos, de sintaxe ou de estilo, a revisão de código permite a detecção de possíveis problemas de desempenho, segurança ou escalabilidade. Além disso existe uma grande oportunidade para os desenvolvedores compartilharem conhecimentos, como também discutirem práticas e padrões.
A revisão de código é uma prática fundamental no desenvolvimento de software, embora possa ser demorada e trabalhosa. Se não for realizada de forma eficiente e direcionada, pode impactar negativamente o desempenho da equipe durante o processo de revisão. Felizmente, existem muitos recursos disponíveis atualmente que compartilham dicas e práticas para aprimorar a revisão de código.
Nesta publicação, compartilharei alguns insights que adquiri ao longo da minha experiência, com o objetivo de ajudar a melhorar a eficácia do seu processo de revisão de código. Abordarei pontos importantes que podem otimizar o tempo gasto na revisão e maximizar os benefícios obtidos a partir desse processo.
Review lógico e Mecânico
Antes de introduzir sobre alguns pontos sobre "Review lógico e Mecânico", gostaria de detalhar o que refere quando apresento estas duas palavras:
- Mecânico: Seria a parte do review onde seu você faz atividades mecânicas repetitivas, ou seja, realiza uma determinada revisão quase que no automático, repetidamente. Exemplo, titulo, descrição, processo manual de teste validando funcionamento, sintaxe do código e convenções do projeto
- Lógico: Esta é a parte da revisão em que não há um processo pré-determinado ou uma sequência repetitiva. O lógico exige um pensamento analítico para avaliar se o que está sendo revisado está em conformidade com os seus critérios de aceitação. É nessa fase que se verifica se o código é coeso, escalavel, você entende o que a alteração impacta na aplicação, valida possiveis melhorias e pauta discussões.
Observação: Claro que nem sempre num processo de review as duas partes estarão tão presente, mas é importante eu levantar para você entender um pouco sobre "prioridade de foco"
Prioridade de foco
Uma vez vi a senguinte desenho em um artigo que me marcou muito
Esta imagem define exatamente o que quero dizer como prioridade de foco, pois a a prioridade de foco ela contribui para que ao fazer revisão você não se atrapalhe gerando sugestões que não fazem sentido. Exemplo, porque faria sentido eu debater a escalabilidade de uma função que talvez não faça sentido ir para produção.
Nesse sentido, é fundamental verificar se a demanda atende às funcionalidades esperadas e, em seguida, avaliar se ela compromete a segurança do projeto. Ao abordar esses dois pontos iniciais, é possível ter uma compreensão inicial do código revisado.
Uma vez que esses aspectos essenciais tenham sido analisados, é possível avançar para uma análise mais abrangente do código, considerando elementos de longo prazo. Isso inclui a avaliação da escalabilidade, resiliência, manutenibilidade, legibilidade, semântica, sintaxe e outros pontos técnicos relevantes que terão um impacto no futuro do projeto.
Altamente recomendado criar um "checklist mental" durante o processo de revisão de código. Essa abordagem ajuda a validar progressivamente os pontos essenciais e garante uma revisão mais completa e eficiente.
Ao desenvolver o seu "checklist mental", você pode incluir uma lista de verificação dos aspectos importantes a serem avaliados, como funcionalidades, segurança, desempenho, legibilidade, conformidade com padrões de codificação e boas práticas, entre outros.
Aqui um exemplo de um "Checklist mental" para revisão de um pr
Exemplo
Checklist logico
- [ ] Eu consigo entender sobre o que o pr se trata.
- [ ] Nome do pr não esta coerente com o que ele faz
- [ ] Existem melhorias ou refatoração que podem ser feitas ou reportadas
- [ ] Existe alguma falha de segurança, invalidade em alguns casos ou brecha no sistema
Checklist mecânico
- [ ] PR esta com bug na execução
- [ ] PR com conflito
- [ ] PR muito tempo desatualizado
- [ ] Tem console ou debugger
- [ ] Falta adicionar tipo, model ou generic type
- [ ] Existe uma função sem type
- [ ] Código contem erros de português ou inglês
- [ ] Os nomes da função e/ou variáveis estão condizentes com o que ela faz
- [ ] Titulo do pr contem Erros de português ou inglês
Hooks que você pode utilizar
Por fim, gostaria também de compartilhar algumas ajudas que você pode ta utilizando para conseguir um melhor desempenho em cada item do checklist.
- Utilizar o GH terminal para navegar entre os pull-request ou extensão GitHub Pull Requests.
- Dedicar um tempo na sua agenda para fazer essa ação.
- Ir marcando o que já foi revisado, não deixar para ultima hora. (Caso seja feito uma alteração muito brusca, revalide, caso contrario siga com itens que não foi revisado)
- Faça alinhamentos com o Dono do pull-request.
- Lembre-se de atualizar a discussão que tiveram no pull-request para dar vibisibilidade caso tenham tomado uma decisão.
- Evite a procura de casos de teste, sempre faça um alinhamento com quem desenvolveu ou com produto / lider, eles devem ter casos de teste para você validar.
Top comments (0)