Revisão de código: um valor indispensável para empresas de tecnologia

A intimidade da liderança técnica com o código se concretiza no dia a dia bem mais na atividade de revisão de código no que na de escrever código. A revisão de código (code review) é muitas vezes encarada como menos importante, ou apenas como um processo burocrático, quando na realidade é central para qualquer empresa de tecnologia.

Boa parte do direcionamento técnico de uma organização deve ser feito por revisão de código, e não com discurso. E isso se faz com eficiência com o uso de ferramentas de engenharia. 

A revisão de código é uma excelente estratégia de treinamento, formação e mentoria de profissionais. Para começar, o code review pode ser encarado como uma continuação do processo de onboarding de uma pessoa que entra na organização. Com revisões de código cuidadosas e detalhadas, pode-se ensinar:

• Quais são os processos daquele lugar
• Como o sistema está organizado
• Quais são os detalhes que precisam de mais atenção

 O processo de revisão de código é extremamente relevante para o aprendizado e o acompanhamento dos novatos, em especial no esquema de trabalho remoto. Revendo código de forma atenta e criteriosa, os profissionais da liderança técnica da empresa conseguem transmitir o direcionamento técnico para a construção dos sistemas que darão solidez e proporcionarão inovação. 

Claro que isso não significa que um contribuidor individual nos níveis mais elevados deva passar o dia todo revendo código de sistemas que são commodity e que terão pouca relevância estratégica para a empresa. Ele pode até ocasionalmente fazer isso como forma de ter uma noção de como anda a qualidade do trabalho na base da pirâmide de funcionários, mas o grosso de suas atividades estará concentrado naquilo de mais relevante e estratégico que a empresa esteja construindo.

O zelo pelo código gera eficiência, porque é mais fácil corrigir um problema durante o processo de revisão e testes do que depois que o sistema já está no ar. E incidentes acabam sendo evitados pelo caminho, desde que quem é responsável pela revisão se sinta à vontade de realmente pedir modificações sempre que necessário, o que só ocorre quando o processo todo está enraizado na cultura da empresa. A revisão não pode ser encarada como uma tarefa que tem de ser feita com pressa para que o código entre logo em produção. 

Independentemente de uma pessoa escrever textos ou códigos, erros sempre acabam sendo cometidos, e quem cometeu o erro costuma não conseguir enxergá-lo, por mais que tenha cuidado ao longo da revisão.

Em textos há um processo de edição e depois de revisão, e com códigos é a mesma coisa: um segundo e até um terceiro par de olhos reduzem em muito a probabilidade de  erros passarem para a frente, mesmo que vários testes tenham sido realizados. O revisor de código traz um olhar diferente e fresco, que pode captar um bug ou sugerir uma modificação que torne o software melhor.

Regras para que a revisão de código seja eficaz

Quanto mais diretrizes e padrões claros existirem na empresa, mais fácil será fazer a revisão de código, pois o que estiver fora do padrão ficará evidente e não estará aberto a questionamento. Quando não há padrões, ao contrário, a revisão é muito mais subjetiva.

Se uma ferramenta já integrar por exemplo a formatação, o revisor nem vai precisar colocar comentários para corrigir a maneira como o código está formatado. E, mesmo que as diretrizes não estejam integradas à ferramenta, só o fato de haver um padrão protocolado já economiza o comentário, porque basta dizer: “Não está seguindo o padrão”.

Existe uma etiqueta que deve ser seguida na revisão de código, pois ela precisa ser respeitosa, e, embora a rapidez não seja o objetivo principal, a agilidade também conta. Em primeiro lugar, é preciso ficar claro para todos que a revisão não é algo pessoal. Tanto quem revisa quanto quem é revisado têm de tratar aquilo como um feedback construtivo, não uma briga de egos. Não pode haver competição entre quem revisa e quem escreve o código. 

Quando líderes do tipo “diminuidor” – na terminologia de Liz Wiseman e Georg McKeowan no livro Multiplicadores – rejeitam o código que receberam para revisar e o reescrevem à sua maneira, os funcionários se frustram e, com o tempo, podem acabar indo embora da empresa. Quem faz a revisão de código tem que ter maturidade profissional para entender que está:

• Zelando pela qualidade do código
• Impondo os padrões arquiteturais da empresa
• Tentando evitar que incidentes aconteçam no futuro

Tanto quem submete o pedido como quem revisa têm que manter os comentários educados e objetivos, com  a consciência de que a finalidade da troca é aprimorar o código para que o trabalho de todos saia aprimorado.

Tanto quem revisa quanto quem é revisado têm de tratar aquilo como um feedback construtivo, não uma briga de egos. Não pode haver competição entre quem revisa e quem escreve o código. 

