Dicas para revisão de código com garantia de qualidade e manutenção da amizade 🤝

Published in

Livelo

19 min readMay 17, 2023

Um aspecto fundamental no desenvolvimento de software, além da escrita do código em si, é o processo de revisão de código por pares. O objetivo nessa prática é garantir a qualidade do produto através de uma verificação adicional por outras pessoas sobre o código antes dele avançar no processo de integração até o ambiente produtivo.

A origem dessa etapa de verificação vem de projetos de código aberto, que permitem a contribuição de pessoas desconhecidas ao redor do mundo. Diante desse cenário, foram criados mecanismos de governança para garantir que o código integrado nas branches principais sejam de alta qualidade.

Na prática, você pode conhecer o mecanismo como Pull Request (PR) ou Merge Request (MR). Neste artigo, será utilizado o acrônimo "PR" , mas cada organização pode utilizar uma nomenclatura diferente.

A iniciativa privada também viu valor nesse mecanismo para garantir a qualidade do código em seus repositórios. Portanto, existem estratégias alternativas para projetos privados, como dar a liberdade de optar por revisão antes de seguir a esteira de entrega. Na estratégia "Ship/Show/Ask" é possível decidir se o código segue para produção, pedir aprovação ou até mesmo avisar sobre a mudança, mas sem necessariamente aguardar a revisão para integrar o código em produção.

Empresas que possuem um nível maior de maturidade em DevOps estão optando por workflows "trunk-based", considerados mais adequados para entrega contínua do que o tradicional Git Flow. Esse artigo busca fornecer dicas aplicáveis em múltiplos contextos, embora existam diferenças no nível de aplicabilidade de acordo com o modelo de entrega contínua da empresa/produto que está sendo desenvolvido.

A origem de conflitos

É comum que o responsável direto pela entrega da atividade, frequentemente sob pressão de lideranças, deseje avançar o mais rápido possível para a próxima etapa do ciclo de desenvolvimento de software. Em paralelo, os responsáveis por revisarem o código também costumam possuir tarefas sob sua responsabilidade e precisam redirecionar o foco mediante a necessidade de revisão de código alheio.

Esse cenário pode desencadear uma série de conflitos, principalmente em times que ainda não desenvolveram um relacionamento sólido entre os integrantes e um processo saudável para todos. Quem desenvolve pode se estressar com a demora na revisão, enquanto quem revisa pode se estressar por ser interrompido para revisar um código de baixa qualidade e sem o contexto necessário.

O objetivo desse artigo é trazer algumas sugestões para evitar esses conflitos, assim como direcioná-los adequadamente conforme eles surjam. As dicas estão divididas em dois grupos: quem desenvolve e quem revisa. É essencial entender os dois papéis, já que eles são frequentemente desempenhados pela mesma pessoa em diferentes momentos.

Dicas para quem desenvolve

#1 — Tenha clareza do processo de revisão de código do seu time

Antes de mais nada, é importante entender o contexto onde se está trabalhando. É possível concluir que muitas dicas desse artigo já estão incorporadas ou são impraticáveis dentro do modelo de trabalho a partir da análise do modelo e coleta de perspectivas dos demais integrantes do time.

Além disso, é recomendado entender as métricas do time. Compreender o impacto do tempo relativo do ticket em processo de revisão pode gerar insights e fornecer insumos para a priorização de melhorias no processo, além de medir os indicadores afetados pelas mudanças introduzidas no processo.

#2 — Invista na comunicação sobre o conteúdo do PR

Independentemente da plataforma ou do workflow utilizado pelo time, é importante que a informação seja endereçada para quem será responsável por revisar.

Essa comunicação pode ser feita na própria ferramenta utilizada para abertura do PR. Garanta que o título demonstre o objetivo do código para que o responsável pela revisão saiba de imediato sobre o que aquilo se trata. A descrição pode ser mais completa, incluindo quaisquer informações adicionais que sejam relevantes para o entendimento do que foi feito, assim como os motivos da implementação ter sido feita de tal forma. Garanta também que informações e links externos, como ID da demanda sendo entregue e documentações alteradas, estejam presentes no PR.

