Code Review: mais do que uma etapa do processo

H pouco mais de um ano, eu deixava meu estgio em uma empresa onde trabalhava principalmente em uma plataforma low code para abraar a oportunidade como desenvolvedor jnior em um outro lugar.

Nessa nova empreitada, pela primeira vez me deparei com uma base de cdigo grande e complexa, nada parecida com os projetos da faculdade ou dos cursos que j havia feito at ento.

Durante os primeiros meses, eu me cobrava frequentemente para ter uma compreenso maior dos projetos, do cdigo e das regras de negcio. Foi nessa poca que li o artigo How to Review Code as a Junior Developer e me mantive ainda mais firme em um hbito que comeava a cultivar: fazer code review todos os dias.

Aps todo esse tempo e um pouco mais de bagagem na mochila, resolvi compartilhar um pouco da minha viso sobre tudo isso e trazer algumas das dicas do artigo traduzidas para o portugus. Vamos l?

Code Review para todos?

Vira e mexe, a bolha dev do Twitter recebe uma mesma pergunta: "jnior tambm faz review?". Quem conhece a nossa bolha sabe que a mais pacfica das perguntas pode gerar a mais sangrenta das batalhas, com muitas opinies, polmicas e cagaes de regras relatos pessoais. Para mim, no entanto, a resposta para essa pergunta deveria ser uma unanimidade: todo mundo deveria fazer code review.

A primeira reao frente a essa ideia questionar a viabilidade de ter algum to iniciante revisando cdigo de pessoas com maior senioridade. Aqui, para mim, entra um ponto muito importante: revisar cdigo no apenas sobre corrigir ou necessariamente melhorar o que est sendo proposto.

Ora, se no sobre literalmente revisar o cdigo e torn-lo melhor, sobre o que seria?

No artigo Reviso de cdigo mais do que revisar cdigo?, de 2015, Maurcio Aniche apresenta os resultados de uma pesquisa feita internamente na Caelum, em que eram observadas as diferenas entre cdigo antes e depois de reviso de cdigo, alm da prpria percepo dos impactos dessa prtica por parte das pessoas desenvolvedoras . O resultado um tanto surpreendente: o code review se mostrou muito mais eficiente na disseminao de conhecimento do que melhoria de cdigo, embora a equipe de desenvolvedores tambm identifique resultados nesse sentido.

Portanto, muitas outras coisas podem ser estimuladas com a reviso de cdigo, como a oportunidade para levantar discusses, aprender tpicos tcnicos e de negcio e, de quebra, fortalecer o time e cultura.

H controvrsias

Eu disse h pouco que, para mim, todos deveriam fazer reviso de cdigo, mas preciso ser um pouco mais especfico. Esse posicionamento faz sentido caso o time tenha escolhido utilizar pull requests em seu fluxo de trabalho. Para esse caso, toda a discusso deste texto pode ser aplicada.

No entanto, preciso dizer que h diversos pontos negativos e potenciais desvantagens em trabalhar com pull requests e code reviews. H sempre outras abordagens e outras vises. Como quase tudo em computao, lidamos aqui com um trade off e devemos seguir pelo caminho que faa mais sentido para o contexto em questo.

A abordagem de trunk based development, por exemplo, advoga a favor de feature branches de curta durao (dois dias, no mximo) ou mesmo de integrao direta na branch principal, desde que o time tenha uma abordagem minimamente segura para isso. Martin Fowler j escreveu sobre a impossibilidade de se ter pull requests e continuous integration em um mesmo fluxo, visto que integrao contnua pressupe uma interao diria de cada integrante do time com a branch principal.

Dado o contraponto, sigamos com a nossa discusso.

Aprendizado e autonomia

Se voc uma pessoa experiente, com grande bagagem tcnica, mas que acabou de chegar em um time, esperado que voc no tenha conhecimento da base de cdigo e do negcio com o qual vai trabalhar. Ler pull requests, ento, se mostra como uma oportunidade perfeita para aprender as modelagens e abstraes, expandir o conhecimento do cdigo para alm do domnio de suas tarefas e tirar tantas dvidas quantas quiser.

Para isso, uma atitude fundamental: faa perguntas. No tenha medo de julgamentos ou de parecer incompetente por isso. Da mesma forma, responda perguntas sempre que puder. Contribua para as discusses e para que esse ambiente de troca de conhecimento se mantenha frtil.

Em contato frequente com as interaes que ocorrem nos pull requests, voc tambm poder entender quais pontos so caros para aquele time, identificar como as pessoas se relacionam e criar um sentimento de pertencimento ao time.

