Code review

Code review é o processo de examinar e avaliar o código-fonte escrito por outro desenvolvedor. É uma prática comum em equipes de desenvolvimento de software, na qual os membros da equipe revisam o código uns dos outros para identificar problemas, fornecer sugestões e garantir a qualidade do código antes de ser implantado.

Durante o code review o código é avaliado em busca de possíveis erros, problemas de estilo, más práticas de programação, falta de otimização e conformidade com os padrões e diretrizes estabelecidos pela equipe, vulnerabilidades de segurança, oportunidades de refatoração, melhorias de desempenho, entre outros.

Vejamos alguns pontos importantes de compreensão para que se tenha uma análise de código de qualidade e bem aproveitada.

Não existe código “perfeito”, existe apenas um código melhor

Muitas coisas podem ser analisadas, e por isso podemos nos perder nestas análises e, por isso, é importante entendermos até quando vale a pena barrar um código. Trouxe um trecho sobre code review que retirei do repositório de boas práticas de engenharia do google extremamente preciso. Vejamos:

“Em geral, os revisores devem favorecer a aprovação de um código quando ele estiver em um estado em que definitivamente melhore a integridade geral do código do sistema que está sendo trabalhado, mesmo que o código não seja perfeito.”

Ou seja, não existe código “perfeito”, existe apenas um código melhor. Em vez de buscar a perfeição, deve-se buscar a melhoria contínua. Não é necessário barrar um pull request até que todos os cenários tenham todos os fluxos perfeitos. Se o código está melhorando a aplicação, e claro, não irá trazer problemas maiores ao ser mesclado, podemos seguir com a implementação.

A melhoria contínua e a troca de conhecimento são o que importam

O fato de não precisarmos buscar um código perfeito não quer dizer que os revisores devem deixar de fazer suas pontuações só para liberar instantaneamente a mesclagem de um novo código. Muito pelo contrário, o revisor deve se sentir sempre à vontade para pontuar melhorias e deixar suas opiniões. Fazendo comentários claros e construtivos. Apontando o local específico do problema, explicando suas preocupações e motivos, se possível fornecendo exemplos e sugestões de como resolver o problema. Inclusive, se há alguma adição de código que não seja coerente com a aplicação, mesmo que seja bem implementada, o revisor poderá negar a aprovação, desde que haja uma explicação plausível, é claro.

Já os autores não devem levar estas sugestões para o pessoal. O code review é um momento de troca de conhecimento que auxilia a manter a qualidade do código e estabelecer a melhoria contínua do código, projeto e produto. Possuindo também a importante função de mentoria, na qual os envolvidos aprendem muito com a troca de conhecimento, evoluindo profissionalmente e aumentando os conhecimentos técnicos

Todos os envolvidos devem compreender que é normal acontecerem falhas, esquecermos de alguns detalhes e que existem soluções melhores ou apenas diferentes para um mesmo problema. Não se prenda à opinião pessoal, o foco deve ser a melhoria contínua e troca de conhecimento.

Defina diretrizes e padrões de codificação

Defina diretrizes e padrões de codificação claros e compartilhe-os com a equipe. Será de grande auxílio para uma revisão, pois será baseada em critérios já estabelecidos e consistentes.

Os padrões podem ser desde indentação até padrões arquiteturais, padrões de nomenclatura à organização. Ferramentas de análise estática e linters devem anteceder ao code review, fazendo a detecção de problemas comuns, erros de formatação, variáveis não utilizadas, entre outros. Tendo uma prévia avaliação automática, já aumentamos a confiabilidade do código.

Mantenha as revisões pequenas

Evite revisões grandes e complexas que podem dificultar a identificação de problemas. Ou seja, evite pull requests muito grandes, com muitas alterações e em muitos arquivos. Revisões menores são mais fáceis de serem analisadas, muito código pode tornar a revisão cansativa e erros e problemas podem passar despercebidos. Também se torna mais fácil de se gerenciar as correções das melhorias sugeridas.

Encoraje a participação da equipe

Incentive todos os membros da equipe a participarem das revisões de código, independentemente do nível de experiência. Mesmo que um pull request já tenha as aprovações necessárias, os demais integrantes do time podem continuar com as revisões, podendo encontrar novos pontos ou somente utilizando a revisão como uma oportunidade de aprendizado, analisando comentários sobre problemas para nãopara que não repeti-los no futuro.
Para iniciantes ou novatos na equipe, visitar pull requests já mesclados pode ser uma grande ajuda para entender os padrões do projeto e obter novos aprendizados.

A inclusão de toda a equipe ajuda a disseminar o conhecimento, melhora a qualidade do código e promove a colaboração. Discussões construtivas entre os envolvidos devem ser encorajadas, desta forma, se instaura uma cultura na qual o time se sentirá confortável para esclarecer dúvidas, para explorar os problemas e debater sobre as alternativas de soluções.

Os pull requests devem ser informativos e rastreáveis

Um bom pull request tornará a análise de código muito mais eficiente, pois trará contexto e informações adicionais para que as análises sejam feitas de forma muito mais completa e até mesmo, com maior facilidade. Por isso, descreva bem o que foi alterado e/ou adicionado e o motivo das alterações.

Para alterações visuais, uma imagem, um gif ou um vídeo podem ser muito esclarecedor. Uma comparação de antes e depois tornará ainda mais claro o que foi alterado e a necessidade de alteração. Vincule o card da tarefa que está sendo desenvolvida do seu board à descrição do PR. Assim, os revisores poderão acessar mais detalhes do que foi requisitado.

Adicione um título claro e descritivo, se atribua como autor e uma boa prática é adicionar labels para identificar do que o PR se trata (feature, bug, versionamento, etc)

Uma boa opção pode ser criar um checklist do que o código e o pull request deve conter para seguir para a fase de análise, por exemplo:

• [ ] Testes para as alterações realizadas foram adicionados
• [ ] A estilização foi projetada considerando o design mobile-first
• [ ] Descrição clara e completa foi adicionada ao PR
• [ ] Estas alterações não geraram novos warnings no terminal ou console
• [ ] Tags adicionadas ao PR

Neste artigo temos alguns exemplos de templates para pull requests para você se basear. Você pode e deve adaptá-los à sua realidade.

Pull requests são um ótimo formato de documentação. No futuro, membros da equipe ou até você mesmo, poderão retornar a um pull request para revisitar alguma informação, uma implementação e até mesmo para investigar possíveis problemas e melhorias.

Conclusão

Diante das informações discutidas anteriormente, podemos compreender que a importância do Code Review transcende a simples revisão de código, é uma prática que contribui para a excelência técnica, a eficiência do desenvolvimento e a evolução dos profissionais envolvidos. É um processo que deve ser abraçado e valorizado em qualquer equipe de desenvolvimento comprometida com a qualidade do produto final.
A dica é: Não subestime o code review.