Exemplo de formulário de abertura de pull request no Github — No GitHub, assim como na maioria das plataformas, é possível utilizar o título e a descrição do PR para transmitir o contexto necessário para o responsável pela revisão. Fonte: GitHub.

Frequentemente, o PR será composto por uma série de commits. Embora isso extrapole o contexto específico de revisão de código, é de extrema importância manter os commits com mensagens sobre as alterações que estão sendo feitas. Isso permitirá uma revisão com navegação commit a commit com facilidade, caso necessário.

Mesmo em times com comunicação mais frequente, em que seja de fácil compreensão o objetivo do PR para os responsáveis pela revisão, uma documentação bem feita a partir de mensagens em commits e PRs pode ser uma excelente ferramenta de análise histórica, dando insumos para análises futuras sobre a implementação por outras pessoas que não possuirão todo o contexto.

#3 — Crie PRs pequenos

Existem inúmeros motivos para trabalhar com PRs pequenos:

Revisão mais rápida: É mais fácil disponibilizar 5 minutos várias vezes por dia para revisar pequenos PRs do que reservar 30 minutos para revisar um PR grande.
Revisão mais completa: Com muitas mudanças em um único pacote, é necessária muita disciplina para que seja feita uma revisão detalhada, visto que quem revisa precisa voltar para as próprias tarefas e pode acabar fazendo uma revisão mais superficial. Nesse caso, problemas podem ser ignorados na revisão, o que aumenta o risco da demanda e impacta a qualidade.
Menos retrabalho em caso de reprovação: Caso alguém observe que a abordagem está errada como um todo, menos trabalho é desperdiçado em PRs menores.
Facilidade de merge: Trabalhar em um PR grande leva tempo, então é normal ter que lidar com muitos conflitos ao fazer o merge com a branch principal. Com uma frequência maior de PRs localizados, a chance de conflito é reduzida e se ocorrerem eles são facilmente resolvidos.
Mais fácil de alcançar um bom design de código: É muito mais fácil polir o design e manter a qualidade de código de uma pequena mudança do que refinar todos os detalhes de uma mudança grande.
Menos tempo bloqueado esperando revisão: Enviando pequenas porções de código para revisão é possível continuar trabalhando na demanda enquanto o restante dela é revisado.
Simplicidade no rollback: Um PR grande provavelmente vai envolver mais arquivos do que um pequeno, tornando-se mais complexo a realização de um rollback. Toda a demanda teria que sofrer o rollback, que poderia ser mais pontual em caso de pequenos PRs.

Para viabilizar PRs pequenos, considere sempre se atentar a algumas práticas:

Maturidade em feature flags: Suba o código para produção mesmo sem a funcionalidade completa estar pronta e não se preocupe em causar impacto. Isso é essencial para possibilitar o merge de PRs pequenos mesmo em funcionalidades ambiciosas do produto.
Shift-right: Mecanismos avançados para deployment em produção, como canary e blue green, além de testes e monitoria robustos em produção, auxiliam na identificação rápida de problemas em caso de subida de algum pacote com defeito. Isso garante uma frequência elevada de deploys em produção sem riscos de catástrofes, elevando a maturidade DevOps do time.
Isolar PR por funcionalidade: É recomendado que um PR não faça mais de uma alteração no produto ao mesmo tempo. Para alcançar isso, é possível separar o refactoring necessário da mudança comportamental de uma story, por exemplo. Assim, o risco de efeito colateral pelo refactoring é isolado do risco inerente à mudança comportamental sendo introduzida.
Arquitetura desacoplada: uma definição adequada do escopo dos componentes que compõe a arquitetura da empresa é essencial para viabilizar mudanças frequentes em produção, visto que os riscos passam a ser isolados e, normalmente, sob responsabilidade do time responsável por aquele contexto. A partir disso, o time consegue mensurar o nível de precaução necessária para cada mudança mediante o potencial impacto para o negócio.

