Engenharia de Software: O tal Code Review

O que é?

Code Review ou Revisão de código é uma prática onde o código desenvolvido para atender determinada demanda passa pela revisão de outras pessoas desenvolvedoras antes de ser integrada a uma versão principal de um software.

Idealmente não deve ser um processo mandatório, e sim um pacto do time, e o valor deve ser muito bem entendido para que existam benefícios.

Code Review x Práticas Agéis

Do ponto de vista do desenvolvimento ágil de software, o code review é um processo que impacta a velocidade do time e da entrega, e pode virar um gargalo se algumas boas práticas não são atendidas, logo uma má prática.

Contexto e Cenários + comuns

Considerando muitos times de desenvolvimento de software, muitos não detém do todo o conhecimento elementar que permitam um modelo de trabalho mais ágil utilizando trunk based sem um processo de code review estruturado e maduro. O trunk based deve ser o próximo passo após superadas essas deficiências e o processo de code review eliminado.

Como aplicar?

Apesar de alguns contrapontos, o processo de code review pode ser bem benéfico, e pode apoiar a maturidade e evolução técnica do time em muito aspectos.

Nessa prática, temos dois papéis:

1. Pessoa(s) quem desenvolveu o código
2. Pessoa(s) quem pode trazer pontos de melhoria, identificar contrapontos e sugerir formas distintas para resolver não somente o problema de implementação, como problemas relacionados a demanda do código.

Pode ser feito de duas maneiras: (1) Pessoalmente com as pessoas que a autora do código confia e se sente segura, ou sua liderança imediata. (2) Utilizando o recurso de Pull Request oferecida por ferramentas de host de versionamento (GitHub, GitLab, BitBucket, etc)

A expectativa do processo é responder algumas das perguntas relacionadas abaixo:

1. Código limpo ou Clean Code: É possível as pessoas lerem o código e entender o seu propósito (comportamento/resultado)?

2. Diretrizes do Projeto: Perfomático, escalável, enxuto, padrões de projetos, padrões de arquitetura, style guide, etc.

3. Funcionalidade: O comportamento do código atende as expectativas da pessoa desenvolvedora e as pessoas que irão usar: clientes, etc? Efeitos colaterais no comportamento e/ou funcionalidades já existentes no software?

4. Complexidade: As mesmas tarefas e resultados do código podem ser executadas com um código mais simples e enxuto?

5. Testes: O código está sendo testado? Existem cenários que cubram os cenários feliz e infeliz do processo principal desenvolvido no código? Se um comportamento indesejado ou inesperado surgir, os testes sinalizaram?

6. Nomes: Os nomes utilizados no código trazem uma conexão com os processos e problemas de negócio que o código está sendo desenvolvido para resolver? Os nomes empregados nas variáveis, classes, métodos, funções apoiam o entendimento do comportamento ou da saída de código em revisão?

7. Comentários: Os que foram utilizados estão fácil de compreender, curtos e realmente úteis onde aplicados?

8. Efeitos colaterais: Impacta na comunicação e/ou comportamento de aplicações internas/externas e de parceiros? Quebra de contratos de comunicação?

9. Documentação: A documentação de apoio precisa ser atualizada? Contém o que precisa para executar alguma atividade ou tarefa relacionada ao código?

Benefícios

1. Apoia o engajamento do time com a saúde do código;
2. Apoia no aprendizado de linguagens, frameworks, paradigmas, etc;
3. Acelera o engajamento de novas pessoas desenvolvedoras sobre o que é esperado do código;
4. A medida que as boas práticas e melhorias são aplicadas, novas formas são discutidas e absorvidas, aumentando a qualidad;
5. Fortalece a confiança da pessoa desenvolvedora e do time em deploys de alta qualidade;
6. Promove discussões sobre: (1) Tecnologias usadas e novas (2) Discussões sobre arquitetura de código (3) Discussões sobre boas práticas;
7. Promove o compartilhamento de conhecimento e a cooperação;
8. Apoia na identificação de refatorações e débitos técnicos que podem ser trabalhados posteriormente.

Contrapontos

1. Pode gerar estresse e ansiedade para as pessoas autoras do código, principalmente para pessoas novas no time/projeto.
2. Pode se tornar um gargalo no ciclo de desenvolvimento de software.

RECOMENDAÇÕES

Autora do Código

