Revisão de Código — a melhor amiga do seu repositório

Hoje vou falar sobre revisão de código, seus benefícios e tentar desbancar alguns mitos e medos que permeiam o assunto. Essa é uma prática muito usada em ferramentas open-source e em grandes empresas de tecnologia.

O texto assume que você e seu time saibam o que é versionamento de código, caso não saiba, recomendo que procurem sobre git, podem ler o ótimo https://git-scm.com/book/pt-br/v1/Primeiros-passos-No%C3%A7%C3%B5es-B%C3%A1sicas-de-Git.

Porque revisar código?

Revisar código significa entender o que ele faz. Ao adotar uma política de revisão de código, a tendência é que o código fique cada vez mais claro, pois a revisão visa garantir que uma pessoa que não escreveu o código é capaz de entendê-lo. Isso aumenta a qualidade do código e diminui a incidência de bugs.

Evita silos de conhecimento

Você já viu uma situação em que uma pessoa deixou a empresa e ninguém mais sabia como funcionava o código dela? Você já teve que mudar suas férias porque tinha algum prazo pro seu projeto e você era a única pessoa que sabia mexer nele?

Fazer revisões de código constantes, a cada mudança, faz com que o conhecimento do projeto se espalhe, evitando que uma única pessoa seja responsável por tudo. Isso é muito saudável tanto para a pessoa quanto para a equipe.

É ótimo para o time manter padrões

Quando um time trabalha em um projeto, é natural que diferentes pessoas entendam mais de partes distintas dele. Alguém pode entender melhor a arquitetura, outro sobre como é o armazenamento dos dados, outro sobre a interação com o usuário, e assim por diante.

Todo esse conhecimento é muito valioso, e seria um desperdício não usá-lo. Revisar as mudanças propostas é uma maneira de garantir que o resto do seu time entenda o que suas alterações influenciam no programa, podendo futuramente mexer nessa parte ou apontar melhorias para alguns trechos.

Com as revisões, também fica mais fácil orientar sobre o uso de padrões de código que o time busca, como Design Patterns, ou testes unitários, por exemplo.

É só para os desenvolvedores mais experientes então?

Näo!!! Todos devem participar e alternar na revisão de código, independente da senioridade na empresa ou há quanto tempo programa. A revisão é uma excelente oportunidade de dividir o conhecimento, e se você não entende o que um trecho de código faz, pergunte! A outra pessoa pode te explicar sobre ele ou torná-lo mais claro.

Todos devem trabalhar para manter a qualidade do código alta. Muitas vezes pessoas menos experientes acabam forçando as mais experientes a escrever código mais claro, e isso é ótimo! Às vezes é fácil se perder em conhecimentos muito específicos de uma linguagem ou framework, e isso acaba criando silos, o que é péssimo pro time e pra empresa.

“Mas eu tenho vergonha de revisarem meu código”

Eu te entendo, pequeno gafanhoto. Normalmente os motivos para se ter vergonha ou medo de revisarem seu código são:

  1. Você é muito novo na carreira ou na empresa, e tem medo de ser julgado pelo seu código.
  2. Você não confia nas próprias habilidades.

Se seu caso for o (1), você não deveria temer. Ter seu código revisado por pessoas mais experientes é uma das melhores maneiras de aprender mais e conseguir evoluir na carreira! E todos do seu time vão buscar te ajudar, porque isso é o melhor para o time.

No caso (2), você pode estar sofrendo de algo chamado Síndrome do Impostor, uma explicação breve é que você vê outras pessoas e as julga muito talentosas, e acaba se sentindo uma fraude. Nesse caso, tenho uma ótima notícia para você: ter seu código revisado é uma ótima maneira de evoluir, você pode revisar código das pessoas que acha talentosas para aprender como elas fazem, ou ainda perceber que, na verdade, seu código é bem bom!!

Caso você se sinta inseguro de pedir feedback sobre seu código mesmo depois de tentar algumas vezes, converse com alguém mais antigo na empresa que você se sinta à vontade, isso pode ajudar muito.

Quando revisar código?

Caso você use git como versionamento em sua equipe, fazer revisões de código é muito simples! Basta criar uma política de mudanças que passe por “Pull Requests”.

Isso significa que toda mudança a ser incluída no código deve ser feito em uma branch e, quando concluída, um Pull Request deve ser criado a partir dessa branch. Dessa forma, outras pessoas podem revisar a mudança, contribuindo para a qualidade do repositório e para uma branch principal sempre funcionando.

Se sua equipe usa outro sistema de versionamento, veja se existe algo similar às branches do git, normalmente existe alguma estrutura parecida, e é possível visualizar as diferenças (diff) entre a branch e o código base. A revisão deve então ser feita baseada nesse diff entre a mudança proposta e o código base.

Conclusão

Revisar as mudanças no código antes de integrá-lo a seu repositório é uma prática que permite construir e entregar funcionalidade mantendo qualidade como ponto focal.

Essa ferramenta não serve para avaliar desenvolvedores, e sim para empoderá-los na hora de contribuir em um produto.

Lembre-se que essa é uma ferramenta, e pode ser adaptada para a realidade da sua equipe. Pequenas mudanças, mantendo a estrutura original pode ser ótimo para sua equipe. Experimente, mude e integre essa prática no seu fluxo de trabalho!