Rodei git blame nas regras que mexem em dinheiro: 87% da lógica de comissão tinha um autor só

Passei tempo demais discutindo concentração de conhecimento por impressão. "Só o Fulano mexe nisso", "esse módulo é do Fulano", "melhor esperar ele voltar". Nenhuma dessas frases entra numa reunião de planejamento como argumento, porque não tem número do lado.

Então parei de opinar e fui medir. O recorte que usei não foi o repositório inteiro: peguei as dez regras de negócio que mexem em dinheiro (como o desconto é calculado, quando um pedido pode ser cancelado, o que libera o repasse ao parceiro), apontei cada uma para o arquivo ou pasta que a implementa e rodei blame só ali.

O script

#!/usr/bin/env bash
# concentracao.sh <caminho>
set -euo pipefail
alvo="$1"
total=$(git blame -w -C -C "$alvo" | wc -l)

git blame -w -C -C --line-porcelain "$alvo" \
  | grep '^author ' | sed 's/^author //' \
  | sort | uniq -c | sort -rn \
  | awk -v t="$total" '{
      nome=$0; sub(/^ *[0-9]+ /, "", nome);
      printf "%-22s %4d linhas  %5.1f%%\n", nome, $1, ($1/t)*100
    }'

Os flags importam mais que o resto do script. O -w ignora mudança só de espaço em branco, e o -C -C faz o blame seguir linha que veio de outro arquivo, em vez de creditar quem moveu o código de lugar. Sem os dois, qualquer commit de formatação transforma uma pessoa no autor do sistema inteiro.

Saída de um dos arquivos:

$ ./concentracao.sh src/billing/commission.ts
Fulano Silva            412 linhas   87.1%
Ciclano Souza            38 linhas    8.0%
Beltrana Lima            23 linhas    4.9%

Dos dez caminhos que eu mapeei, três passaram de 80% num nome só, e em dois deles era o mesmo nome. Não foi surpresa para ninguém do time. A diferença é que agora dava para escrever no card.

A segunda consulta é a que muda a conversa

Concentração alta não é um problema, são dois, e eles pedem respostas diferentes. Descobre qual é o seu perguntando se a pessoa ainda está por perto:

$ git log -1 --format='%an  %ad' --date=short -- src/billing/commission.ts
Fulano Silva  2024-11-19

$ git log --author='Fulano Silva' --since='8 months ago' --oneline | wc -l
0

Zero commits em oito meses. Aquele arquivo não tem gargalo, tem órfão: quem escreveu 87% dele saiu, e o que ficou é a única descrição viva das regras. Quando o número volta com a pessoa ativa, o retrato é o oposto, e o custo aparece na agenda antes de aparecer no código. Toda tarefa que encosta na regra entra na fila de uma pessoa só, a estimativa passa a depender do calendário dela, e em janeiro o roadmap anda com o que sobra.

Onde o blame mente

Ele mede quem escreveu a linha que está lá hoje, e mais nada. Três armadilhas que eu peguei rodando isso:

• Commit de formatação em massa (prettier, black, mudança de lint) reescreve autoria de arquivo inteiro. Vale conferir com git log --format='%h %an %s' -- <caminho> e jogar os hashes suspeitos num .git-blame-ignore-revs, apontando com git config blame.ignoreRevsFile .git-blame-ignore-revs.
• Migração de repositório ou import inicial gigante credita tudo a quem rodou o script de migração. O --since na consulta de atividade ajuda a separar isso.
• Autoria não é entendimento. Quem escreveu pode ter esquecido, e quem revisou por meses pode explicar melhor que o autor. O número é um indício de para onde olhar, não um veredito.

Para a terceira armadilha existe um teste mais honesto, e ele não sai do git. Pegue alguém que nunca mexeu naquela regra e peça uma alteração pequena, lendo apenas a documentação. Se a pessoa terminar sem perguntar nada, sua documentação é boa. Se ela abrir o Slack em vinte minutos, você tem um arquivo, não um documento.

Em obra existe o projeto, que é o desenho de antes, e existe o as-built, o desenho de como ficou depois das decisões tomadas no canteiro. Repositório quase sempre tem o primeiro e não tem o segundo. O commit registra o "como" e some com o "porquê": aquele if estranho no meio do serviço de pedidos costuma ser um contrato comercial de 2019 fechado por telefone.

O agente engorda o numerador e não o denominador

Escrever código sempre foi a forma cara de aprender o sistema. Quem implementava a regra de comissão passava uns três dias dentro dela, xingava o histórico e saía sabendo explicar. Com um agente, a mesma alteração sai em quarenta minutos, passa no review e entra em produção.

O efeito na medição é direto: a quantidade de linhas que precisam de manutenção cresce, e o número de cabeças capazes de explicar aquelas linhas continua o mesmo. Se você rodar o script hoje e de novo daqui a seis meses, é bem provável que a concentração suba sem ninguém ter tomado nenhuma decisão a respeito.

O que eu faço com o número depois

Força-tarefa de documentação resolve pouco e envelhece rápido. O que move o percentual é fazer outra pessoa escrever naquele arquivo, e isso cabe em três movimentos: tarefa que encosta na regra concentrada sai em dupla, com quem não sabe segurando o teclado. O plantão roda entre todo mundo, com quem conhece o sistema na retaguarda e não na linha de frente. E o dono da regra escreve meia página de porquê, que só vale depois que outra pessoa conseguiu alterar a regra lendo apenas ela.

Isso custa alguma coisa como 20% a 30% a mais nas primeiras semanas, e o time reclama. Se você tem três pessoas e ainda está procurando cliente, nem faça: concentração é vantagem nesse estágio, e o seu problema de verdade é descobrir se alguém paga pelo produto. A conta vira quando o faturamento passa a depender daquele arquivo.

Eu rodo o script uma vez por trimestre e guardo a saída num arquivo com a data no nome. A comparação entre duas medições diz mais que qualquer uma delas sozinha.

Como vocês medem isso aí? Alguém usa .git-blame-ignore-revs para essa finalidade, ou tem métrica melhor que blame para achar regra de negócio com um dono só?

Publicado originalmente no blog da Revin: https://revin.com.br/pt/blog/divida-cognitiva-divida-tecnica-fora-do-codigo