Do lado mais prático, é inegociável que qualquer pedido de revisão de código venha acompanhado dos respectivos testes. Assim que o revisor recebe o pedido, deve abri-lo, dar uma olhada rápida para verificar se os testes vieram junto, e dar uma resposta inicial a quem escreveu o código, já abrindo uma linha de comunicação. Se verificar que não há testes, que alguma coisa está fora do padrão ou que por algum motivo não é a pessoa ideal para fazer aquela revisão, deve devolver o pedido imediatamente, para que não se perca tempo e para que a nova solicitação seja feita da forma correta. 

A existência de ferramentas para conduzir essas trocas aumenta a eficácia do processo. Os comentários de ambos os lados ficam registrados e devem ser acompanhados pelas outras pessoas envolvidas no projeto, porque dessa maneira o aprendizado se multiplica. 

Isso não elimina o valor de uma conversar ao vivo, em tempo real, para casos específicos. E, quando há uma discordância que não está sendo superada, vale a pena pedir ajuda externa para uma terceira pessoa que consiga intermediar a “negociação”.

Objetivos da revisão de código

O profissional revisor tem que ter em mente objetivos mais amplos, afinal é pensando dessa forma que coloca em prática as diretrizes técnicas da empresa. Será preciso avaliar se:

• O código está correto e claro.
• A mudança proposta está sendo feita no lugar certo.
• O problema está mesmo sendo solucionado.
• O problema em questão é o problema correto a ser resolvido.
• A mudança no código é um investimento necessário.
• O design da alteração é escalável, em termos estruturais.
• A mudança se acopla bem a outros elementos da plataforma.
• A modificação não vai causar dependências que levem a débitos técnicos.
• As interfaces propostas são extensíveis e intuitivas.
• Há documentação correta a respeito da alteração, para prevenir dificuldades na manutenção do código.
• O código novo foi escrito dentro do espírito de facilitar a realização de mais testes em modificações ou adições futuras.
• O código é resiliente a instabilidades.
• Há mecanismos para evitar que ocorra algum tipo de incidente quando for posto em produção, além de sistemas de alerta e de reversão de mudanças em caso de emergência. 
• A alteração pode causar problemas de desempenho (é mais comum do que se imagina), e se há testes específicos nesse sentido. 

Quando uma liderança faz revisão de código, ela consegue verificar na prática se o conceito de plataformas está sendo aplicado, e tomar providências se achar que não está. E também assegura que o código seja claro, legível e padronizado, para que qualquer desenvolvedor da empresa seja capaz de lê-lo e compreendê-lo, mesmo que muitos anos depois. Por fim, está ajudando a construir na organização o pensamento intencional de evitar débitos técnicos, planejar horizontes de curto, médio e longo prazo e fomentar a inovação.

Valorização da revisão de código na cultura da empresa

Para estabelecer uma cultura forte de revisão de código em uma companhia, é preciso que essa priorização se reflita em promoções e aumentos de remuneração.

Se o sistema de avaliação e de progressão de carreira mensurar apenas novas funcionalidades que tiverem sido postas em produção por um funcionário ou gestor, a importância da revisão de código fica invisível e não há incentivo para fazê-la. Como pode ser premiada uma pessoa que passa 80% do tempo revendo criteriosamente o código escrito por outros engenheiros, garantindo que as diretrizes estruturantes estejam se traduzindo em sistemas?

A ênfase na revisão de código tem de estar alinhada com os parâmetros usados para a progressão de carreira, e outras iniciativas menos tangíveis podem reforçar o processo. Se a mais alta liderança técnica da empresa revisar código e disponibilizar os comentários publicamente por intermédio das ferramentas, fica claro para o resto da engenharia de que se trata de um trabalho relevante. 

O envolvimento pessoal das lideranças é um dos mecanismos do dia a dia para reconhecer conquistas e ditar a cultura da empresa. Os objetivos estratégicos têm de estar integrados tanto aos instrumentos de avaliação de desempenho e remuneração quanto a métodos mais informais de incentivo, como prêmios e reconhecimento público.

Outro motivo para valorizar uma cultura de revisão de código é o compartilhamento de responsabilidade na hora em que um incidente acontece. A pessoa que revisou o código não pode ser encarada como aquela que simplesmente autorizou a mudança apertando um botão, e sim como uma parceira no desenvolvimento daquele código, e que pode se envolver para solucionar um eventual problema que apareça.

O hábito da testagem exaustiva possibilita que os times se sintam mais seguros em abrir o código para contribuições externas dentro da empresa e até fora dela, em um esquema colaborativo de verdade.

Se a mais alta liderança técnica da empresa revisar código e disponibilizar os comentários publicamente por intermédio das ferramentas, fica claro para o resto da engenharia de que se trata de um trabalho relevante.