This content originally appeared on DEV Community and was authored by Marylly
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:
- Pessoa(s) quem desenvolveu o código
- 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
- Apoia o engajamento do time com a saúde do código;
- Apoia no aprendizado de linguagens, frameworks, paradigmas, etc;
- Acelera o engajamento de novas pessoas desenvolvedoras sobre o que é esperado do código;
- A medida que as boas práticas e melhorias são aplicadas, novas formas são discutidas e absorvidas, aumentando a qualidad;
- Fortalece a confiança da pessoa desenvolvedora e do time em deploys de alta qualidade;
- Promove discussões sobre: (1) Tecnologias usadas e novas (2) Discussões sobre arquitetura de código (3) Discussões sobre boas práticas;
- Promove o compartilhamento de conhecimento e a cooperação;
- Apoia na identificação de refatorações e débitos técnicos que podem ser trabalhados posteriormente.
Contrapontos
- Pode gerar estresse e ansiedade para as pessoas autoras do código, principalmente para pessoas novas no time/projeto.
- Pode se tornar um gargalo no ciclo de desenvolvimento de software.
RECOMENDAÇÕES
Autora do Código
- 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;
- 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;
- 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;
- 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;
- 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;
- Se for fazer revisão pessoalmente, agende com a pessoa e reserve um tempo para focar adequadamente no processo;
- 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;
- 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;
- 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
- Evite criticar a pessoa ou código;
- Seja propositiva nos comentários, e compartilhe suas razões;
- Foque nas diretrizes do projeto;
- Evite compartilhar opiniões pessoais, faça de forma privada, somente você e a pessoa autora;
- Não compartilhe feedbacks negativos ou construtivos, faça de forma privada, somente você e a pessoa autora;
- Se existir dúvida se vai ofender ou gerar conflitos, faça de forma privada ou busque apoio para transmitir a mensagem adequadamente;
- 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;
- 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;
- Busque o consenso em detrimento da imposição;
- Abordagens interessantes de solução foram apresentadas, reconheça, aprecie a pessoa autora do código, reforce as coisas boas e que trazem valor;
- 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
This content originally appeared on DEV Community and was authored by Marylly
Marylly | Sciencx (2021-09-14T23:16:17+00:00) Engenharia de Software: O tal Code Review. Retrieved from https://www.scien.cx/2021/09/14/engenharia-de-software-o-tal-code-review/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.