Olá! Neste artigo, vou falar sobre revisão de código (ou Code Review). Venho tendo a oportunidade nos últimos trabalhos de realizar essa prática (e de participar ativamente de criação de documentações para isso) e tenho gostado bastante do resultado!

Por conta disso, decidi escrever uma série sobre esse assunto, começando pela parte teórica, e para a próxima parte colocar algo prático.

Vamos lá?

---

Quer ser notificado sobre os próximos artigos, lives semanais, eventos e treinamentos? Entre no canal LuisDev no Telegram!

---

O que é Code Review?

O Code Review, ou revisao de código, é uma avaliação sistemática de código produzido seguindo uma série de parâmetros definidos (idealmente que estejam documentados, para facilitar o processo).

Basicamente, o processo de Code Review segue o seguinte fluxo:

1. Uma pessoa se torna a revisora de código do autor, uma tarefa por exemplo;
2. Ela analisa o código em busca de inconsistências com padrões adotados e também de potenciais problemas de performance e fragilidade de código, entre outros fatores;
3. Finalmente, ela adiciona feedback utilizando alguma ferramenta, como em merge request do Gitlab, e repassa ao autor para correções.

Basicamente, é esse o processo. Nos processos tópicos irei detalhar características dele.

Melhores práticas

Ter um documento para guiar a prática

É muito importante que exista um documento que guie o Code Review, oferecendo valor tanto para quem vai revisar, quanto para quem vai desenvolver. Sem ele, é mais comum que programadores cometam erros que já foram submetidos a Code Reviews anteriores, e que não foram documentados. Além disso, revisores podem ficar sem um “norte” e irem mais por intuição do que um padrão adotado pela equipe, resultando em revisões menos assertivas.

Implementar uma cultura de compartilhamento de conhecimento e feedback

Benefícios

Maior qualidade de código

Fazer com que o código produzido pela equipe passe pelo processo de Code Review resulta em maior qualidade deste. Ele auxilia, entre outras coisas, na:

• Produção de código com uso de melhores práticas;
• Remoção de código desnecessário ou não utilizado;
• Melhora da legibilidade.

Eliminação de bugs

Code Reviews podem ser uma maneira mais “barata” de descobrir bugs do que testes. Os tipos de bugs que normalmente são mais encontrados nessa fase são:

• Lógica e desenho utilizados para resolver o problema;
• Segurança;
• Tratamento (ou falta dele) de exceções.

Cultura de compartilhamento de conhecimento e feedback

Com o tempo, os Code Reviews afetam muito positivamente na distribuição de conhecimento. Tanto o autor quanto o revisor aprendem sobre diversos assuntos nesse processo, como convenções do time, desenho de sistemas, algoritmos, etc.

Além disso, desenvolvedores novos aprendem muito mais rápido sobre o padrão da equipe. Imagina você acabar de chegar em uma equipe, ter seu trabalho revisado, aprender a partir disso e poder contribuir com a qualidade do projeto? Fascinante, não?

Evita que existam salvadores da pátria de módulos específicos

Com a revisão do codigo, evita-se que uma pessoa seja a detentora universal de uma solução, sendo a única capaz de resolver problemas nos módulos desta. E se essa pessoa ficar doente ou sair da empresa?

Diferentes membros da equipe terão conhecimento sobre os módulos que estão sendo desenvolvidos, e isso contribui para um ambiente mais saudável.

Compartilhamento de responsabilidade pelo código e transparência

Todos se tornam responsáveis pelo código. Hábitos de se colocar a culpa em pessoas específicas por falhas no sistema são desestimuladas, já que todos têm seu papel em manter os padrões de qualidade no projeto que está sendo desenvolvido.

Transparência é promovida, já que é bem mais difícil de um desenvolvedor fazer aquelas gambiarras altamente prejudiciais e “se safar” até que ocorram problemas em produção. Membros de equipe se tornam mais abertos não somente a receber, mas também oferecer feedback.

Obstáculos

Existe uma série de obstáculos que podem surgir durante a implementação de revisões de código. Alguns deles são compartilhados com os testes unitários, como explico nesse artigo.

Gerência e seus prazos

Pô, daora esses processos novos que você quer colocar para melhorar a qualidade de código… Seria uma pena se a entrega fosse para hoje, não é mesmo?  

Um Chefe Anônimo

