Escolhendo a altitude certa para corrigir um bug encontrado em review, não só o patch mais rápido

na Dynamox

Em code review, identifiquei um bug de null-safety que teria derrubado três componentes de produção, e corrigi a classe do defeito em vez das três instâncias, propondo um helper compartilhado na camada de dados para a autora do PR em vez de aplicar patch em cada ponto de renderização eu mesma; um dos 310 pull requests em que dei um veredito explícito de review naquele semestre (702 em quatro repositórios entre 2025-03 e 2026-08), medido a partir da API do Bitbucket em vez de lembrado de memória.

impactoEvitei um crash em três componentes de produção antes de irem ao ar.Removi a classe de defeito subjacente, não só as três instâncias conhecidas, via um helper compartilhado na camada de dados que qualquer consumidor futuro agora usa.Mantive a correção sob ownership da autora original, reforçando o padrão para ela em vez de substituir meu julgamento pelo dela.Parte de uma prática de review reconhecida em feedback de performance pela clareza de suas perguntas e documentação, com mais de 100 reviews em um único semestre entre frontend, backend e testes.

Contexto

A maioria dos meus estudos de caso é sobre trabalho que fui dona de ponta a ponta. Este é evidência de uma capacidade diferente, igualmente importante: elevar o padrão de qualidade do trabalho de outra pessoa sem tomá-lo para mim. Code review é onde muito julgamento real de engenharia é invisível: identificar um defeito que não está obviamente errado, decidir corrigir o caso geral em vez da instância, e escolher sugerir em vez de reescrever para que a autora mantenha ownership e a lição. Isso é parte de uma prática sustentada, mais de 100 reviews entre frontend, backend e testes em um único semestre, ao lado de pair programming em trabalho crítico, em vez de uma pegada pontual.

Problema

O pull request de uma colega de time renderizava uma lista de itens depois de filtrá-la, mas uma lógica próxima no mesmo componente ainda se referia ao tamanho do array original, não filtrado. As duas linhas eram localmente corretas, e nenhuma estava errada por si só, mas juntas codificavam uma suposição de que os dois valores sempre concordariam. Não concordariam: no momento em que o filtro de fato removesse um item, os dois valores derivados divergiriam, e três componentes compartilhavam exatamente esse padrão.

Restrições

—O bug era invisível linha a linha. Nada no diff estava individualmente errado. O defeito só existe na *relação* entre dois valores derivados da mesma fonte, exatamente o tipo de bug que um review rápido e focado no diff perde.

—A correção rápida era tentadora e insuficiente. Aplicar patch nos três pontos de chamada conhecidos teria feito o sintoma visível desaparecer sem remover a classe de defeito subjacente, e o próximo componente construído da mesma forma o reintroduziria.

—Não era o meu código. Propor uma mudança estrutural mais profunda no pull request de outra pessoa arrisca ser ignorada (leve demais) ou tomar o trabalho dela (pesado demais). Acertar esse equilíbrio é, em si, a habilidade.

Decisão

Reconheci o formato do bug antes de decidir o que fazer sobre ele: dois valores derivados da mesma fonte, lidos de forma independente, sem garantia de que permaneceriam sincronizados. Era o mesmo tipo de problema que já resolvi arquiteturalmente em outro lugar dando a um valor derivado um único caminho de computação.

—Rastreei o padrão até os três componentes afetados, não só o do diff, para que a correção pudesse endereçar a classe real do defeito.

—Propus um helper compartilhado na camada de dados, um único lugar que deriva o valor de que ambas as lógicas precisam, para que nada a jusante possa mais ler duas respostas diferentes da mesma fonte.

—Sugeri à autora em vez de implementar eu mesma. Deixar a mudança nas mãos dela custou uma rodada extra de review, mas manteve o ownership dela sobre o PR intacto e ensinou o padrão em vez de silenciosamente sobrescrever o trabalho dela.

Trade-offs

—Um helper compartilhado na camada de dados em vez de aplicar patch nos três pontos de renderização. Corrigir as três instâncias é mais rápido; dar a elas uma fonte compartilhada remove a classe de defeito para qualquer consumidor futuro também, o que valeu a etapa extra de design para um padrão que já tinha se repetido três vezes.

—Sugerir a correção em vez de implementá-la eu mesma. Escrever a correção diretamente teria sido mais rápido e garantido meu resultado preferido, mas teria tirado o PR de sua autora. Propor e deixá-la aplicar custou um ciclo de review e produziu uma colega que entendeu o padrão, não só uma correção mesclada.

—Revisar o invariante em vez de revisar o diff. Raciocinar sobre o que os dois valores derivados deveriam garantir juntos, em vez de checar cada linha isoladamente, é mais lento por review mas é a única forma dessa classe de bug ser pega antes de produção.

Impacto

—Evitei um crash em três componentes de produção antes de irem ao ar.

—Removi a classe de defeito subjacente, não só as três instâncias conhecidas, via um helper compartilhado na camada de dados que qualquer consumidor futuro agora usa.

—Mantive a correção sob ownership da autora original, reforçando o padrão para ela em vez de substituir meu julgamento pelo dela.

—Parte de uma prática de review reconhecida em feedback de performance pela clareza de suas perguntas e documentação, com mais de 100 reviews em um único semestre entre frontend, backend e testes.

Lições Aprendidas

Conhecimento de engenharia reutilizável que levo adiante disso:

—Um valor com dois leitores independentes é um bug esperando o dia em que vão divergir. O mesmo princípio que rege consistência de dados entre serviços se aplica igualmente dentro de um único componente.

—Em review, corrija a classe quando conseguir vê-la, não só a instância na sua frente. Três repetições do mesmo padrão são um sinal de que aplicar patch na visível vai deixar as outras duas para falhar depois.

—Sugira, não tome para si. Um review que corrige o padrão e devolve a implementação ensina; um review que silenciosamente reescreve o PR não ensina.

—Revise o que o código assume, não só o que ele mudou. O bug só era visível ao raciocinar sobre o invariante que as duas linhas deveriam compartilhar.

Evidência

—Identifiquei e redirecionei um bug de divergência de null-safety em três componentes antes do lançamento, via uma abstração compartilhada proposta em vez de uma reescrita direta.

—Parte de uma prática de review sustentada, medida a partir da fonte (Bitbucket, 2025-03 a 2026-08): 702 pull requests em que registrei um veredito explícito de review, 692 aprovações e 10 solicitações de mudança, em quatro repositórios (dois serviços de backend, a aplicação web compartilhada, e o repositório de infraestrutura), de 1.221 em que fui designada como revisora. Semestre de pico: 310 veredictos em 2025-07 a 2025-12, que é de onde veio o número "mais de 100 reviews em um semestre" na minha avaliação de performance. O número real era o triplo disso. Para efeito de escala, eu escrevi 360 pull requests no mesmo período (337 mesclados), então revisei aproximadamente duas mudanças de colegas para cada uma minha.

—Também entre frontend, backend, testes e infrastructure-as-code, mais pair programming em entregas críticas.

—Reconhecida em feedback de performance pela clareza das perguntas de review e da documentação de PR, e pelo volume, subindo de 18 reviews no ciclo anterior.

—Fonte: contagens de review computadas diretamente da API do Bitbucket sobre os quatro repositórios em que contribuo (veredito como autora e como revisora por pull request), 2025-03 a 2026-08. Narrativa e o review-âncora: base de conhecimento de carreira consolidada e evidência de avaliação de performance (privada).