Code Review: O que Autores e Revisores Precisam Saber?
A chave para melhorar o código é estar sempre disposto a enxergar através dos olhos dos outros... ― The Art of Readable Code", Dustin Boswell
A revisão de código, ou code review, é uma das práticas mais importantes para garantir a qualidade do software e promover o crescimento técnico da equipe. No entanto, muitas vezes, o processo pode ser visto como uma tarefa monótona ou até mesmo um campo de batalha de egos. Mas não precisa ser assim. Code reviews são, acima de tudo, uma oportunidade de colaboração e aprendizado, onde tanto o revisor quanto o autor podem crescer juntos.
Neste artigo, vamos explorar os dois papéis fundamentais no processo de revisão de código: o autor, que submete seu trabalho para avaliação, e o revisor, que é responsável por verificar a qualidade, regras de negócio, contratos e a aderência às boas práticas. Vamos abordar alguns dos principais problemas que podem surgir, como exceções não tratadas ou falhas na programação defensiva, além de destacar a importância da comunicação eficaz durante o feedback. O objetivo aqui é reforçar que o foco deve estar sempre na melhoria do código, sem personalizar ou atribuir críticas à pessoa por trás dele.
Se você já passou por uma revisão de código que não foi tão produtiva, ou se já sentiu que poderia ter dado um feedback melhor, esse artigo é para você. Vamos entender o que cada lado precisa saber para tornar esse processo mais leve, eficiente e, acima de tudo, humano.
O Papel do Autor
Você terminou de codar. Depois de horas (ou talvez dias) pensando em uma solução, o código finalmente parece estar pronto. Tudo parece funcionar, os testes passaram, e agora chegou a hora de enviar sua obra para a revisão de código. Mas será que está mesmo pronto?
Na indústria de software, é comum os desenvolvedores seguirem um caminho rotineiro: começam a trabalhar em uma feature, escrevem código, testam e, finalmente, submetem o resultado no repositório. Esse ciclo pode ser automático, quase sem que a gente perceba. Aquele velho "git commit, git push" já se tornou parte do fluxo diário. Mas, em meio à repetição, será que estamos sempre parando para refletir sobre a qualidade do que estamos enviando? Ou estamos apenas querendo "fechar mais uma tarefa"?
Steve McConnell, em "Code Complete", escreveu que "programar é uma atividade solitária, mas o código pertence à equipe". Isso é algo que muitas vezes esquecemos como autores de código. Trabalhamos sozinhos em nossas máquinas, mas o código que escrevemos não será mantido apenas por nós. Ele será lido, interpretado, modificado, e ampliado por outras pessoas.
Vamos pensar no passo a passo comum: você escreve o código, revisa rapidamente (ou nem tanto), executa alguns testes unitários, garante que a funcionalidade está funcionando conforme o esperado, e aí, pronto. O código vai para o repositório e você abre uma Pull Request (PR). Nesse momento, algo dentro de você já está aliviado. “Acabou!” – você pensa. Mas será que essa pressa de enviar o código para revisão está nos impedindo de fazer uma autoavaliação mais profunda?
Autoria de código é algo delicado. Assim como escritores revisam seus textos antes de publicá-los, desenvolvedores também devem pensar no impacto de suas criações. Contudo, é fácil cair na armadilha da rotina: estamos ocupados, há prazos, e quanto mais rápido o código é aprovado, mais rápido podemos passar para a próxima tarefa. E é aí que muitos de nós, autores de código, caímos na cilada de “só mais uma PR”.
Essa prática rotineira é algo natural, mas também pode ser perigosa. Afinal, o que escrevemos é muito mais do que um conjunto de instruções para o computador. É uma peça do quebra-cabeça maior do sistema, que precisa estar em harmonia com outras partes e ser compreendida pelos seus colegas.
Daqui a pouco, vamos convesar mais a fundo para o papel do revisor. Mas, por enquanto, vamos parar para refletir: como você, no papel de autor, tem enviado seu código para revisão? Está realmente pronto ou você está apenas seguindo o fluxo?
Esse é o momento de pensar sobre o impacto de sua criação, afinal, todos nós escrevemos código e já estivemos do outro lado. E, claro, sabemos que a pressa ou a rotina podem muitas vezes tirar a profundidade desse processo.
Reagindo a Comentários Na PR
Quando o código é enviado para revisão, o autor não apenas abre uma Pull Request; ele também abre as portas para o feedback. E feedback nem sempre é fácil de lidar, especialmente quando envolve questionamentos à implementação de uma funcionalidade, à estrutura do código, ou até mesmo a uma escolha de variáveis de ambiente. Nesse momento, muitos desenvolvedores sentem um desconforto natural — afinal, ver algo que você escreveu ser questionado pode parecer, à primeira vista, um ataque ao seu trabalho.
Mas vamos colocar isso em perspectiva. O que o revisor está avaliando não é a sua capacidade como desenvolvedor, mas sim o código em si. Isso pode parecer estranho à primeira vista, afinal, como desenvolvedor, sua principal função é escrever código, certo? No entanto, o foco da revisão de código não é avaliar o seu valor como profissional, mas sim garantir que o código que está sendo submetido atenda aos padrões de qualidade, seja legível e esteja alinhado às necessidades do projeto.
A essência aqui é que a revisão de código é um processo colaborativo. O revisor está ali para oferecer uma nova perspectiva, ajudar a identificar possíveis problemas, e, acima de tudo, melhorar o código. Como você reage a esses comentários faz toda a diferença no resultado final.
Algumas vezes, o comentário do revisor pode ser técnico: "Você tratou todas as exceções possíveis aqui?" ou "Será que essa variável de ambiente está acessível em todos os contextos de execução?" Outras vezes, pode ser algo mais amplo, relacionado à regra de negócio: "Essa abordagem contempla todos os cenários que discutimos com o time?" Nessas horas, a reação imediata pode ser de defensiva. É humano querer proteger o que criamos, mas o papel do autor vai além de apenas subir código e correções sugeridas pelo revisor.
A verdade é que o processo de revisão de código deve ser visto como uma conversa. Isso envolve um passo que, muitas vezes, é negligenciado: explicar o contexto. O revisor, por mais experiente que seja, nem sempre terá o mesmo nível de familiaridade com o que você está trabalhando naquele momento. É aqui que o autor se destaca ao oferecer clareza.
Explicar o contexto não é sobre defender cegamente suas escolhas, mas sim oferecer uma visão de por que determinadas decisões foram tomadas. Se o revisor questiona uma abordagem específica, como um padrão de projeto ou uma integração com um serviço externo, o autor deve explicar como chegou a essa solução. Talvez você tenha considerado alternativas, mas optou por essa abordagem devido a uma limitação técnica ou de prazo. Essa conversa enriquece o processo, tornando-o mais colaborativo.
Outro aspecto crucial que muitas vezes passa despercebido é a capacidade do autor de buscar melhorias ativamente. Um comentário do revisor não precisa ser visto como uma sentença definitiva. Se um ponto é levantado, como um potencial impacto em outra área do sistema, é uma oportunidade de revisar, não apenas a linha ou bloco de código mencionado, mas o impacto geral daquela alteração. Há algum comportamento inesperado que pode emergir em outro serviço ou algum risco de performance que não foi considerado?
O autor tem a responsabilidade de pensar além do que está sendo pedido. Não é só aplicar correções sugeridas e seguir em frente. É entender o sistema como um todo e analisar os efeitos colaterais da mudança. Se o feedback do revisor levanta uma dúvida sobre como uma parte do código pode afetar outra, o autor deve usar essa oportunidade para investigar um pouco mais a fundo, explorar potenciais melhorias e, se possível, propor soluções que vão além do que foi solicitado. Isso transforma o code review em um processo muito mais rico e benéfico.
E há uma citação de Robert C. Martin em "Clean Code" que se encaixa perfeitamente: "Código limpo é como uma história bem escrita. Ele faz com que os leitores entendam seu propósito com facilidade, sem esforço." Isso nos lembra que o papel do autor na revisão de código vai além de simplesmente garantir que funcione. Ele deve focar em comunicar suas intenções com clareza, tanto para o revisor quanto para futuros desenvolvedores que precisarão entender e manter esse código.
Comunicando-se Melhor com o Revisor
Depois de receber feedback sobre o código, o próximo passo é a comunicação. O processo de code review é visto também como uma colaboração e a forma como você, como autor, se comunica pode determinar a eficácia dessa colaboração. Não se trata apenas de corrigir o código de acordo com o que o revisor apontou, mas sim de engajar em uma conversa produtiva sobre as escolhas técnicas e o impacto das alterações. Especialmente para programadores iniciantes, entender como essa troca de ideias funciona pode transformar o code review em uma das ferramentas mais poderosas de aprendizado.
Para muitos desenvolvedores iniciantes, é comum o pensamento de que o objetivo principal da revisão é simplesmente “passar” ou “ter o código aprovado”. Mas, na verdade, é muito mais do que isso. O code review é uma oportunidade para entender melhor o código, as decisões técnicas, e aprimorar suas habilidades de comunicação.
Passos para Melhorar a Comunicação com o Revisor
Seja Transparente com Suas Decisões: Quando enviamos código para revisão, ele é apenas uma parte de um quebra-cabeça maior. É fácil para o revisor perder de vista o contexto completo, especialmente se estiver lidando com múltiplas revisões simultaneamente. Explicar o “porquê” de suas decisões pode fazer toda a diferença. Se você optou por uma abordagem específica, forneça o raciocínio por trás dela. Por exemplo, se você escolheu usar um determinado algoritmo por causa de uma restrição de performance ou um detalhe de negócio, essa explicação ajuda o revisor a entender o contexto.
Programadores iniciantes podem se sentir inseguros ao explicar suas decisões, mas lembre-se de que isso é importante para seu desenvolvimento profissional. O ato de justificar suas escolhas revela seu pensamento crítico e abre espaço para uma discussão mais rica, onde você pode tanto defender suas ideias quanto aprender com as alternativas sugeridas.
Faça Perguntas: É fácil sentir-se vulnerável ao receber feedback, mas não tenha medo de fazer perguntas ao revisor. Se ele sugerir uma mudança que você não entende completamente, pergunte o porquê da sugestão. Muitos programadores iniciantes ficam receosos de parecerem inexperientes ao questionar decisões, mas a verdade é que perguntas bem feitas demonstram interesse genuíno no aprendizado. Entender por que uma determinada abordagem é melhor do que outra é o que irá, no final das contas, melhorar suas habilidades como desenvolvedor.
Perguntas também podem ajudar a esclarecer quando o comentário em algum trecho está confusa ou vaga. Se um revisor diz "Isso pode ser mais eficiente", mas não fornece detalhes, peça mais contexto: "Você pode me ajudar a entender onde posso melhorar a eficiência aqui?"
Pense no Sistema como um Todo: É muito comum, especialmente no início da carreira, focar no que está diretamente à frente: a funcionalidade ou o módulo que estamos desenvolvendo. No entanto, um passo importante para melhorar sua comunicação com o revisor é mostrar que você compreende o impacto do seu código no sistema como um todo. Antes de enviar sua Pull Request, pense: "Como essa alteração afeta outras partes do sistema? Existem efeitos colaterais que eu posso não ter considerado?" Isso demonstra que você está pensando além do código imediato e está preocupado com a integridade e a robustez do sistema.
Se você perceber durante a revisão que um comentário levanta uma questão que pode afetar outras áreas, aproveite para engajar nessa conversa. Isso eleva o nível da discussão e faz você se destacar como alguém que está pensando à frente. Além disso cria a oportunidade para você conhecer outras áreas dentro da empresa.
Explique as Limitações: Nem sempre temos o luxo de fazer tudo com as melhores práticas ou da maneira ideal. Às vezes, prazos apertados ou limitações de tecnologia nos forçam a escolher soluções menos ideais, pelo menos temporariamente. Quando isso acontece, explicar essas limitações ao revisor pode ser útil. Ao fazer isso, você reconhece os pontos fracos do seu código, mas também demonstra que você está ciente deles e disposto a revisitar esses pontos no futuro.
Por exemplo, se uma solução foi implementada com uma performance abaixo do ideal devido a uma restrição de tempo, mencione isso. "Eu implementei essa solução como uma medida temporária, pois tínhamos um prazo, mas estou aberto a revisitar isso na próxima entrega. Consegue me orientar? Podemos conversar em breve?"
Um Conselho Para os Iniciantes
Se você está começando sua jornada na programação, o code review pode parecer um processo intimidador. Mas, na realidade, é uma ferramenta valiosa para o seu crescimento. Cada revisão é uma oportunidade de absorver conhecimento da equipe e de entender como decisões técnicas são feitas. Não encare as revisões como uma simples barreira para a aprovação do seu código. Veja-as como uma chance de aprender, de questionar e de melhorar suas habilidades.
Seja transparente com suas decisões, pergunte quando algo não estiver claro, e, acima de tudo, mantenha a mente aberta. Lembre-se de que o code review é sobre colaboração, e quanto mais você se comunicar de forma clara e eficiente, mais fácil será esse processo.
Com o tempo, você verá que essas interações vão moldar não só o seu código, mas também a sua maneira de pensar como programador.
O que um Autor Jamais Deve Fazer
Ao entrar no processo de revisão de código, o autor deve entender que esse não é um momento ruim, mas uma oportunidade de aprendizado e evolução. Todos nós, em algum momento, caímos na armadilha de querer "só passar" pelo processo de revisão, como se fosse uma etapa burocrática. Mas isso, além de ser uma abordagem limitada, também desperdiça a chance de crescer como desenvolvedor.
Uma coisa que o autor deve evitar é ficar na defensiva. Quando você recebe comentários ou questionamentos sobre o seu código, especialmente de alguém mais experiente, pode ser tentador justificar cada decisão técnica de maneira rígida. Porém, a verdade é que ser receptivo ao feedback é uma das maiores habilidades que você pode desenvolver. No livro "The Art of Readable Code", Dustin Boswell explica isso de forma clara: "A chave para melhorar o código é estar sempre disposto a enxergar através dos olhos dos outros. Respostas defensivas bloqueiam o progresso e dificultam a colaboração." Abrir-se para a perspectiva de outro desenvolvedor pode trazer insights que você não havia considerado.
Outro ponto que pode ser delicado para autores iniciantes é o reconhecimento de que não existe código perfeito. Steve McConnell, em seu livro "Code Complete", nos lembra: "Não existe código perfeito, apenas código em constante melhoria." Ter essa mentalidade permite que você veja cada revisão como uma etapa de aprimoramento, não como uma corrida para a aprovação. Isso também exige humildade para aceitar que, por mais que seu código funcione, ele pode sempre ser melhorado — seja em legibilidade, performance ou até em manutenibilidade. E tudo bem, porque o objetivo é crescer e fazer o sistema evoluir junto.
Agora, pensando em como evitar erros comuns, é importante lembrar que um PR sem contexto é como uma conversa sem começo. Deixar o revisor no escuro é frustrante, tanto para ele quanto para você. Um commit com a mensagem "Correções" não diz nada sobre o que foi feito ou por que foi feito. Da mesma forma, uma Pull Request que simplesmente mostra um monte de mudanças sem uma explicação adequada dificulta o trabalho do revisor.
Isso não só demonstra que você está envolvido no processo, mas também que está pensando além do que é óbvio.
Manter uma postura segura e humilde é outro aspecto fundamental. A segurança vem do fato de que você sabe o que fez e pode explicar suas decisões, mas a humildade permite que você reconheça quando algo pode ser melhorado. O equilíbrio entre essas duas qualidades faz com que a colaboração flua naturalmente. Quando você se abre para a possibilidade de mudança, o revisor também se sente mais inclinado a discutir soluções ao invés de simplesmente apontar erros. O foco deve ser sempre em melhorar o código, e não em provar quem está certo ou errado.
O processo de code review não precisa ser uma batalha entre egos, nem um obstáculo a ser superado. Ele pode ser uma rica troca de ideias, onde todos aprendem algo novo e o código se torna melhor a cada iteração. Ao manter uma postura aberta, fornecer contexto e aceitar feedback de maneira construtiva, o autor transforma o code review em uma oportunidade de crescimento — tanto para o código quanto para ele mesmo como desenvolvedor.
Por fim, lembre-se sempre de que ninguém está sozinho nesse processo. O código que você escreve será lido e mantido por outros desenvolvedores, e as revisões de código são uma parte essencial dessa jornada colaborativa.
5 Perguntas que o Autor Deve se Fazer Antes de Abrir uma PR:
Minha Pull Request tem um escopo claro e bem definido?
Certifique-se de que a PR se concentra em uma tarefa ou feature específica.
Expliquei o contexto da alteração de forma clara na descrição?
Adicione uma descrição que explique o que foi feito e o porquê, incluindo prints ou logs, se necessário.
Meus commits estão bem estruturados e com mensagens claras?
Cada commit deve ter uma mensagem que descreva exatamente o que foi alterado.
Considerei possíveis exceções e impactos no sistema como um todo?
Pense nas consequências da alteração em outras partes do sistema e trate exceções adequadamente.
Fiz uma revisão no código antes de enviá-lo?
Revise seu código e testes antes de abrir a PR, evitando erros simples.
5 Perguntas que o Autor Deve se Fazer Depois de Abrir uma PR e Receber Comentários:
Entendi os comentários do revisor completamente?
Se algo não estiver claro, peça explicações antes de tomar qualquer ação.
Estou sendo defensivo ou aberto às sugestões?
Avalie se você está aceitando o feedback de forma construtiva.
Existe algo que posso melhorar além do que foi apontado?
Use os comentários como um ponto de partida para explorar melhorias adicionais.
Expliquei minhas decisões de maneira adequada onde necessário?
Se você tomou uma decisão consciente que foi questionada, explique com clareza seu raciocínio.
Essa mudança vai realmente melhorar o código e o sistema?
Reflita se as mudanças sugeridas (ou suas próprias melhorias) fazem sentido para o objetivo final da funcionalidade.
Essas perguntas ajudam bastante, principalmente a garantir um processo de code review mais fluido e colaborativo.
Agora chegou o momento de falar com os revisores de código.
O Papel do Revisor
Eu também sou um autor de código, mas também faço meu papel como revisor de código. Eu também preciso melhorar! Então vamos conversar bastante sobre esse papel importante e os ajustes que talvez precisamos fazer.
Quando uma PR é aberta, o revisor tem uma responsabilidade que vai além de simplesmente aprovar ou rejeitar o código. Não se trata apenas de verificar se o código funciona. Como revisor, você está ajudando a moldar a saúde do código (do software) a longo prazo.
É comum que, com a correria do dia a dia, o revisor sinta a tentação de aprovar rapidamente uma PR, sem considerar todas as implicações. No entanto, o papel do revisor exige atenção aos detalhes. Não basta verificar se o código executa corretamente — é essencial pensar nos impactos de longo prazo, nos possíveis efeitos colaterais e na clareza para outros desenvolvedores que trabalharão com aquele código no futuro.
Além disso, a forma como o feedback é dado é tão importante quanto o conteúdo. Revisores que utilizam sarcasmo, deboche ou arrogância minam a confiança e a colaboração no time. Um dos grandes riscos é transformar o code review em um momento de crítica pessoal, quando, na verdade, deveria ser focado no código, não no autor. O revisor tem a chance de transformar o feedback em uma oportunidade de aprendizado e crescimento, mantendo sempre uma comunicação clara, direta e respeitosa.
Ser um bom revisor também significa não apenas apontar problemas, mas propor soluções. Se você identificou algo que pode ser melhorado, apenas a pontar o problema não ajuda. Sugerir uma alternativa ou oferecer um caminho possível é uma atitude que realmente agrega valor. O feedback construtivo precisa vir acompanhado de possibilidades de melhoria.
Outro ponto é que o revisor precisa entender o contexto da alteração. Antes de avaliar cada linha de código, pergunte a si mesmo: "Eu entendo o que está sendo proposto aqui?" Se o contexto não estiver claro, é importante solicitar mais informações antes de sugerir mudanças. Um bom revisor também reconhece que o processo não é uma disputa de conhecimento ou superioridade. A revisão de código não é um momento para mostrar que você sabe mais, mas para colaborar com o autor e garantir que o código atenda aos padrões de qualidade.
A revisão de código é, portanto, uma construção conjunta, onde tanto o revisor quanto o autor têm um papel ativo. O que o revisor aprova reflete não apenas a qualidade do código, mas a maturidade e a colaboração da equipe como um todo. Como disse Kent Beck: "Otimizo o time primeiro, depois o código" .
Não Seja um Babaca!
Uma coisa que precisamos entender, especialmente conforme avançamos na carreira como desenvolvedores, é que ser excelente tecnicamente não é o bastante. Se você é o tipo de programador sênior que acredita que a revisão de código é um momento para mostrar superioridade, ou que usa o processo para derrubar o trabalho de colegas com comentários arrogantes, então é hora de refletir. A engenharia de software é muito mais sobre colaboração, comunicação e respeito pelas pessoas com quem você trabalha do que sobre escrever linhas de código.
Titus Winters, em seu livro "Engenharia de Software no Google: Lições Aprendidas com a Programação ao Longo do Tempo", captura perfeitamente essa ideia ao dizer: “Em um ambiente profissional de engenharia de software, a crítica quase nunca é pessoal - geralmente é apenas parte do processo de fazer um projeto melhor. O truque é garantir que você (e aqueles ao seu redor) entendam a diferença entre uma crítica construtiva da produção criativa de alguém e um ataque direto ao caráter de alguém."
E esse é o ponto: o code review não é um ataque ao caráter do autor. Ele deve ser uma oportunidade de melhorar o código, o sistema e o próprio autor. Quando você decide fazer comentários sarcásticos, agressivos ou tenta provar que está certo a qualquer custo (principalmente quando não está), o que você está realmente fazendo é minando a confiança e criando um ambiente tóxico. O que adianta ser tecnicamente excelente se seus colegas evitam discutir ideias com você? Se a sua presença no time gera desconforto? A maneira como você se comunica pode ser o fator determinante entre um time de sucesso e um time que trabalha sob tensão constante.
Winters ainda complementa: “Este último (ataques ao caráter) é inútil - é mesquinho e quase impossível de agir. O primeiro (crítica construtiva) pode (e deve!) ser útil e dar orientação sobre como melhorar. E, o mais importante, é imbuído de respeito: a pessoa que faz a crítica construtiva realmente se importa com a outra pessoa e quer que ela melhore a si mesma ou seu trabalho." Essa é a essência de uma boa revisão de código: o respeito mútuo, o desejo genuíno de ajudar o outro a crescer e, consequentemente, fazer com que o projeto evolua.
Outra voz importante nesse debate é Ben Collins-Sussman, coautor de "Team Geek: A Software Developer's Guide to Working Well with Others". Ele afirma: “O melhor software é construído por equipes que se comunicam bem. Se você é o programador mais habilidoso do mundo, mas não consegue trabalhar bem com outros, então seu impacto no projeto será limitado.” Esse comentário é um lembrete de que o verdadeiro sucesso na engenharia de software vem da colaboração. E essa colaboração só pode crescer em um ambiente onde as pessoas se sentem seguras para compartilhar suas ideias e aprender umas com as outras.
Então, a próxima vez que você estiver revisando um código, pergunte-se: Estou realmente contribuindo para o crescimento do autor e para o bem-estar da equipe? Se sua resposta for não, talvez seja hora de reavaliar a forma como você está lidando com o processo. Porque, no final das contas, não importa quão habilidoso você seja tecnicamente se a sua maneira de agir faz com que seus colegas se afastem ou sintam-se desvalorizados por causa de suas péssimas atitudes!
Um bom revisor faz perguntas objetivas, guia os iniciantes, propõe soluções, explica o porquê das mudanças e, acima de tudo, ajuda o time a crescer junto. Por isso, não seja um babaca, colabore com todos!
Se você se vê agindo dessa forma, está na hora de mudar. Revisões de código não são um palco para o ego, mas sim uma oportunidade de colaborar, aprender e construir algo que tenha valor, tanto para o sistema quanto para as pessoas. A engenharia de software é, antes de mais nada, sobre pessoas.
Como um Revisor Pode Garantir a Qualidade Durante o Code Review?
Quando o autor do código já forneceu o contexto necessário para a revisão, o trabalho do revisor começa a se aprofundar. Nesse momento, o olhar técnico e atento do revisor precisa ser aplicado de maneira cuidadosa para garantir que o código não apenas funcione, mas que esteja robusto, alinhado com as regras de negócio e livre de problemas que possam surgir de maneira inesperada.
Um dos pontos centrais para qualquer revisor é a aderência às regras de negócio. Elas são a espinha dorsal do sistema, o que significa que qualquer desvio ou erro na implementação pode gerar grandes problemas. O revisor deve garantir que as regras estão sendo corretamente aplicadas, que estão sendo testadas de forma clara e que não existem ambiguidades. Além disso, é importante verificar se o código lida corretamente com cenários onde a regra pode ser violada ou não atendida. Por exemplo, se uma determinada condição é essencial para o funcionamento correto da aplicação, o que acontece se essa condição não for cumprida? Estamos garantindo o tratamento adequado? Ou estamos deixando um caminho aberto para erros futuros?
Outro ponto crucial é a análise de exceções. Um bom revisor não olha apenas para a lógica feliz — aquela onde tudo funciona conforme esperado. Ele deve buscar cenários em que algo possa sair errado: exceções não tratadas, caminhos de erro que não foram cobertos, ou mesmo a ausência de lançamentos apropriados de exceção. O código que falha silenciosamente, sem fornecer feedback adequado sobre o erro, pode se transformar em um pesadelo quando o problema aparecer em produção. É por isso que verificar se as exceções estão sendo lançadas nos momentos corretos e, mais importante, se estão sendo tratadas de forma adequada, é fundamental.
Além disso, devemos prestar muita atenção a possíveis null pointers e variáveis mal inicializadas. Quantas vezes já nos deparamos com bugs de runtime causados por um simples valor null inesperado? Durante o code review, o revisor precisa ter um olhar afiado para identificar onde as variáveis podem não ter sido inicializadas corretamente, ou onde existe o risco de uma variável receber um valor inesperado que, no momento da execução, gera um comportamento imprevisível. Esse tipo de bug muitas vezes passa despercebido durante a fase de desenvolvimento, mas um olhar cuidadoso pode preveni-los antes que cheguem à produção.
Um exemplo clássico é quando uma função espera um valor não-nulo, mas o código não garante isso de forma explícita. Pergunte-se: "Onde está o ponto de falha aqui? E se essa variável for null? O que acontece se esse valor não for inicializado antes de ser utilizado?" O revisor precisa fazer essas perguntas o tempo todo, e mais importante, precisa verificar se o código já está prevenindo esses cenários. Quando falamos de variáveis mal inicializadas ou não inicializadas, estamos lidando com um risco real de undefined, algo que, se não for tratado no início, pode resultar em problemas difíceis de rastrear mais tarde.
Ignorar esses cenários abre portas para comportamentos inesperados e falhas que podem ser catastróficas em produção.
Quebras de Contrato: Atenção Redobrada em API’s
Outro aspecto crucial durante o code review, especialmente em corporações que seguem princípios como API First, é estar atento a possíveis quebras de contrato. APIs são o ponto de contato entre diferentes serviços e sistemas, e qualquer mudança que quebre o contrato estabelecido pode gerar falhas em cascata em diversas partes do sistema.
Se o código alterado afeta uma API — seja diretamente ou indiretamente — o revisor precisa garantir que o contrato da API está sendo respeitado. Uma quebra de contrato acontece quando mudanças são feitas na API (por exemplo, na estrutura de resposta, nos parâmetros de entrada, ou no comportamento esperado) que não são compatíveis com as versões anteriores. Isso pode levar a falhas em qualquer cliente que dependa dessa API, o que pode ser um risco grave em sistemas de produção.
Alguns pontos que o revisor deve verificar:
Mudanças na Estrutura de Dados: A estrutura do retorno da API mudou? Novos campos foram adicionados ou removidos? Como isso afeta os consumidores dessa API? Verificar se mudanças são compatíveis com versões anteriores é fundamental para evitar que clientes que já utilizam a API quebrem após a atualização.
Mudanças em Regras de Negócio Expostas: A API aplica alguma regra de negócio que foi alterada? Essas mudanças afetam a lógica dos consumidores? Qualquer alteração nesse sentido precisa ser documentada e, se possível, compatibilizada com a versão anterior da API.
Tratamento de Exceções e Erros: Verificar se a API continua tratando os erros corretamente e fornecendo feedback adequado aos seus consumidores. Por exemplo, se antes ela lançava um código de erro 400 para entradas inválidas, certifique-se de que isso ainda está funcionando da mesma forma após as mudanças.
Seguir o API First significa que a API é desenhada e documentada antes de qualquer implementação interna ser feita. Portanto, qualquer mudança no código que possa afetar essa API precisa ser cuidadosamente revisada e validada para garantir que não haverá quebras que possam prejudicar outros serviços e equipes que dependem dela.
No próximo tópico, vamos falar sobre como a programação defensiva se encaixa nesse processo, e como ela pode ser uma poderosa aliada para minimizar riscos e falhas.
Como o Revisor Pode Orientar um Código que Precisa de Programação Defensiva?
Imagine que você está revisando uma funcionalidade que foi desenvolvida rapidamente. O autor fez o melhor que pôde dentro do tempo que tinha, mas é claro que existem pontos frágeis no código — talvez o tratamento de exceções esteja incompleto, ou os cenários de erro não estejam adequadamente cobertos. O primeiro passo para um revisor é reconhecer a urgência que o autor teve. Comentar algo como: "Eu entendo que essa funcionalidade precisava ser entregue rapidamente, mas podemos adicionar algumas verificações para garantir que o código esteja mais resiliente a falhas?" pode ser uma forma de introduzir o tema sem parecer um ataque ou uma crítica ao esforço do autor.
Um aspecto importante da programação defensiva é fazer o autor refletir sobre cenários que ele pode ter deixado passar, especialmente quando há pressa. Uma forma eficaz de estimular essa reflexão é fazendo perguntas abertas que incentivem o autor a pensar de forma mais ampla sobre possíveis falhas no código. Comentários como: "Legal essa implementação, mas estamos considerando que esse campo pode ser nulo?" ou "Show essa solução! É possível adicionar uma verificação de nulo antes, ou já estamos tratando isso de outra maneira?" ajudam o autor a perceber as áreas onde a programação defensiva pode ser aplicada, sem que isso soe como uma crítica direta.
Outro ponto essencial é oferecer sugestões práticas. Não basta apenas dizer "isso precisa de programação defensiva". O revisor deve ser específico e mostrar onde as melhorias podem ser feitas. Por exemplo, ao encontrar um trecho onde há uma dependência de uma variável externa, o revisor pode comentar: "Aqui seria interessante verificar se essa variável foi corretamente inicializada antes de utilizá-la, para evitar erros de runtime." Dessa forma, o feedback não só alerta para o problema, mas também mostra o caminho para resolvê-lo.
Em situações onde há prazos apertados, a maneira como sugerimos programação defensiva também importa. Se o autor já está sob pressão, o ideal é apresentar essas sugestões como parte de um ciclo contínuo de melhoria. Algo como: "Entendo que o prazo foi curto para essa entrega, mas que tal adicionarmos uma verificação extra nas próximas sprints? Isso pode evitar erros futuros e tornar o código mais robusto." Aqui, o revisor está reconhecendo a limitação de tempo e propondo uma melhoria gradual, sem sobrecarregar o autor.
O revisor pode sugerir pequenas mudanças que, somadas, aumentam significativamente a segurança do código. Perguntas como: "Será que não estamos ignorando alguma entrada inesperada? Por exemplo uma string com caracteres especiais poderia quebrar a jornada? Se quiser me ligar podemos nos reunir brevemente para ver isso, o que acha?" são formas de criar um diálogo aberto e colaborativo entre revisor e autor.
Ao fazer essas perguntas, o revisor não apenas aponta possíveis áreas de melhoria, mas se coloca à disposição para ajudar a resolver essas questões. Isso mostra uma postura proativa e uma atitude de parceria, onde o revisor não está apenas analisando o código de maneira crítica, mas se oferecendo para colaborar na solução.
Se colocar no lugar do outro é fundamental nesse processo. Imagine estar sob pressão para entregar rapidamente uma funcionalidade e, ao receber a revisão, em vez de críticas duras ou isoladas, você recebe uma oferta de ajuda para resolver os problemas de forma mais eficaz. Isso humaniza o processo e cria um ambiente onde o autor se sente mais seguro para ajustar o código sem o peso de julgamentos.
E claro, essas são apenas sugestões! Cada time pode aderir ou não a essas práticas, e não são regras absolutas. Alguns times podem preferir abordagens diferentes, dependendo de suas prioridades e estilo de trabalho. O importante é encontrar o que funciona melhor para o seu time e construir um ambiente de confiança e melhoria contínua.
O Revisor Ajuda na Qualidade dos Testes
Um outro aspecto importante que o revisor precisa observar durante o code review são os testes que acompanham o código. Muitas vezes, autores menos experientes podem não ter a mesma atenção ou compreensão sobre a importância de testes bem estruturados e que realmente cubram os cenários necessários. Aqui, o papel do revisor é essencial para garantir que o código seja não apenas funcional, mas também testado de maneira adequada.
É importante verificar não apenas a existência dos testes, mas a qualidade deles. Por exemplo, o teste cobre os cenários críticos? Existe alguma validação para entradas inesperadas ou valores limites? Testes apenas para os "caminhos felizes" podem dar uma falsa sensação de segurança, e o revisor tem a responsabilidade de garantir que os testes também considerem possíveis falhas ou comportamentos inesperados. Um bom ponto de partida é perguntar ao autor: "Esses testes estão cobrindo todos os cenários esperados? Será que podemos adicionar mais algum teste para um caso extremo ou entrada inválida?"
Outro ponto é incentivar os autores menos experientes a refletir sobre a qualidade dos testes, e não apenas sobre sua quantidade. Muitas vezes, a cobertura de código pode ser alta, mas os testes em si podem ser superficiais. O revisor pode ajudar comentando: "Você acha que esse teste captura bem os casos em que a funcionalidade pode falhar? Há algum comportamento inesperado que deveríamos verificar? Por exemplo, por que não escrevemos um cenário de teste para esse caso… (propor cenário)" Essa abordagem não apenas melhora o código, mas também ajuda o autor a desenvolver uma mentalidade de testes mais sólida.
Para autores menos experientes, um dos maiores aprendizados pode ser a criação de bons testes unitários e de integração, e o revisor pode desempenhar um papel de mentor nesse aspecto. Ao invés de criticar a ausência ou fragilidade dos testes, o revisor pode sugerir exemplos de como um teste bem pensado poderia cobrir um cenário específico, criando uma oportunidade de aprendizado sem sobrecarregar o autor.
Testes são a linha de defesa que previne muitos problemas em produção, e o revisor pode ser aquele que ajuda a elevar a barra de qualidade do time. Portanto, ao revisar o código, lembre-se: o código pode estar funcionando, mas os testes garantirão que ele continue funcionando mesmo quando as coisas mudarem.
Ufa! Quanta coisa um revisor precisar estar atento e olha que infelizmente não vamos cobrir todos os assuntos que eu gostaria de comentar neste artigo. Mas se ficou alguma dúvida ou se você não concorda com qualquer coisa, deixe um comentário e vamos conversar sobre isso!
5 Perguntas que o Revisor Deve se Fazer Antes de Olhar uma PR:
Eu compreendo o contexto da funcionalidade ou alteração que estou revisando?
Procure entender a história e os requisitos antes de iniciar a revisão.
Quais são os objetivos principais dessa PR?
Entender claramente o que está sendo alterado ou adicionado evita confusões e comentários desnecessários.
O que essa funcionalidade impacta no sistema como um todo?
Pense em como a mudança interage com outras partes do sistema, e se há áreas que podem ser afetadas.
Estou preparado para revisar com um olhar imparcial e construtivo?
Verifique sua postura para garantir que o feedback seja produtivo e sem tons agressivos ou pessoais.
Tenho tempo suficiente para fazer uma revisão de qualidade?
Uma revisão apressada pode deixar passar detalhes importantes. Reserve um tempo adequado.
5 Perguntas que o Revisor Deve se Fazer Durante o Processo de Code Review de uma Funcionalidade:
Esse código está atendendo corretamente às regras de negócio?
Verifique se as regras de negócio foram implementadas de forma clara e se estão refletidas no código.
Existem exceções ou cenários de erro bem tratados?
Observe se o código está preparado para lidar com exceções e cenários inesperados.
Os testes cobrem os cenários mais críticos e casos extremos?
Avalie a qualidade dos testes. Eles cobrem entradas inválidas ou situações limites?
O código é legível e fácil de entender?
Pergunte-se se o código é fácil de seguir. Outros desenvolvedores conseguirão mantê-lo no futuro?
Há alguma área que poderia se beneficiar de programação defensiva?
Considere se existem pontos onde a programação defensiva pode fortalecer a robustez da funcionalidade.
Essas são só algumas das várias perguntas que podem ajudar o revisor a se preparar e a conduzir uma análise mais cuidadosa e completa, garantindo que a PR atenda aos padrões de qualidade do time e do sistema. Cada projeto tem seus próprios padrões e principios a serem seguidos, pode ser que a equipe trabalhe com conceitos como Arquitetura Hexagonal, Arquitetura Limpa, Principios SOLID, Patterns entre outros. Seria legal escrever perguntas para você 🫵🏻 revisor analisar antes de colocar qualquer tipo de comentário em uma PR. Por isso analise seu contexto e entenda o que faz sentido e o que não faz!
Conclusão!
O code review é muito mais do que apenas uma etapa técnica no desenvolvimento de software. Ele é uma oportunidade única de aprendizado contínuo, melhoria de qualidade e fortalecimento da colaboração dentro da equipe. Para os autores, isso significa ter a abertura para receber feedback de forma construtiva, enxergando as críticas como uma chance de refinar suas habilidades e elevar o padrão do código. Para os revisores, é importante lembrar que seu papel não é apenas identificar erros, mas guiar o autor no caminho das melhores práticas, com empatia e clareza.
Quando bem conduzido, o code review transforma o processo de desenvolvimento em uma troca rica, onde todos saem ganhando: o código fica mais robusto, as equipes crescem em conhecimento e o produto final ganha em qualidade e confiabilidade. Afinal, o objetivo não é só fazer com que o código funcione, mas sim garantir que ele seja sustentável, claro e escalável. E isso só é possível quando autores e revisores trabalham juntos, com o objetivo comum de entregar o melhor resultado possível.
Lembre-se: code review é uma ferramenta poderosa. Use-a com sabedoria e empatia, e veja como isso pode moldar tanto seu código quanto sua carreira.