Você, novato na equipe, conversa entusiasmado com os membros sobre práticas supimpas para turbinar a qualidade do que vocês produzem. Eles te olham com uma cara de “Sabe de nada, inocente”, e dizem que seria ótimo se o chefe de vocês não viesse frequentemente pedindo novas alterações “inofensivas”, com aquele prazo… até o final do dia.

Realidade é que ter um gestor desses complica a implementação de praticamente todas boas práticas. Algumas se tornam possíveis com grande esforço, mas a motivação vai por água a baixo a cada cobrança desse nível.

A dica que dou é tentar apresentar os benefícios das práticas, como mostrei nos tópicos anteriores, e tentar negociar um processo de desenvolvimento com ele.

Fator humano

Algumas pessoas são bem aversas a receber feedback sobre seu trabalho. Imediatamente se colocam em posição defensiva, e pouco se dispõe a escutar e entender a mensagem a ser passada. Isso é ainda mais intensificado em uma prática como o code review, já que o código de cada um é analisado literalmente linha por linha.

Além disso, já vi de pessoas agirem como uma “quadrilha” em relação a essa prática. Sim, existem pessoas que “revisam” o código de outra, sem real intenção de achar bugs. Ou mesmo não se interessam em revisar nada, e simplesmente aprovam o código sem bater nem o olho. Algo perceptível nesses casos é quando uma pessoa simplesmente não deixa feedbacks de código. Tipo, nunca. Tarefa vai, tarefa volta, e a pessoa assiste a tudo passivamente.

Sinceramente, não sei o que é pior. Não conseguir implantar essa prática por conta de pressão de prazos da gestão, ou de membros da equipe que simplesmente não estão interessados na qualidade do produto desenvolvido. O que acham?

Quando se tem propósito na equipe em relação à melhora contínua da qualidade, acredito que problemas desse tipo dificilmente ocorram. É importante deixar claro que todos têm sua responsabilidade no produto sendo construído, e que os desenvolvedores se sintam a vontade para opinar sobre melhorias no processo.

Falta de entendimento do que foi implementado

Imagine que você acabou de chegar na equipe, e não sabe praticamente nada do que a aplicação realiza. Te colocam para revisar código, e ao visualizar aquelas 15 mudanças no código, você simplesmente não entende o que está ocorrendo. Que elementos da arquitetura são esses? Como funcionam por baixo dos panos? Que possíveis exceções podem ocorrer a partir deles?

A tarefa de revisar código e checar por problemas de segurança, fragilidade e performance fica bem complicada quando não se conhece o domínio nem os componentes da aplicação.

Práticas que acredito que ajudem bastante nesse quesito:

• Pair programming com alguém mais experiente na equipe. Assim, os desenvolvedores que acabarem de chegar na equipe conseguem ver resolução de problemas reais, enquanto tiram suas dúvidas sobre o sistema.
• Documentação da arquitetura e padrões dos componentes constituem uma boa forte de compartilhamento de conhecimento sobre os projetos e são um bom pontapé para o desenvolvedor na equipe.

---

Quer alavancar sua carreira como Desenvolvedor(a) .NET?

Opa, aqui é o Luis Felipe (LuisDev), criador do blog LuisDev.

Além de Desenvolvedor .NET Sênior, eu sou instrutor de mais de 700 alunos e também tenho dezenas de mentorados.

Conheça o com mais de 800 video-aulas sobre C# e desenvolvimento de APIs com ASP NET Core, Microsserviços com ASP NET Core, Arquitetura de Software, Computação em Nuvem, SQL, HTML, CSS e JavaScript, JavaScript Intermediário, TypeScript, Desenvolvimento Front-End com Angular, e Desenvolvimento Front-end com React. Diversos mini-cursos disponíveis aos alunos e atualizações gratuitas.

Suporte dedicado, e comunidade de centenas de alunos.

Completo e online, destinado a profissionais que querem dar seu próximo passo em sua carreira como desenvolvedores .NET.

Clique aqui para ter mais informações e garantir sua vaga

Conclusão

Espero que pelos benefícios que o code review possa agregar em seus projetos, sua equipe não se intimide em implantá-lo. E que conhecendo os obstáculos, a implementação dessa prática seja mais assertiva e sem tantos atritos.

No próximo artigo dessa série, a parte prática será explorada, com a apresentação de alguns trechos de código e como eles podem ser melhorados de um ponto de vista de Code Review.

Até a próxima!