Engenharia de Software: O tal Code Review
Tags: codereview, agile, bestpractice, engineering
Published: 2021-09-14 23:16:17

## 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_](https://dev.to/marylly/clean-code-introducao-bfb):** É 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