Esse nível de maturidade não é simples de se alcançar, mas é importantíssimo buscar atingir. Quanto maior a frequência de deploys em produção, maior a confiança no processo e maior a facilidade de execução de rollback para uma versão pouco diferente da versão mais recente.

#4 — Promova o PR

Para garantir o engajamento das pessoas necessárias para a revisão do PR, uma prática recomendada é a promoção ativa a partir de quem desenvolveu. Isso significa destacar as qualidades do PR e o motivo de você estar motivado a entregar o quanto antes.

Alguns exemplos de características que é possível destacar em um PR:

Quantidade de linhas / arquivos alterados. Se possível, uma estimativa de tempo que deve ser suficiente para efetuar a revisão é melhor ainda, para destacar que, com apenas alguns minutos de esforço, a pessoa vai contribuir bastante na entrega de seu trabalho, além de ajudar a empresa a atingir seus objetivos.
Data alvo / urgência. Deixe claro qualquer objetivo que precise ser cumprido através da entrega rápida do PR. Esse objetivo pode ser a release de uma versão da aplicação, a conclusão de uma sprint ou até mesmo o cumprimento de alguma regulação governamental com data inflexível.
Motivo de seleção da pessoa. Destaque o motivo da escolha de tal pessoa e por que é importante ter a aprovação dela no PR, quando aplicável. Por exemplo, caso seja necessário o apoio de alguém que possui vivência em determinada área da aplicação ou experiência na aplicação de algum design pattern utilizado no PR, destaque isso ao solicitar a revisão.
Prestatividade. Também é uma boa ideia dialogar sobre o conteúdo revisado, assim como esclarecer quaisquer dúvidas que venham a surgir durante a revisão.

Uma boa reputação é essencial para garantir essa cooperação. Então busque entregar código de alta qualidade, que normalmente não necessite de ajustes. Na inversão de papéis é essencial revisar rapidamente o código de colegas, gerando reciprocidade.

#5 — Lide bem com comentários

Eventualmente vão existir comentários no seu código, e isso não é problema nenhum. Nunca leve críticas a qualidade da implementação do código para o lado pessoal, e maximize o potencial dos comentários na construção de software de alta qualidade.

Caso a pessoa não tenha entendido algo no código, a resposta padrão deve ser ajustar o código. Isso por que é importante que o código se comunique por si só. Se gerou dúvidas, é provável que a pessoa responsável pela manutenção futura também fique confusa com a implementação. Portanto, a melhor resposta costuma ser simplesmente ajustar o código para aumentar a clareza. Excessões existem, como casos em que a pessoa não tem contexto ou conhecimento suficiente para entender o que foi feito. Nesse caso, realmente uma resposta no comentário seja o melhor caminho. O importante é sempre fazer essa reflexão.

Caso alguma alteração seja solicitada, tenha paciência e empatia para compreender o que a pessoa solicitou. Pode ser muito frustrante caprichar em uma entrega e receber um comentário contestando a sua abordagem, mas pode ser que ele realmente faça todo sentido, e traga uma abordagem melhor para resolver o problema. Maximize o auto aprendizado se aprofundando nas práticas e padrões sugeridas para ser capaz de utilizar em futuras implementações. Se o comentário for relativo a um deslize na interpretação dos requisitos da demanda, ou algum detalhe que poderia ser evitado a nível de desenvolvimento, reflita sobre como evitar novas ocorrências.

Caso você realmente discorde tecnicamente do apontamento na revisão, busque esclarecer se a sua interpretação do comentário está correta e, caso sim, argumente com cortesia e respeito em favor da sua implementação. Fale sobre os tradeoffs que foram considerados na abordagem, e os motivos de sua abordagem ser a mais adequada dentro do contexto. Trabalhe colaborativamente para garantir que a empresa tenha o melhor resultado final. Sempre deve ser possível chegar em um consenso com base em critérios técnicos. Frequentemente, múltiplas alternativas podem atender ao problema com qualidade e custo parecidos. Nesse caso, não deve ser necessário fazer alterações, desde que se chegue em um acordo.

