A prática do coding review é bastante comum em algumas empresas e pode se dar de diversas formas, geralmente como: todos revisam o código de todos, determinada equipe revisa o código de outra equipe, os membros do mesmo time revisam o código uns dos outros, o líder técnico revisa o código dos demais desenvolvedores, entre outras maneiras. Neste post, irei descrever as minhas respostas para as perguntas relacionadas ao tema “Revisão de Código” mencionado no post #0 da série.

Motivação

Além de ser uma prática comum, acredito que ler e revisar código de outros desenvolvedores nos ajuda a aprender mais e a evoluir como devs. Também considero que revisar o próprio código antes de fazer uma entrega seja muito válido e costumo fazer no dia a dia, assim como pedir para outros desenvolvedores revisarem.

A motivação para as perguntas é entender quais pontos a pessoa entrevistada observa, principalmente voltados à qualidade de software, e isso também pode mostrar o quanto ela conhece, estuda e pratica no dia a dia quando faz o design do próprio código.

Revisão de Código

• Você já revisou o código de alguém? Em que você presta atenção quando está revisando?

Resposta: Sim, estou acostumado a revisar código de outros devs e ter o meu revisado também.
Quando estou revisando, procuro entender a linha de raciocínio da outra pessoa. Se o código pertencer a uma empresa, costumo olhar para os padrões e convenções que geralmente já foram estipulados e combinados com o time; verifico possíveis problemas de performance em algoritmos, vejo o uso de estruturas de dados adequadas para cada cenário e, se eu conhecer as regras de negócio, também faço uma validação mental para verificar se não tem nenhum bug e confiro os cenários de testes criados. Mais especificamente em aplicações Java, verifico a coesão, principalmente relacionada a atribuição de responsabilidade, e nomenclatura de classes, objetos, atributos, variáveis, constantes e métodos, além de considerar o bom uso prático dos conceitos de orientação a objetos.

• Na sua opinião, o que é código limpo?

Resposta: Na minha visão, código limpo é aquele que qualquer desenvolvedor, em qualquer nível, pode ler e entender o que está sendo feito. Mesmo que quem esteja lendo não entenda como está sendo feito e por que foi feito daquela maneira, o que considero que pode ser uma simples questão de nivelamento técnico, o que está sendo feito deve ser compreendido por qualquer desenvolvedor. A partir disso, considero importante o uso de princípios e padrões do paradigma intencional da linguagem utilizada, boa nomenclatura, coesão, flexibilidade, responsabilidade única e demais fatores que simplificam a leitura de um código.

• Qual estratégia você utiliza para refatorar o seu código? E o código que um desenvolvedor desconhecido fez?

Resposta: Quando estou refatorando um código que fiz muito recentemente, procuro fazer as melhorias técnicas que conheço e depois ajustar os testes porque provavelmente ainda terei as regras de negócio na cabeça e consigo confiar no código que entreguei há pouco tempo.
Se for um código meu mais antigo, prefiro começar pelos testes antes de fazer o refactoring porque considero mais seguro e, começar a partir dos cenários de teste, me ajuda a garantir o bom funcionamento do código sem ter a necessidade de realizar muitos testes manuais.
Em relação ao código de outros desenvolvedores, primeiro costumo verificar se existem testes e, em caso positivo, dependendo da complexidade do que precisa ser refatorado, faço o refactoring, rodo os testes existentes e faço os ajustes se necessário. Caso não existam testes criados, verifico a possibilidade e estimo o tempo para criar os testes antes de iniciar o refactoring e, se o investimento não valer apena ou for aprovado, considero não refatorar e criar uma tarefa como débito técnico para que código seja refeito ou refatorado em um momento futuro, geralmente em conjunto com outra tarefa do mesmo contexto técnico.

Este é um tema interessante e suas perguntas e respostas podem variar muito com base no conhecimento teórico e prático de cada pessoa. Para desenvolvedores java, considero muito relevante revisar códigos, tanto o próprio quanto o de outros devs. Acho importante seguir ou definir padrões e convenções, dar nomes explicativos para tudo, criar e manter testes, seguir princípios da orientação a objetos, usar padrões de projeto e tudo o que aprendemos para deixar o código mais limpo.

Para saber mais

• Código Limpo: Habilidades Práticas do Agile Software
• Arquitetura Limpa: o Guia do Artesão Para Estrutura e Design de Software

Gostou? Foi útil? Concorda ou discorda de algum ponto? Comenta ai e vamos aprender mais juntos.

Espero que te ajude 😉