Code review: Porque não leva-lo para o lado pessoal

Olá caro leitor, hoje acabei inclinado a escrever um pouco sobre experiências que estão além da bancada ou do computador, mas que intimamente conectada, faz parte do meu dia-a-dia, a prática da revisão de código, podendo ser “agringalhada” no termo Code review. O objetivo desse pequeno artigo não é postular formalmente a prática, tampouco exibir algum tutorial de como fazê-lo. Trata — se um incentivo a reflexão desse tipo de processo e porque um desenvolvedor, independente do seu grau de conhecimento, não deve tomar o processo de críticas como algo pessoal.

Mas antes de tudo: Code Review in a “small” Nutshell

A prática da revisão de código, como o proprio nome sugere, consiste num estagio intermediário de integração, muito presente em projetos onde exista mais de um desenvolvedor, é interessante deter algum controle de cada linha de código que entra ou sai da versão distribuida ao cliente final (e isso é agnóstico ao tipo de software que você desenvolve, seja embarcado, servidor ou web), assim tem — se esse estagio intermediário consistindo na revisão das mudanças que serão integradas ao código comum entre todos os desenvolvedores.

Confuso? Vamos deixar a coisa mais fácil, imagine que dois desenvolvedores com grau de conhecimento equivalente sejam escalado para trabalhar no desenvolvimento de uma aplicação embedded (desculpem a turma dos outros ramos, mas precisei pegar um exemplo próximo a mim, ok?) para fazer a leitura e publicação dos dados de alguns sensores. Desenvolvedor A, cuida da aquisição, e Desenvolvedor B cuida do envio dos dados. Eles concordam entre si em publicar melhorias incrementais da aplicação final num repositório de software (firmware nesse caso) comum a ambos, com as seguintes condições:

1 - “Toda e qualquer mudança a ser publicada devera ser revisada por alguém que não seja o desenvolvedor desta.”

2 - “O aceite para publicação dessa mudança é condicionada a concordancia do que foi escrito por ambos os participantes da revisão.”

Deixando a coisa ainda mais simples, só entra no repositório comum, modificações no firmware que sejam revisadas pelo próprio desenvolvedor, e um ou mais terceiros e que todos eles concordem com a mudança proposta. Lembrando que os revisores podem se recusar a autorizar uma publicação que possa ser potencialmente nociva ao desempenho final do projeto desenvolvido. Pra quem gosta de uma ilustração, segue um processo simplificado ao abrir um pull request no conhecido github:

Pull request simplficado no github

Momento da frustração: Quando recusam uma modificação

Chegamos no ponto que esse texto quer tratar, o caminho feliz da revisão de código consiste quando o Desenvolvedor A, do nosso exemplo, submete uma modificação e o Desenvolvedor B revisa, aprova e a modificação passa a ser código comum a ambos. Os problemas começam quando o Desenvolvedor B do nosso exemplo, não aprova a modificação do Desenvolvedor A, esse cenário ocorre seja B com maior, menor ou mesmo grau de conhecimento de A, e onde A, ao abrir sua ferramenta de revisão de código se depara com algo do tipo:

"Desenvolvedor B, solicitou que você modifique algo no código em revisão."

Seguido de uma porção de comentários em vários pontos do código, que podem evidenciar problemas em algum caso de uso, ou até mesmo um mau design (que culmina geralmente em refatoração). Essa situação de crítica em um primeiro momento pode gerar um desconforto e até questionamentos do quão bom A é como desenvolvedor. Como contribuidor de projetos de código aberto, todas as modificações que subo passam por um crivo digamos, chatinho, vejam um exemplo do que acontece com um Review rejeitado que submeti para o projeto Zephyr:

Observem no canto superior direito que os revisores negaram a entrada de um incremento que fiz na seção de arquitetura, eu coloque o resumo, mas a conversa é extensa, e pode ser acompanhada aqui. Mas dentre os principais pontos, foram encontrados estilo de código fora do padrão, a adição muito grande poderia ser dividida gerando dois reviews menores. Tirando apenas esse ponto, seria suficiente para causar um estrago emocional afinal: "Quem são esses revisores para dar pitaco no patch que deu tanto trabalho para desenvolver?". Deve ser isso o que eu, você e o Desenvolvedor A pensa ao receber uma negatva.

Mas é ai onde reside o pior erro de quem recebe a negativa, levar pro lado pessoal. Mas vamos encarar de outro modo, não acabamos de comentar que o objetivo da revisão é prover um ambiente controlado para adição de mudanças no código comum de forma mais segura? Então porque o seu revisor deve facilitar? A revisão de código tem carater preventivo, o de pegar erros que o desenvolvedor não pensou, ou que simplesmente não enxergou por estar focado em resolver o problema central que foi proposto, então da mesma forma que se revisa um texto, nada melhor que uma terceira pessoa não envolvida no problema para detecctar vícios.

Não amigo, você não é um mau desenvolvedor, não escolheu a carreira errada e tampouco seu revisor não é um cara arrogante que não gosta de você, ele está ali na posição de julgar um projeto e cada adição da forma mais pragmática possível, da mesma forma que você precisará julgar o código dele, e aprovar de primeira se estiver bom. Ou recusar se achar um problema, vamos pensar, quem gosta de corrigir bug em ambiente de produção? Corrigir um problema de pagamento em um site em pleno funcionamento é triste não? Imagina consertar o algoritmo de acelerador eletrônico de um carro por que o revisor foi bonzinho?

Por isso quando receber uma negativa ou antes de dar uma negativa para vingar-se daquele revisor chato, pense que todos trabalham por um objetivo comum, entrega com qualidade, todos querem ver o sucesso do projeto (por mais bomba e mal estimado que ele possa parecer) e ninguém, mas ninguém mesmo se sentirá confortável em corrigir aquele corner case que passou no review na base da birra. E mais importante, é somente código, não o trate como filho.

E sobre o review que foi reprovado ali em cima, não teve jeito, ele foi fechado e não entrou no mainline, mas um amigo assumiu o trabalho e mesmo corrigindo tudo ainda existem problemas de licença e a revisão fomentou a discussão sobre como os diretórios do projeto Zephyr estão organizados, discussão essa que jamais teria vindo a tona se não fosse a revisão de código e a aparente chatisse dos revisores, portanto encare revisão como algo positivo seja para aprovar, seja para reprovar ou ser reprovado!