Normalmente, qualquer crítica ou sugestão no código é feita com o objetivo de manter a base de código da empresa saudável, e não como um ato de perseguição individual. No entanto, a pessoa responsável por revisar o código pode se sentir frustrada, principalmente em casos em que sentiu que teve que interromper o próprio trabalho para revisar um código no qual considera que o autor não dedicou cuidado o suficiente para entregar em alto nível, até mesmo com erros já pontuados em revisões anteriores, mas repetidos frequentemente.

Em sua posição de guardiã da qualidade de código do repositório, a pessoa também pode se sentir pressionada e em constante batalha com devs tentando introduzir código inadequado nas branches principais. Diante desse cenário, a pessoa pode acabar se expressando mal na revisão de código e chatear o autor, criando um clima desagradável no ambiente de trabalho.

Isso não significa que a pessoa esteja certo nesse cenário, como será analisado nas dicas para quem revisa. Porém, busque fazer um esforço para abstrair e refletir. "O que a pessoa quis dizer? Que opinião construtiva posso obter a partir dos comentários?". Siga com seu trabalho a partir desse filtro.

Nunca responda com rispidez a comentários da revisão. Isso não será bem visto, e ficará para sempre registrado no histórico da plataforma de versionamento. Caso esteja com o humor muito impactado para conseguir responder com calma aos comentários, dê uma espairecida, ou vá trabalhar em outra tarefa, até conseguir responder com calma aos comentários, com a devida educação.

Caso sinta que a pessoa não está fornecendo feedbacks de forma construtiva e educada, explique pessoalmente, ou por chamada de vídeo. Explique, com tranquilidade, por que você não gostou da forma com que a pessoa se expressou, e sugira alternativas para uma comunicação mais saudável.

Se ainda assim não seja possível resolver o conflito, e estejam em um impasse, escale com a gestão para buscar juntos uma solução.

Dicas para quem revisa

#1 — Priorize garantir a qualidade do código entregue

Fique atento para não aprovar código que não atenda os critérios necessários para manter a qualidade da base. Dentre os critérios que podem ser avaliados estão:

