Engenharia de Software: O tal Code Review

O que ?

Code Review ou Reviso de cdigo uma prtica onde o cdigo desenvolvido para atender determinada demanda passa pela reviso de outras pessoas desenvolvedoras antes de ser integrada a uma verso principal de um software.

Idealmente no deve ser um processo mandatrio, e sim um pacto do time, e o valor deve ser muito bem entendido para que existam benefcios.

Code Review x Prticas Agis

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 prticas no so atendidas, logo uma m prtica.

Contexto e Cenrios + comuns

Considerando muitos times de desenvolvimento de software, muitos no detm 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 prximo passo aps superadas essas deficincias e o processo de code review eliminado.

Como aplicar?

Apesar de alguns contrapontos, o processo de code review pode ser bem benfico, e pode apoiar a maturidade e evoluo tcnica do time em muito aspectos.

Nessa prtica, temos dois papis:

1. Pessoa(s) quem desenvolveu o cdigo
2. Pessoa(s) quem pode trazer pontos de melhoria, identificar contrapontos e sugerir formas distintas para resolver no somente o problema de implementao, como problemas relacionados a demanda do cdigo.

Pode ser feito de duas maneiras: (1) Pessoalmente com as pessoas que a autora do cdigo confia e se sente segura, ou sua liderana 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. Cdigo limpo ou Clean Code: possvel as pessoas lerem o cdigo e entender o seu propsito (comportamento/resultado)?

2. Diretrizes do Projeto: Perfomtico, escalvel, enxuto, padres de projetos, padres de arquitetura, style guide, etc.

3. Funcionalidade: O comportamento do cdigo atende as expectativas da pessoa desenvolvedora e as pessoas que iro usar: clientes, etc? Efeitos colaterais no comportamento e/ou funcionalidades j existentes no software?

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

5. Testes: O cdigo est sendo testado? Existem cenrios que cubram os cenrios feliz e infeliz do processo principal desenvolvido no cdigo? Se um comportamento indesejado ou inesperado surgir, os testes sinalizaram?

6. Nomes: Os nomes utilizados no cdigo trazem uma conexo com os processos e problemas de negcio que o cdigo est sendo desenvolvido para resolver? Os nomes empregados nas variveis, classes, mtodos, funes apoiam o entendimento do comportamento ou da sada de cdigo em reviso?

7. Comentrios: Os que foram utilizados esto fcil de compreender, curtos e realmente teis onde aplicados?

8. Efeitos colaterais: Impacta na comunicao e/ou comportamento de aplicaes internas/externas e de parceiros? Quebra de contratos de comunicao?

9. Documentao: A documentao de apoio precisa ser atualizada? Contm o que precisa para executar alguma atividade ou tarefa relacionada ao cdigo?

Benefcios

1. Apoia o engajamento do time com a sade do cdigo;
2. Apoia no aprendizado de linguagens, frameworks, paradigmas, etc;
3. Acelera o engajamento de novas pessoas desenvolvedoras sobre o que esperado do cdigo;
4. A medida que as boas prticas e melhorias so aplicadas, novas formas so discutidas e absorvidas, aumentando a qualidad;
5. Fortalece a confiana da pessoa desenvolvedora e do time em deploys de alta qualidade;
6. Promove discusses sobre: (1) Tecnologias usadas e novas (2) Discusses sobre arquitetura de cdigo (3) Discusses sobre boas prticas;
7. Promove o compartilhamento de conhecimento e a cooperao;
8. Apoia na identificao de refatoraes e dbitos tcnicos que podem ser trabalhados posteriormente.

Contrapontos

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

RECOMENDAES

Autora do Cdigo

