Quem nunca teve raiva do programador que você era a alguns anos atrás? É comum no começo de nossas carreiras focarmos “somente” em codar e esquecer de certos padrões e premissas. Code Review é um desses padrões. As vezes até conhecemos estes padrões, mas os tratamos como bullshit. Passam-se os anos e quando você revisita os projetos dessa época fica com raiva da imaturidade do seu eu mais novo, pois agora você está pagando o preço.

Veja as situações abaixo:

Projeto 1: A alguns dias atrás abri um projeto com o qual não mexia fazia um bom tempo. Projeto estável, em produção, porém bem antigo. Precisava fazer pequenos ajustes. Abri o código e não entendi porcaria nenhuma. Fui ao Github, comecei a olhar os commits, na esperança de achar alguma explicação. O que encontrei foram commits muito grandes e com mensagens muito genéricas. Todos os commits feito diretamente na master. A última esperança era falar com meu colega de trabalho neste projeto. Ele leu o código e entendeu menos ainda do que eu. Tive que sair codando no escuro e torcendo para não quebrar nada. Experiência nada legal.

Projeto 2: Mesma situação. Projeto estável e em produção, porém antigo. Precisava fazer pequenos ajustes. Abri o código e entendi bem algumas coisas, porém outras fiquei na dúvida. Fui ao Github, comecei a olhar os commits, vi mensagens claras e merges originados de pull requests. Abri o pull request e vi discussões sobre cada trecho de código. Gastei meia horinha relendo os PRs e pronto! Projeto fresco na cabeça e muito mais fácil para dar manutenção.

Sabe a diferença do primeiro projeto para o segundo? Code Review! O segundo projeto teve como premissa a aprovação do seu código por outro desenvolvedor. Este detalhe trouxe uma série de novas necessidades que acabaram por documentar todo o processo.

Afinal de contas, o que é Code Review?

Segundo o Wikipedia:

Code review is systematic examination of computer source code. It is intended to find mistakes overlooked in software development, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.

Tradução livre:

Code Review é uma examinação sistemática de código-fonte computacional. Tem como intenção encontrar erros que passaram desapercebidos no desenvolvimento de software, melhorando a qualidade do software. Essas revisões são feitas de várias formas, como pair-programming, análises informais e até inspeções formais.

Entendeu? Simples né. Na prática, é basicamente você fazer isso aqui: “Fulano, se liga como eu resolvi esse problema. O que você acha?”.

É algo super fácil de se fazer, porém, muitas vezes é negligenciado pela constante urgência em entregar.

“Mas Moacir, se eu for ficar analisando código dos outros e chamando os outros para analisar o meu código, eu vou perder muito tempo e isso vai comprometer a entrega!”

Por quanto tempo esse projeto vai se desenvolver? Provavelmente alguns anos, certo? Com essa mentalidade você invariavelmente, vai cair no cenário do Projeto 1. O segredo está em entender a mentalidade por trás do conceito: Trata-se de organização, prevenção de dados, otimização de tempo e desenvolvimento coletivo.

Mas como eu coloco o Code Review em prática?

Para colocar um processo de Code Review em prática é preciso entender que estamos falando de uma mentalidade, um modo de se trabalhar. É preciso desenvolver e praticar a cultura. Com isso em mente, existem algumas ferramentas e modo de trabalho que podemos adotar.

Pair Programming

Parear e programar junto com um colega é uma das experiências mais legais quando falamos em desenvolvimento. Não tem segredo, né? Coloca a cadeirinha do lado do coleguinha e comecem a discutir e programar. Revezem o piloto e pau na máquina.

Cabe aqui o bom senso também pra entendermos que estamos investindo o tempo de duas pessoas em uma mesma atividade. O interessante é atacar problemas estruturais ou estratégicos, onde as decisões tomadas influenciarão no desenvolvimento futuro, afinal, duas cabeças pensam melhor que uma.

Pull Requests e Code Approval

Você usa Github, certo? Também sabe que o jeito correto de programar é sempre fazer um fork da branch principal, desenvolver nesta branch e depois fazer um merge com a branch principal. Porém, como você está fazendo isso?

Pra quem usa Github como ferramenta pra gerenciar seu repositório git, existe uma funcionalidade chamada Pull Request. Basicamente, quando você faz push da sua branch e abre ela no Github, terá um botão “New Pull Request”. Ao clicar neste botão, você abrirá uma solicitação de merge com a branch principal. Essa solicitação vem com um pequeno disclaimer, onde basta explicar com detalhes o problema a ser resolvido e como você decidiu resolver esse problema.