1. Na apresentação ou descrição da revisão, comunique o objetivo da implementação, e se for necessário, as idéias por traz da solução desenvolvida;
2. Se o processo for por PRs, faça-os de forma incremental com pouco conteúdo e sinalize o trabalho ainda em andamento (vulgo WIP ou Work in Progress), para não desestimular as pessoas revisoras pelo volume ou pela falta de tempo para revisar adequadamente;
3. Evite enviar para revisão pedaços de código não-funcionais ou que não agregam ao processo. Atrapalha a revisão e aumenta o tempo utilizado para entender o que o código faz;
4. Evite códigos de coisas que ainda vão ser desenvolvidas no futuro (as vezes coisas não confirmadas). Ex. Classes vazias, métodos/funçõe vazios, as vezes só a sua assinatura, TO-DOS, etc;
5. Não espere pelo tempo das pessoas revisoras, sinalize as envolvidas, afinal todas temos prazos para serem atendidos, e a entrega é do time, pelo alguém do time deve se organizar para fazer a revisão;
6. Se for fazer revisão pessoalmente, agende com a pessoa e reserve um tempo para focar adequadamente no processo;
7. Se não houver consenso ou ocorrer conflitos, busque a liderança ou outras pessoas para chegar na melhor solução possível para o contexto e momento;
8. Em revisões privadas, compartilhe os resultados num comentário do PR ou num canal comum com o time para que todas entendam e aprendam com a informação;
9. Evite código/artefatos desnecessários: Código comentado que não está e/ou nem será utilizado, arquivos que não precisam ser versionados ou que são temporários.

Revisora do código

1. Evite criticar a pessoa ou código;
2. Seja propositiva nos comentários, e compartilhe suas razões;
3. Foque nas diretrizes do projeto;
4. Evite compartilhar opiniões pessoais, faça de forma privada, somente você e a pessoa autora;
5. Não compartilhe feedbacks negativos ou construtivos, faça de forma privada, somente você e a pessoa autora;
6. Se existir dúvida se vai ofender ou gerar conflitos, faça de forma privada ou busque apoio para transmitir a mensagem adequadamente;
7. Nem sempre as preferências da pessoa revisora é uma regra que deve ser adotada pela pessoa autora do código, e isso deve ficar bem entendido pelas pessoas envolvidas;
8. Sinalize quando um comentário é apenas uma sugestão, não necessariamente algo mandatório, e a pessoa autora pode tomar a decisão de fazer ou não;
9. Busque o consenso em detrimento da imposição;
10. Abordagens interessantes de solução foram apresentadas, reconheça, aprecie a pessoa autora do código, reforce as coisas boas e que trazem valor;
11. Se não conhece muito bem a codebase, comece pelos testes para entender o comportamento desenvolvido e os elementos do código utilizado para confrontar com a proposta inicial da demanda.

Princípios Recomendados

1. Novas demandas emergentes: Podem surgir necessidades de reavaliação da implementação, refatoração e até necessidade de criar novas funcionalidades. As pessoas da liderança e de negócio devem ser sinalizadas e a solução replanejada ou refatorada de acordo com o prazo, pessoas e recursos disponíveis, evitar absorver esse trabalho emergente num trabalho iniciado e identificado através de uma revisão de código;
2. Ambiente seguro e inclusivo: NÃO é um espaço para repressão das pessoas autoras por preconceitos por parte das pessoas revisoras, pelas características da pessoa autora do código (raça, gênero, origem, religião, inclinação política, comportamento e/ou aparência), todas as pessoas DEVEM ser respeitadas pelo o que REALMENTE são;
3. Espaço de aprendizado: NÃO é um espaço para as pessoas autoras serem reprimidas por falta de alguns conhecimentos, e sim, para suprir deficiências técnicas, aprender novas formas de trabalho, exporem suas idéias, fortalecerem seus conhecimentos e obter feedback sobre a evolução do trabalho antes de ir para ambiente produtivo;
4. Revisões rápidas: O time deve ser encorajado a fazer as revisões assim que possível, o período máximo de um dia de trabalho para ser concluído.

Conclusões

Apesar do Code Review não ser considerada uma boa prática, pode ser um espaço de muito crescimento e amadurecimento das pessoas envolvidas, e deve ser utilizado como um trampolim para a evolução para o formato trunk based.

Se conhece outras formas para a prática do processo, compartilhe comigo nos comentários, seria muito legal continuar a conversa e evoluir sobre o tema. =]

ATENÇÃO: Esse conteúdo é a consolidação das impressões e opiniões da autora sobre o assunto, resultado de vivências e processos empíricos que trouxeram resultados para contextos específicos, não há garantia que é aderente a qualquer contexto e/ou time de desenvolvimento de software.

Referências

Google Inc: The Standard of Code Review, Engineering Practices. Acessado em 10 de Setembro de 2021: https://google.github.io/eng-practices/review/reviewer/standard.html

Yu, Chak Shun; Better Programming Blog: 5 Actionable tips to deliver higher quality code reviews today.
Acessado em 14 de Setembro de 2021: https://betterprogramming.pub/5-actionable-tips-to-deliver-higher-quality-code-reviews-today-de422cd538df