Agora, se voc algum que no possui conhecimento da base de cdigo nem tem experincia, revisar cdigo a oportunidade no s de alcanar tudo j mencionado at aqui, mas tambm um timo ambiente para aprender tpicos tcnicos. Ao ler cdigo de tarefas mais complexas, provavelmente voc vai ver solues, tecnologias e possibilidades com as quais voc dificilmente esbarraria em outros contextos.

Como uma pessoa desenvolvedora iniciante, muitas vezes voc vai "imitar" as estratgias de outras pessoas da sua equipe. Nesse sentido, ter contato com outras tarefas faz com que voc tenha muito mais cartas na manga para usar nas jogadas.

Portanto, evidente que fazer code review potencializa o processo de aprendizado dentro de um novo projeto. Consequentemente, isso leva a um crescente de autonomia na forma como se encara as tarefas. muito mais provvel que algum sinta segurana para mudar as coisas durante os primeiros meses quando se tem uma noo maior de como tudo funciona.

Um espelho do time

A forma como code review feito reflete o seu contexto, portanto, a forma como o time est organizado e como costuma interagir influencia diretamente nisso. Nesse sentido, essencial que o time possua uma cultura de abertura a discusses e proporcione um ambiente seguro, o mais livre possvel de opresso ou julgamentos.

Somente assim ser possvel colocar em prtica code reviews no s como uma formalizao de aceite, mas sim como um lugar propcio para fazer perguntas, tirar dvidas, discutir melhorias e perspectivas.

Para times que trabalham de forma remota, os pull requests se mostram tambm como mais uma maneira de tornar informaes pblicas, contribuindo para o trabalho assncrono e fortalecendo autonomia do time, no sentido de descentralizao de conhecimento. Por isso, d preferncia por manter as discusses no pull request, para que outras pessoas possam ver e aprender junto. Caso as conversas tenham se dados em outro meio, vale a pena tambm manter um registro escrito no pull request.

Por fim, quando defendo a ideia de que todos deveriam fazer reviso de cdigo de todos, me refiro tambm ao conceito de feedback circle (ou "crculo de feedback"), isto , quando pessoas se propem a estar vulnerveis entre si e ter seu trabalho disposio para ser revisado, temos um ambiente em que se torna mais fcil tecer comentrios e construir feedbacks. No mais, isso evidencia a horizontalidade do time, sem amarras rgidas de hierarquia.

O desafio de promover Code Review

Como podemos ver, o simples ato de revisar cdigo pode levar a diversas vantagens. Mas nada to simples nem to fcil quanto parece, afinal estamos diante de duas tarefas bastante difceis: promover uma cultura propcia para que o time aproveite ativamente essas oportunidades e que, principalmente, faa mais code reviews.

Esses pontos so difceis de implementar por estarem intimamente ligados cultura. E cultura algo que no podemos controlar diretamente, visto que cresce e muda de forma orgnica. Colocar essas mudanas em prtica pode envolver muitos outros processos.

Frequentemente, a equipe de desenvolvimento recebe uma quantidade alta de demandas e coloca seu esforo principalmente em entregar tarefas para dar vazo a esse fluxo. Nesse caso, no difcil que os integrantes estejam constantemente em um pull request paradox.

De toda forma, possvel adotar algumas prticas e estimular alguns hbitos, como:

• Incentivar as pessoas a fazer pull requests menores e bem documentados. Isso faz com que no s tenhamos mais chance de receber reviews, como tambm diminui o risco quando as mudanas forem para produo.

• Possuir um guia de estilo e um guia de reviso, para que as pessoas saibam o que vlido ou no comentar em relao a estilo, formatao, nomenclatura etc. Assim evitamos comentrios repetitivos e temos um acordo j definido que deve ser seguido.

• Tornar claro por meio dos valores do time que revisar cdigo parte fundamental do trabalho e tem tanto valor quanto entregar tarefas.

Mais do que uma etapa

Tal qual um escalador, que, enquanto guia a escalada, confia e se apoia na segurana e perspectiva que recebe de seu segurador, o autor ou autora de um pull request tem muito a ganhar quando pode contar com outras vises e com o apoio de revisores.

Por todos os pontos mencionados aqui, acredito que code review seja mais do que uma simples etapa do ciclo de vida das tarefas. E por esse motivo, algo que merece ateno para ter todo seu potencial aproveitado.

Foto de capa: Via ferrata Irg2, de Maja Kochanowska.