Design da solução: Um dos primeiros pontos a avaliar no PR é garantir que o design da solução esteja bem elaborado. Verifique se as escolhas feitas para resolver o problema foram bem feitas, se realmente a mudança deveria ser feita naquela parte do código, e não em outro serviço ou biblioteca, se aquela mudança é coerente dentro do contexto do sistema, etc.
Funcionalidade: Talvez o ponto mais importante: a solução implementada resolve o desafio proposto? Normalmente, é esperado que o código tenha sido suficientemente testado por quem desenvolveu para garantir que os critérios técnicos e de negócio da demanda estejam sendo atendidos. Porém, é necessário se atentar, avaliar casos extremos (como potenciais problemas de concorrência entre threads, que possam passar despercebidas no desenvolvimento), e até mesmo potenciais bugs que podem ter passado batido pelos testes. Também é possível testar o PR na própria máquina, principalmente para validar comportamentos de tela, caso sinta a necessidade. Uma alternativa é pedir uma demonstração.
Complexidade: Importante garantir que o código seja limpo, e não represente uma complexidade desnecessária que possa impactar futuras manutenções, com nomenclatura adequada para classes, objetos e funções. É fácil de identificar códigos de alta complexidade pela demora na interpretação do que o código está fazendo. Nesses casos, é possível que alguém introduza um bug no futuro, ao tentar alterar o código sem total entendimento do funcionamento. Preste atenção em casos de over-engineering e ao conceito de Yagni (You ain't gonna need it) para evitar código que traga complexidade desnecessária no momento pensando em evitar possíveis problemas futuros. Existem casos que vale a reflexão sobre se o código é realmente complexo ou se você não está acostumado com o paradigma. Programadores acostumados com orientação a objeto não necessariamente entendem com facilidade programação funcional, e nem por isso uma composição de funções está errada ou complexa demais.
Testes: É essencial garantir que os testes unitários, de integração, de contrato, de mutação, ou quaisquer outros testes automatizados que o time costume utilizar, estejam devidamente implementados antes de aprovar código novo para produção. É possível ter mecanismos automáticos integrados na esteira para verificar a cobertura de testes, mas no geral as verificações não substituem o olhar de um ser humano no quesito sensatez. Os testes também precisam ter alta manutenibilidade, e devem influenciar positivamente o design da solução.
Comentários: É necessário entender se os comentários são realmente necessários, e não foram escritos apenas para viabilizar código de baixa qualidade. Normalmente, comentários são úteis para explicar o motivo por trás de algum código, e não para explicar o que o que código está fazendo. Se o código não for auto-explicativo, deve se buscar alternativas para torná-lo mais simples. Existem exceções, como expressões regulares e algoritmos complexos, como criptografia. Docstrings não se enquadram como comentários, então os times podem ficar a vontade de utilizar conforme a padronização do projeto.
Estilo: É importante garantir se o código está seguindo os padrões pré-definidos do projeto e da linguagem de programação. Refatorações para adequação de estilo não devem ser incluídas junto com mudanças reais de comportamento, até por que isso dificulta a análise de alterações e o histórico do repositório. Portanto, é bom recomendar 2 PRs separados caso a refatoração prévia seja necessária. Casos que não tenham uma definição formal, e sim uma preferência pessoal, não devem ser cobrados na revisão do código. O máximo que deve ser feito nesse cenário é uma sugestão (nitpick / np) e, talvez , servir de insumo para um alinhamento a respeito da padronização do projeto. Boa parte dos possíveis problemas reais de estilo devem ser identificados de forma automática na esteira, evitando debates sobre isso e permitindo o aprofundamento em outros critérios.
Documentação: Verifique se a mudança trás consigo uma necessidade de ajuste nas documentações do time, e se os ajustes necessários foram feitos. A necessidade pode vir de alterações no processo de build do projeto, nas interfaces expostas, ou em fluxos de negócio que precisem ser documentados. Para manter a documentação organizada, também é importante avaliar se as documentações referentes a APIs depreciadas ou fluxos removidos também foram ajustadas.

Garanta ter revisado profundamente todos os aspectos mencionados, além de qualquer outro aspecto que você considere importante, em todo o PR. Caso o PR seja muito grande, não arrisque comprometer a qualidade da base de código para poder fazer uma revisão rápida. Alinhe com o time para uma melhor quebra de atividades para garantir uma entrega contínua sem comprometer a qualidade. Caso não se sinta 100% confortável em validar algum trecho do código por falta de domínio no contexto, tenha certeza que pessoas capacitadas também estejam presentes na revisão. Se possível, aproveite a oportunidade pra adquirir o conhecimento necessário.

É essencial buscar o equilíbrio entre rigor e velocidade de entrega diante de cada contexto. A rigidez não pode ser tamanha a ponto de que nenhuma mudança seja considerada boa o suficiente para chegar em produção. Por outro lado, não é recomendado ser flexível a ponto de permitir que a qualidade da base de código se deteriore. Isso é um desafio, visto que a qualidade da base de código costuma cair lentamente, conforme pequenas mudanças são introduzidas com o decorrer do tempo, principalmente quando o time enfrenta prazos agressivos e busca atalhos para atingir os objetivos dentro do tempo determinado, sem mapear os débitos técnicos para adequação futura. Isso ressalta a importância da revisão de código no processo. Assim como quem desenvolve, quem revisa também é responsável pelo código introduzido em produção.

Não existe "código perfeito". Existe código melhor do que o anterior. Portanto, se o código proposto atende o objetivo e não degrada a qualidade da base, no geral deve ser aceito. Ao invés de buscar a perfeição, é importante focar em melhoria contínua. Se o PR melhora a manutenibilidade, legibilidade e facilidade de entendimento de um sistema, ele não deve ser segurado por dias ou semanas até atingir a suposta perfeição. Sugestões são sempre bem vindas, mas é importante deixar claro quando for apenas uma sugestão, para que a pessoa possa decidir se seguirá ou não a proposta.

Por fim, não desperdice oportunidades de elogiar o código em aspectos positivos observados. As revisões de código costumam gerar conflitos por ser um processo de qualidade que pode apontar erros de colegas, mas também pode ser uma oportunidade de criar vínculos e reforçar bons comportamentos a partir de elogios oportunos.

#2 — Faça rápido

É necessário otimizar a velocidade de entrega de produtos do time como um todo. Em um contexto ágil, a velocidade do coletivo é mais importante do que a velocidade individual, então é muito importante desbloquear a sequência do fluxo para outros colegas do time quando solicitado.

Um processo lento de revisão de código pode impactar de forma drástica no ciclo de desenvolvimento de software, principalmente por existir a possibilidade de devolução para ajustes no desenvolvimento, o que exigirá múltiplas interações para a mesma atividade, atenuadas pelo tempo tomado entre cada interação. Quem desenvolveu pode sentir frustração com a demora e não aceitar de cabeça aberta os comentários impostos, criando atritos no time. Caso a atividade tome muito tempo nessa fase do processo, pode surgir uma pressão para acelerar a entrega, com solicitações de flexibilização na criteriosidade para habilitação rápida da funcionalidade em produção.

Caso não se esteja trabalhando em uma tarefa que exija foco prolongado, a revisão deve ser quase imediata. Se estiver escrevendo código, não interrompa imediatamente para realizar a revisão. Leva um tempo para um retomar o fluxo de desenvolvimento de software após uma interrupção. Então calibre a execução das próprias tarefas com uma revisão rápida do código alheio. Caso ambas as partes sigam boas práticas, o processo total deve ser rápido e indolor.

Uma forma de acelerar a resposta do PR é criar comentários conforme identifique problemas. Dessa forma, quem desenvolve já pode analisar os comentários e fazer alguns ajustes enquanto o PR continua a ser revisado, paralelizando o processo.

Caso esteja atuando em demandas urgentes e não vá conseguir dedicar o tempo necessário para revisar o PR com qualidade e velocidade, sugira outras pessoas que consigam te substituir dentro daquele contexto. Isso atenderá as necessidades do time e te permitirá seguir com as atividades mais importantes.

Com o passar do tempo, o time deve evoluir o nível de maturidade, com PRs de tamanho adequado para revisão e maior qualidade desde o commit, reduzindo o volume necessário de comentários e acelerando o processo como um todo. Porém, no início, pode ser que o processo realmente seja um pouco trabalhoso, então dedique esforços para garantir a melhoria contínua do time.

#3 — Revise com clareza e respeito

É importante demonstrar cortesia e respeito sem abrir mão da clareza nos comentários. É essencial sempre fazer comentários sobre o código de não sobre quem desenvolveu, sempre explicando os motivos para os apontamentos necessários. É importante formular as frases para evitar chateação. Por exemplo, ao invés de comentar:

"Por que você utilizou múltiplas threads nesse contexto, quando na prática a complexidade aumenta sem trazer nenhum benefício real?"

É possível dizer:

"O modelo de concorrência adotado aqui está adicionando complexidade ao sistema sem nenhuma melhoria real de performance que eu consiga ver. Como não há benefício de performance, é melhor que esse código utilize apenas uma thread ao invés de múltiplas threads".

No geral, é tarefa de quem desenvolveu arrumar o PR, e não de quem está revisando. Quem revisa não é obrigado a fornecer um design detalhado da solução ou escrever código. No entanto, isso não significa deixar de ser colaborativo. É importante encontrar um equilíbrio no nível de auxílio fornecido para resolver os problemas identificados. Lembre-se que, embora resolver sozinho seja uma ferramenta importante de evolução pessoal e parte da responsabilidade de quem desenvolve código, você está comprometido com a qualidade do código e com a velocidade de entrega do time, então é essencial contribuir em um nível maior de detalhes conforme necessidade.

#4 — Utilize a revisão como ferramenta de mentoria

A função principal da revisão de código é garantir a qualidade do código da empresa em produção. Entretanto, não deixa de ser uma ferramenta muito útil para mentoria entre integrantes mais experientes e integrantes menos experientes de um time, tanto em carreira como em tecnologias específicas.

A revisão de código de pares tem uma função muito importante no aprendizado sobre linguagens, frameworks e princípios de desenvolvimento de software. É sempre valioso o uso de comentários que ajudem as pessoas a aprenderem algo novo.

O compartilhamento de conhecimento é parte essencial da estratégia de melhoria de base de código ao longo do tempo.

#5 — Lide bem com reações aos comentários

Se o responsável pelo desenvolvimento do código questionar ou discordar das sugestões propostas, primeiramente, é importante tirar um momento para considerar que a pessoa pode estar certa, visto que, normalmente, ela está mais próxima do código do que você, e pode ter uma visão mais detalhada do contexto naquele momento. Então é válido se perguntar se os argumentos de quem produziu o código são válidos, e não está sendo realmente criada uma redução na qualidade do código.

Dito isso, nem sempre quem desenvolveu tem razão. Nesse caso, é necessário explicar com maior profundidade e clareza o motivo de se acreditar que a sugestão seja válida. Uma boa explicação demonstra tanto que as preocupações foram entendidas, quanto acrescenta informações adicionais para reforçar o motivo da solicitação de alterações. Quando você acredita que a sugestão vai melhorar a qualidade do código e justifica o tempo estimado para aplicação, você deve advogar pela mudança e ir além, garantindo que o mindset do time esteja alinhado em relação a qualidade de software.

Eventualmente, quem desenvolve pode ficar chateado ao receber comentários insistentes solicitando melhorias no código, mas no final normalmente ficam agradecidas pela ajuda no desenvolvimento profissional e na garantia de qualidade de código. Muitas vezes a chateação é maior na cabeça de quem fornece feedbacks, pela preocupação em evitar conflitos com pares. Mas normalmente, quando a pessoa fica chateada, o motivo maior é a maneira como a comunicação ocorreu, e não em relação aos apontamentos realizados.

Não abra exceções com frequência em relação a rigidez da revisão. Caso seja alguma demanda urgência, e que dê para o código entrar em produção sem quebrar funcionalidades ou introduzir novos bugs, é possível aprovar mediante a abertura de débitos técnicos no backlog, por exemplo. Garanta que dentro da estrutura em que o time trabalha, o volume e aging de débitos técnicos seja monitorado, e algum profissional seja responsável pela priorização adequada dos itens.

Por fim, lembre-se que as insatisfações na revisão de código são normalmente amplificadas por deslizes de quem revisa, como lentidão nas respostas ou comentários considerados grosseiros. Evitando esses pontos, a probabilidade de quem desenvolveu receber os comentários de bom grado e seguir as recomendações prontamente é muito maior. Lembre-se também que um perfil questionador muitas vezes é melhor do que um perfil acomodado, que simplesmente aceite qualquer comentário para evitar conflitos. Valorize e internalize os feedbacks para melhoria contínua no próprio trabalho em revisão de código.

Colocando em prática

Não é necessário muito esforço para aplicar boa parte desse material no dia a dia. Seja proativo em já utilizar as dicas que fizerem sentido para você, além de pesquisar mais além, possivelmente começando pelas referências elencadas, e discutir com seus colegas sobre o assunto.

Uma prática essencial para garantir a melhoria contínua do processo de desenvolvimento ágil de software é o uso adequado de retrospectivas. Inclusive, um dos princípios por trás do manifesto ágil reforça a importância de um refinamento constante do modelo de trabalho:

Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

Caso deseje utilizar amplamente as práticas debatidas no artigo, mas encontre dificuldades, debata com seu time, mantendo a mente aberta. Entenda as dores de cada um e trabalhem juntos na definição e execução de um plano de ação colaborativo. Aja como um replicador de boas práticas e estimule a entrega contínua de software de alta qualidade.