Há pouco mais de um ano, eu deixava meu estágio em uma empresa onde trabalhava principalmente em uma plataforma low code para abraçar a oportunidade como desenvolvedor júnior em um outro lugar.
Nessa nova empreitada, pela primeira vez me deparei com uma base de código grande e complexa, nada parecida com os projetos da faculdade ou dos cursos que já havia feito até então.
Durante os primeiros meses, eu me cobrava frequentemente para ter uma compreensão maior dos projetos, do código e das regras de negócio. Foi nessa época que li o artigo How to Review Code as a Junior Developer e me mantive ainda mais firme em um hábito que começava a cultivar: fazer code overview todos os dias.
Após todo esse tempo e um pouco mais de bagagem na mochila, resolvi compartilhar um pouco da minha visão sobre tudo isso e trazer algumas das dicas do artigo traduzidas para o português. Vamos lá?
Code Evaluate é para todos?
Vira e mexe, a bolha dev do Twitter recebe uma mesma pergunta: “júnior também faz overview?”. Quem conhece a nossa bolha sabe que a mais pacífica das perguntas pode gerar a mais sangrenta das batalhas, com muitas opiniões, polêmicas e cagações de regras relatos pessoais. Para mim, no entanto, a resposta para essa pergunta deveria ser uma unanimidade: todo mundo deveria fazer code overview.
A primeira reação frente a essa ideia é questionar a viabilidade de ter alguém tão iniciante revisando código de pessoas com maior senioridade. Aqui, para mim, entra um ponto muito importante: revisar código não é apenas sobre corrigir ou necessariamente melhorar o que está sendo proposto.
Ora, se não é sobre literalmente revisar o código e torná-lo melhor, sobre o que seria?
No artigo Revisão de código é mais do que revisar código?, de 2015, Maurício Aniche apresenta os resultados de uma pesquisa feita internamente na Caelum, em que eram observadas as diferenças entre código antes e depois de revisão de código, além da própria percepção dos impactos dessa prática por parte das pessoas desenvolvedoras . O resultado é um tanto surpreendente: o code overview se mostrou muito mais eficiente na disseminação de conhecimento do que melhoria de código, embora a equipe de desenvolvedores também identifique resultados nesse sentido.
Portanto, muitas outras coisas podem ser estimuladas com a revisão de código, como a oportunidade para levantar discussões, aprender tópicos técnicos e de negócio e, de quebra, fortalecer o time e cultura.
Há controvérsias
Eu disse há pouco que, para mim, todos deveriam fazer revisão de código, mas preciso ser um pouco mais específico. Esse posicionamento faz sentido caso o time tenha escolhido utilizar pull requests em seu fluxo de trabalho. Para esse caso, toda a discussão deste texto pode ser aplicada.
No entanto, é preciso dizer que há diversos pontos negativos e potenciais desvantagens em trabalhar com pull requests e code opinions. Há sempre outras abordagens e outras visões. Como quase tudo em computação, lidamos aqui com um commerce off e devemos seguir pelo caminho que faça mais sentido para o contexto em questão.
A abordagem de trunk based development, por exemplo, advoga a favor de function branches de curta duração (dois dias, no máximo) ou mesmo de integração direta na department 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 steady integration em um mesmo fluxo, visto que integração contínua pressupõe uma interação diária de cada integrante do time com a department principal.
Dado o contraponto, sigamos com a nossa discussão.
Aprendizado e autonomia
Se você é uma pessoa experiente, com grande bagagem técnica, mas que acabou de chegar em um time, é esperado que você não tenha conhecimento da base de código e do negócio com o qual vai trabalhar. Ler pull requests, então, se mostra como uma oportunidade perfeita para aprender as modelagens e abstrações, expandir o conhecimento do código para além do domínio de suas tarefas e tirar tantas dúvidas quantas quiser.
Para isso, uma atitude é elementary: faça perguntas. Não tenha medo de julgamentos ou de parecer incompetente por isso. Da mesma forma, responda perguntas sempre que puder. Contribua para as discussões e para que esse ambiente de troca de conhecimento se mantenha fértil.
Em contato frequente com as interações que ocorrem nos pull requests, você também poderá entender quais pontos são caros para aquele time, identificar como as pessoas se relacionam e criar um sentimento de pertencimento ao time.
Agora, se você é alguém que não possui conhecimento da base de código nem tem experiência, revisar código é a oportunidade não só de alcançar tudo já mencionado até aqui, mas também um ótimo ambiente para aprender tópicos técnicos. Ao ler código de tarefas mais complexas, provavelmente você vai ver soluções, tecnologias e possibilidades com as quais você dificilmente esbarraria em outros contextos.
Como uma pessoa desenvolvedora iniciante, muitas vezes você vai “imitar” as estratégias 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 overview 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 provável que alguém sinta segurança para mudar as coisas durante os primeiros meses quando se tem uma noção maior de como tudo funciona.
Um espelho do time
A forma como code overview é 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 discussões e proporcione um ambiente seguro, o mais livre possível de opressão ou julgamentos.
Somente assim será possível colocar em prática code opinions não só como uma formalização de aceite, mas sim como um lugar propício para fazer perguntas, tirar dúvidas, discutir melhorias e perspectivas.
Para instances que trabalham de forma remota, os pull requests se mostram também como mais uma maneira de tornar informações públicas, contribuindo para o trabalho assíncrono e fortalecendo autonomia do time, no sentido de descentralização de conhecimento. Por isso, dê preferência por manter as discussões no pull request, para que outras pessoas possam ver e aprender junto. Caso as conversas tenham se dados em outro meio, vale a pena também manter um registro escrito no pull request.
Por fim, quando defendo a ideia de que todos deveriam fazer revisão de código de todos, me refiro também ao conceito de suggestions circle (ou “círculo de suggestions”), isto é, quando pessoas se propõem a estar vulneráveis entre si e ter seu trabalho à disposição para ser revisado, temos um ambiente em que se torna mais fácil tecer comentários e construir feedbacks. No mais, isso evidencia a horizontalidade do time, sem amarras rígidas de hierarquia.
O desafio de promover Code Evaluate
Como podemos ver, o simples ato de revisar código pode levar a diversas vantagens. Mas nada é tão simples nem tão fácil quanto parece, afinal estamos diante de duas tarefas bastante difíceis: promover uma cultura propícia para que o time aproveite ativamente essas oportunidades e que, principalmente, faça mais code opinions.
Esses pontos são difíceis de implementar por estarem intimamente ligados à cultura. E cultura é algo que não podemos controlar diretamente, visto que cresce e muda de forma orgânica. Colocar essas mudanças em prática pode envolver muitos outros processos.
Frequentemente, a equipe de desenvolvimento recebe uma quantidade alta de demandas e coloca seu esforço principalmente em entregar tarefas para dar vazão a esse fluxo. Nesse caso, não é difícil que os integrantes estejam constantemente em um pull request paradox.
De toda forma, é possível adotar algumas práticas e estimular alguns hábitos, como:
-
Incentivar as pessoas a fazer pull requests menores e bem documentados. Isso faz com que não só tenhamos mais likelihood de receber opinions, como também diminui o risco quando as mudanças forem para produção.
-
Possuir um guia de estilo e um guia de revisão, para que as pessoas saibam o que é válido ou não comentar em relação a estilo, formatação, nomenclatura and many others. Assim evitamos comentários repetitivos e temos um acordo já definido que deve ser seguido.
-
Tornar claro por meio dos valores do time que revisar código é parte elementary 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 segurança e perspectiva que recebe de seu segurador, o autor ou autora de um pull request tem muito a ganhar quando pode contar com outras visões e com o apoio de revisores.
Por todos os pontos mencionados aqui, acredito que code overview seja mais do que uma simples etapa do ciclo de vida das tarefas. E por esse motivo, é algo que merece atenção para ter todo seu potencial aproveitado.
Foto de capa: Via ferrata Irg2, de Maja Kochanowska.