1. Na apresentao ou descrio da reviso, comunique o objetivo da implementao, e se for necessrio, as idias por traz da soluo desenvolvida;
2. Se o processo for por PRs, faa-os de forma incremental com pouco contedo e sinalize o trabalho ainda em andamento (vulgo WIP ou Work in Progress), para no desestimular as pessoas revisoras pelo volume ou pela falta de tempo para revisar adequadamente;
3. Evite enviar para reviso pedaos de cdigo no-funcionais ou que no agregam ao processo. Atrapalha a reviso e aumenta o tempo utilizado para entender o que o cdigo faz;
4. Evite cdigos de coisas que ainda vo ser desenvolvidas no futuro (as vezes coisas no confirmadas). Ex. Classes vazias, mtodos/fune vazios, as vezes s a sua assinatura, TO-DOS, etc;
5. No espere pelo tempo das pessoas revisoras, sinalize as envolvidas, afinal todas temos prazos para serem atendidos, e a entrega do time, pelo algum do time deve se organizar para fazer a reviso;
6. Se for fazer reviso pessoalmente, agende com a pessoa e reserve um tempo para focar adequadamente no processo;
7. Se no houver consenso ou ocorrer conflitos, busque a liderana ou outras pessoas para chegar na melhor soluo possvel para o contexto e momento;
8. Em revises privadas, compartilhe os resultados num comentrio do PR ou num canal comum com o time para que todas entendam e aprendam com a informao;
9. Evite cdigo/artefatos desnecessrios: Cdigo comentado que no est e/ou nem ser utilizado, arquivos que no precisam ser versionados ou que so temporrios.

Revisora do cdigo

1. Evite criticar a pessoa ou cdigo;
2. Seja propositiva nos comentrios, e compartilhe suas razes;
3. Foque nas diretrizes do projeto;
4. Evite compartilhar opinies pessoais, faa de forma privada, somente voc e a pessoa autora;
5. No compartilhe feedbacks negativos ou construtivos, faa de forma privada, somente voc e a pessoa autora;
6. Se existir dvida se vai ofender ou gerar conflitos, faa de forma privada ou busque apoio para transmitir a mensagem adequadamente;
7. Nem sempre as preferncias da pessoa revisora uma regra que deve ser adotada pela pessoa autora do cdigo, e isso deve ficar bem entendido pelas pessoas envolvidas;
8. Sinalize quando um comentrio apenas uma sugesto, no necessariamente algo mandatrio, e a pessoa autora pode tomar a deciso de fazer ou no;
9. Busque o consenso em detrimento da imposio;
10. Abordagens interessantes de soluo foram apresentadas, reconhea, aprecie a pessoa autora do cdigo, reforce as coisas boas e que trazem valor;
11. Se no conhece muito bem a codebase, comece pelos testes para entender o comportamento desenvolvido e os elementos do cdigo utilizado para confrontar com a proposta inicial da demanda.

Princpios Recomendados

1. Novas demandas emergentes: Podem surgir necessidades de reavaliao da implementao, refatorao e at necessidade de criar novas funcionalidades. As pessoas da liderana e de negcio devem ser sinalizadas e a soluo replanejada ou refatorada de acordo com o prazo, pessoas e recursos disponveis, evitar absorver esse trabalho emergente num trabalho iniciado e identificado atravs de uma reviso de cdigo;
2. Ambiente seguro e inclusivo: NO um espao para represso das pessoas autoras por preconceitos por parte das pessoas revisoras, pelas caractersticas da pessoa autora do cdigo (raa, gnero, origem, religio, inclinao poltica, comportamento e/ou aparncia), todas as pessoas DEVEM ser respeitadas pelo o que REALMENTE so;
3. Espao de aprendizado: NO um espao para as pessoas autoras serem reprimidas por falta de alguns conhecimentos, e sim, para suprir deficincias tcnicas, aprender novas formas de trabalho, exporem suas idias, fortalecerem seus conhecimentos e obter feedback sobre a evoluo do trabalho antes de ir para ambiente produtivo;
4. Revises rpidas: O time deve ser encorajado a fazer as revises assim que possvel, o perodo mximo de um dia de trabalho para ser concludo.

Concluses

Apesar do Code Review no ser considerada uma boa prtica, pode ser um espao de muito crescimento e amadurecimento das pessoas envolvidas, e deve ser utilizado como um trampolim para a evoluo para o formato trunk based.

Se conhece outras formas para a prtica do processo, compartilhe comigo nos comentrios, seria muito legal continuar a conversa e evoluir sobre o tema. =]

ATENO: Esse contedo a consolidao das impresses e opinies da autora sobre o assunto, resultado de vivncias e processos empricos que trouxeram resultados para contextos especficos, no h garantia que aderente a qualquer contexto e/ou time de desenvolvimento de software.

Referncias

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