Práticas de revisão do código

Data: 19/09/2203/21

Autores:

1. Ancelmo Luiz Evangelista dos Santos (DEV Team)
   
2. Matheus da Silva Cruz (DEV Team)

1. Objetivo

Elaborar um estudo sobre praticas de revisão de código.

2. Introdução

Quem nunca ouviu a frase “Toma que o filho é seu!”. No desenvolvimento de software o “filho” é de todos os integrantes do time. Quem quer um “filho” feio, desorganizado, todo “malacabado”?

O “filho”, que em nosso estudo é uma aplicação desenvolvida pelo time para a organização, tem que ser “ô filho!”, unindo todos os adjetivos possíveis a ele, que resumidos em aplicável, funcional, seguro e sem bugs.

3. Desenvolvimento

Desenvolver uma aplicação funcional e sem bugs, um software, é uma tarefa que envolve vários processos e diversos profissionais de um time ou vários times de desenvolvimento. Algumas das etapas envolvidas são:

• Levantamento de requisitos;
• Análise de Requisitos;
• Projeto;
• Implementação;
• Testes e
• Implantação.

Há uma outra etapa fundamental no processo de desenvolvimento que nem sempre é usada ou lembrada. A revisão de código. Conhecida pelos times como code review.

O que é code review?

É o processo em que os membros do time de desenvolvimento revisam o código desenvolvido, identificando possíveis problemas “bugs”, oferecendo feedbacks para melhorar a sua qualidade antes de integrá-lo à base. Enfim, ao término das tarefas da história, ao fazer o merge com a branch Dev, os integrantes do time revisam o que foi refatorado ou implementado para depois ser aprovado ou não.

“A revisão por pares – uma atividade na qual outras pessoas, além do autor de uma entrega de software, o examinam em busca de defeitos e oportunidades de melhoria – é uma das ferramentas mais poderosas de qualidade de software disponíveis. Os métodos de revisão por pares incluem inspeções, orientações, verificações de mesa por colegas e outras atividades semelhantes. Depois de experimentar os benefícios das revisões por pares por quase quinze anos, nunca trabalharia em uma equipe que não as realizasse.” Karl Wiegers.

A citação de Karl Wiegers, renomado escritor americano já nos mostra a importância do code review.

Acrescento mais um fator. Além de importante é urgente! Recentemente o caveira André Cortez nos explanou em nossa última entrega de Sprint.

“O que eu fiz está certo! Está funcionando!”, “Não gosto que fiquem falando o que devo e como devo fazer, eu faço da forma que funciona. Pronto!”, “O colega não para de comentar meus commits. Ele tá de marcação! ☹”.  Quem nunca né!

A verdade é: o time joga junto, e o dever de todos é cuidar do “filho” do time. Isso requer maturidade e aos poucos você e todos terão isso em mente e o processo de code review que consiste principalmente no feedback de ambas as partes para chegarem a um denominador comum: o que atende ao padrão do projeto que o time segue, será atingido.

O trabalho em equipe do time requer senso colaboração, pois a propriedade do código é da organização, o time é o responsável, todos devem ter o entendimento de tudo ou quase tudo que acontece na aplicação desenvolvida. Não pode ocorrer que tenhamos somente um “guru” da aplicação X.

Quando um código é analisado por outras pessoas e há um olhar sobre o trabalho do outro, o conhecimento acerca do que foi desenvolvido é descentralizado, distribuindo o sentimento de responsabilidade, tornando-o propriedade não só de uma pessoa, mas do time envolvida.

Já sabemos o que é code review e sua importância no processo de desenvolvimento, então o que você deve revisar? O que você está procurando? Essas são boas perguntas para o sucesso do code review.

Sabe aquele nome da branch que você utiliza para identificar aquela sua história no gitlab, github ou outro repositório utilizado pelo time? Ele deve ser tão auto explicativa quando suas variáreis e métodos do seu code. A descrição do que você desenvolveu também é importante. Somente quando entendemos o motivo da revisão, podemos descobrir o quê queremos procurar durante a revisão e atentar a esses dois itens é importantíssimo para que os membros do time revisem seu código.

A revisão será de fato, observado itens que envolve o código:

• Legível;
• De fácil manutenção;
• Extensível;
• Outro que seja acordado pelo time.

Quando fazer? E quando está concluído?

Acontece quando todo o código de sua branch está completo e pronto para produção. Obs: não deve ser feito o merge até que a revisão seja concluída. O time deve estabelecer uma chamada de atenção quando tiver uma história em code review.

O code review deve ser prioridade pois o merge dependerá da conclusão dele.

É desmotivador ter uma história em code review e ficar por muito tempo aguardando o feedback do time, ou que tenha uma revisão que nunca termina.

As diretrizes para decidir quando a revisão estiver concluída será do time de desenvolvimento. Por padrão temos os critérios a seguir:

• Todos os comentários forem tratados por correções no código;

Isso mesmo, terá comentários do time no seu código! Não que seja obrigado a aceitar todos, você pode ter tido motivos para ter feito daquela forma. Defenda e explique, justifique o que fez e o porquê fez. O time sempre decidirá se o que está feito não irá comprometer o que foi previamente acordado para não sair do padrão do projeto. “Democracia code” 😊.

4. Conclusão

Sem mais delongas, vamos as boas práticas:

1. A pessoa revisora não pode ser a mesma que criou o código: afinal ninguém critica seu próprio código. Então deixam que o façam. Ser criticado ajuda evoluir;
2. Registre a revisão e o feedback por meio de uma ferramenta: Quem revisa comente todas as implementações ou fatorações que achar incorreto no guitlab. Quem é revisado, se identificou o erro corrija, se não concorda justifique, se sua justificativa não foi concordada por todos do time, corrija seu código;
3. Tenha uma comunicação direta entre pessoas: A revisão com inclusão de comentários e espera de feedback pode demorar muito, afinal seu colega também está “codando”, então se identificar uma demora, chama o time e debatam pessoalmente ou numa cal para que tenham uma decisão rápida e precisa;
4. Revisões de código não possuem hierarquia: Independente da experiência do profissional de um time, seu código também precisa ser revisado. Como já falei, somos pessoas passíveis de erros, e pode até ser que o código de alguém experiente seja impecável ou quase perfeito, mas não custa revisá-lo. É tendencioso aquele “faca na caveira” do time aprovar uma revisão e o restante ir junto confiando pois ele “é o cara”. Revise mesmos assim. Algo que você está fazendo pode depender do que está no código ou melhor, tem um aprendizado “mastigado” alí pra você consumir;
5. Faça a revisão com tempo e calma;
6. Deixe bem claro o contexto do seu código, seja no nome da branch e no detalhamento dela ao solicitar o merge;
7. Não negligencie o feedback: Não pense que as observações recebidas são de cunho pessoal. Lembre-se que o code review é visando o desenvolvimento de um trabalho em equipe de qualidade.

Para finalizarmos: Todos somos o “pai da criança”.

5. Referências

https://natahouse.com/pt/revisao-de-codigo-descubra-o-que-voce-precisa-saber-sobre-o-assunto
https://blog.convisoappsec.com/4-boas-praticas-de-code-review-para-um-ambiente-realmente-seguro/
https://blog.platformbuilders.io/tudo-que-voce-precisa-saber-sobre-boas-praticas-recomendadas-para-code-review/