Paguei três vezes pela mesma função. Dinheiro foi o menor problema

Uma edtech chegou na Revin com uma base de três anos e sete freelancers no histórico. Fui atrás de um bug e encontrei a mesma função construída três vezes. A duplicação não era o desastre. O desastre era o que ela escondia.

Por Victhor Araújo

Victhor Araújo

Abri o repositório dessa edtech num sábado à noite atrás de um bug bobo: o e-mail de redefinição de senha não chegava para parte dos usuários. Dei um grep por "sendMail". Voltaram três resultados. Não três chamadas da mesma função, três funções diferentes, em três arquivos diferentes, cada uma mandando e-mail do seu jeito.

A base tinha três anos e sete freelancers no histórico do git. Contei pelos nomes dos commits, meio por curiosidade, meio por susto. Sete pessoas passaram por ali, e cada uma, em algum momento, precisou mandar um e-mail e resolveu escrever de novo em vez de procurar o que já existia. A edtech tinha acabado de chegar na Revin, e essa foi a primeira coisa que eu vi.

Se você é founder e contratou freelancer atrás de freelancer para tocar o produto, cada um ótimo no portfólio, cada um recomendado por alguém, esse texto é sobre a sua base de código, mesmo que você nunca tenha aberto o git.

Procurei um remetente de e-mail e achei três, cada um escrito por uma mão que nunca leu as outras duas.

Três remetentes, um bug que não morria

Consertei o remetente do reset de senha em vinte minutos. O problema é que o e-mail de confirmação de cadastro usava outro dos três remetentes, e esse seguiu quebrado por mais uma semana, até um usuário reclamar no suporte. O de cobrança usava o terceiro. Três lugares para arrumar a mesma coisa, e ninguém no time sabia que eram três.

Esse é o custo que a duplicação esconde, e ele não é o espaço em disco. É uma correção que deveria valer para o produto inteiro valendo só para um pedaço, enquanto os outros dois seguem quebrados sem avisar ninguém. Você acha que resolveu. O cliente descobre que não.

Por que ninguém apagou a função velha?

A resposta desconfortável é que apagar código dá trabalho e não aparece. Quando um freelancer entra para entregar "o fluxo de cobrança em duas semanas", ele tem duas semanas e um escopo fechado. Ler os outros trinta arquivos para descobrir que já existe um mailer pela metade não está no orçamento dele. Escrever um novo, que ele controla e entende, é mais rápido e mais seguro para o prazo. Então ele escreve.

Nenhum dos sete fez por preguiça. Eu li o código deles, tinha gente muito boa ali. Fizeram a conta que qualquer freelancer sensato faz: reusar código alheio que você não entende é mais arriscado do que escrever do zero, quando você vai embora em duas semanas e não volta. Faz sentido para cada um, isolado. O que ninguém soma é o efeito dos sete juntos.

E aqui vai uma concessão que preciso fazer, senão fico desonesto: freelancer não é o vilão em todo cenário. Para uma landing de campanha, um script que roda uma vez, uma integração isolada que ninguém vai tocar de novo, contrate um bom freela e seja feliz. O estrago aparece quando você usa freelancer em série para construir e manter um produto que depende de continuidade. Aí cada troca de pessoa reinicia a memória do sistema do zero.

O que a duplicação cobra depois

Somando tudo, a conta que sobra para o founder tem quatro linhas, e nenhuma aparece no orçamento de nenhum dos sete contratos:

• Bug que volta: você conserta num lugar e ele reaparece no outro, porque eram cópias que ninguém sabia que existiam.
• Retrabalho puro: nessa mesma base, um dos freelancers refez do zero uma exportação de CSV que já existia 80% pronta num canto do projeto.
• Imposto de onboarding: todo dev novo trava na mesma pergunta, qual dos três remetentes eu uso, e escolhe errado metade das vezes.
• Velocidade falsa: o time parece produtivo porque entrega telas, mas boa parte da energia vai em manter versões paralelas da mesma coisa.

Aquele CSV, quando fui somar as horas lançadas para refazer o que já existia, deu uns R$ 26 mil. É estimativa minha, olhando o time tracking do freela, e pode estar inflada: nem toda hora dele foi só nisso. Mas mesmo cortando pela metade, são R$ 13 mil para reconstruir código que estava no próprio repositório.

Isso é dívida que se acumula em silêncio, do tipo que a gente costuma tratar como planilha de risco, não como queixa de dev.

Ler a base inteira antes de tocar é a parte chata que ninguém cobra, e a que acha a duplicação primeiro.

Um squad que fica lê a base antes de escrever

A diferença de um time que vai manter o que escreve começa antes da primeira linha. Se eu sei que daqui a um ano ainda vou estar nesse mesmo repositório, apagar a função duplicada deixa de ser trabalho invisível e vira interesse próprio: cada cópia que sobra é uma cópia que eu mesmo vou ter que consertar de novo. O incentivo muda, e o código muda junto. Nada disso é heroísmo. É o que acontece naturalmente quando quem escreve é quem vai manter.

Na Revin, a primeira coisa que a gente faz ao entrar num cliente é ler a base inteira, no Diagnostic Sprint, antes de encostar em qualquer coisa. Duplicação é um dos padrões que aparecem já na primeira leitura: quando lemos 31 bases que chegaram quebradas, um dos números que mais se repetia nem era falha de segurança, era função copiada. Se quiser ver como isso se desfaz num caso real, os cases contam melhor do que eu.

A base de código lembra quem ficou

Toda base carrega a marca de quem passou por ela. Uma base tocada por sete freelancers em série tem a cara do que é: sete pessoas que fizeram um bom trabalho pontual e foram embora antes de aprender que o sistema já sabia mandar e-mail. A culpa não é de nenhuma delas. Faltou alguém que ficasse tempo suficiente para dizer "isso já existe, não escreve de novo".

Se o seu produto já passou por muita gente e você nunca sentou para contar quantas vezes a mesma coisa foi construída, fica o convite: vale meia hora de alguém lendo a base com você, antes que a próxima correção volte pela terceira vez. Quando quiser, é só marcar uma conversa.