Pull Request feito, você terá uma interface com todas as diferenças entre as duas branchs destacadas de forma simples e intuitiva. Você também terá uma thread para questionamentos e discussão sobre melhorias. Você também pode solicitar a pessoas específicas para revisar seu código. Poderá também travar o merge para que ele seja feito somente depois de alguém aprovar seu código.

Resumindo: É basicamente tudo o que você precisa para fazer um Code Review de respeito!

Revise a abordagem do problema e não code style

Pronto! Você conseguiu convencer sua equipe a fazer Code Review e agora todos estão fazendo seus pull requests e entrando no fluxo. Logo no primeiro Code Review que você vai fazer, você começa a marcar todas as “não boas-práticas” do coleguinha, como indentação com Tab, importação de libs não utilizadas, etc. Pode parar! Tá errado!

A intenção do Code Review não é ficar apontando detalhes irrelevantes que não agregam valor ao projeto. A intenção é revisar e aprimorar a abordagem do problema e a forma como ele foi resolvido. É isso que vai fazer o nível técnico, seu, do seu colega e do projeto evoluir.

É claro que vale uma dica aqui ou outra ali. O importante é manter o foco no objetivo do problema e principalmente manter o bom senso. Por exemplo: Seu colega utilizou percent form ao invés de format para imprimir uma string em Python, quando todo o projeto utiliza format. É super pertinente você alertar sobre o ocorrido, porém não faz sentido não aprovar o merge só por causa deste detalhe.

Bom senso deve ser o norte para tornar a prática saudável. Aliás, bom senso deve ser o norte em todo processo que envolve comunicação com outras pessoas.

Automatize tudo o que pode ser automatizado

Algumas pessoas podem discordar da seção acima quando digo para ignorar divergências de code style. E com razão. Manter o padrão do projeto é super importante. É muito irritante pegar partes do projeto que fogem totalmente ao padrão geral. Mais irritante ainda é quando um projeto não tem padrão.

A questão aqui é que tudo isso pode ser resolvido de uma forma simples, prática e com custo baixíssimo de tempo: Automatize!

Existem diversas bibliotecas de linters que revisam seu código automaticamente e colocam ele no padrão definido para cada linguagem. Também praticamente todos os editores de texto/IDEs decentes fazem isso ou possuem plugins para que isso possa ser feito a cada momento que você salva o arquivo. Existe tanta ferramenta boa pra isso que renderia um post. O papo é longo!

É também importante ressaltar que na grande maioria das vezes novas alterações quebram funcionalidades já implementadas. A cada nova alteração você vai repassar tooooodo o projeto só pra verificar se tudo está ok e nada quebrou? Não! Você vai programar orientado a testes automatizados.

Com os testes automatizados você garante que tudo o que foi feito e testado esteja funcionando. Caso rode os testes e algo quebre, você vai e conserta antes de fazer o pull request. Simples né?

Além disso você pode plugar serviços de continuous integration (como o CircleCI que é de graça, por exemplo) e fazer com que os testes rodem sempre que um Pull Request for aberto. Assim, caso alguém esqueça de rodar os testes antes de abrir o PR, o Github e o CircleCI resolvem isso pra você de forma automática.

Boas práticas para praticar um bom Code Review

O Code Review em si só já é uma boa prática. Entretanto existem algumas dicas e macetes que ajudarão a manter um fluxo otimizado. Segue uma lista de boas práticas e um resumo do artigo:

  • Resolva apenas um problema por pull request. Se for um problema grande, quebre em partes menores. Isso vai otimizar o tempo de seus colegas e fazer com que seu PR seja fácil de ser entendido.
  • Seja claro na sua comunicação. Explique sempre o que você fez e principalmente porque você fez isso.
  • Seja educado e critique construtivamente. A intenção é buscar a melhoria e não apontar erros.
  • Automatize tudo o que possa ser automatizado. Foque na resolução do problema e evite trabalho manual e operacional.
  • Faça com que o time se baseie em um style guide já conhecido e difundido. Não há necessidade de reinventar a roda.

Espero que este artigo tenha sintetizado bem os benfícios que a prática do Code Review pode trazer.

Gostou do artigo? Compartilhe! Não gostou, compartilhe para falar mal de mim.

Ficou com alguma dúvida ou não concorda com algo que eu disse? Ficarei imensamente feliz em bater um papo com você. Os comentários estão habilitados logo abaixo.

Abraços

Referências