Código em produção não pertence mais ao programador

Código em produção deixa de ser seu depois do deploy.

TL;DR

• O usuário, o empresário, o financeiro e o suporte passam a depender de comportamento que parece detalhe para você.
• “Refazer tudo” quase sempre custa mais do que preservar compatibilidade.
• Código em produção é rotina de gente — e muda de dono: depois do deploy, deixa de ser seu.

~ 5 min de leitura · 898 palavras

No desenvolvimento, o código é seu. Em produção, não.

Eu escrevi essa frase pela primeira vez há 25 anos, mantendo um ERP em produção. Durante o desenvolvimento, o código ainda não é código em produção — parece uma extensão do programador: você escolhe a arquitetura, os nomes, os padrões. É seu, no bom sentido.

Quando o sistema entra em produção, essa propriedade se dissolve. Quem passa a “dono” do comportamento são as pessoas que usam:

• O usuário pensa no trabalho dele — se hoje ele emite uma nota em três cliques, mudou para cinco, o dia dele piorou.
• O empresário pensa na operação — o fluxo que você achou elegante pode quebrar a rotina da loja — código em produção é rotina de gente, não artefato.
• O financeiro pensa nos números — alterou a ordem de cálculo, o relatório do contador muda.
• O suporte pensa no que quebra — cada mudança em código em produção é um ticket em potencial.

Na minha visão, isso é a maior mudança de estatuto que um código sofre na vida dele: código em produção pertence à operação, não a quem o escreveu.

Uma decisão tecnicamente elegante pode ser operacionalmente péssima. E o contrário também vale: uma solução feia, mas previsível, frequentemente sustenta uma empresa inteira. Eu não entregaria em produção nenhuma alteração que eu não soubesse explicar em termos de operação — só de técnica.

Desenvolvimento versus produção

No desenvolvimento, o código em produção ainda não existe: o sistema é hipótese. Em produção, ele vira hábito.

Eu já reescrevi rotinas achando que estava melhorando, e descobri que operadores de caixa tinham decorado a sequência de telas. A mudança era objetivamente superior — e ainda assim virou problema, porque quebrou memória muscular de dezenas de pessoas.

Experiência vivida: em décadas de manutenção do Posseidom, o código em produção que mais dói mexer nunca é o mais feio. É o que mais gente depende sem saber.

Elegância técnica versus necessidade empresarial

Lugar-comum do desenvolvedor: “isso precisa ser refatorado”. Mas refatorar é meio, não fim — em código em produção, toda mudança tem cliente.

Duas perguntas que eu faço antes de qualquer alteração em sistema em produção:

1. O que a empresa ganha com isso em dinheiro ou tempo? 2. O que ela perde durante a transição?

Se a resposta da segunda é maior que a da primeira, a refatoração espera. Sistema não é vitrine de técnica — é infraestrutura de trabalho de gente real.

O custo de alterar código em produção conhecido

Compatibilidade é valor, não é dívida. Quando você muda o comportamento de uma tela que mil pessoas usam todos os dias, você cobra dessas mil pessoas um custo de reaprendizado que ninguém aprovou. Toda mudança de código em produção cobra esse juro.

O caso concreto mais parecido com o post anterior: em produção, uma tela velha que “ninguém usa” — até você mudar e descobrir que um cliente montou treinamento interno, macro de planilha e checklist em cima dela.

Usuários criam processos em volta do sistema

Parte disso é bom: usuários que dobram o sistema a favor deles conhecem o negócio melhor que qualquer engenheiro. Parte é armadilha: o processo não está no sistema, está na cabeça deles.

Quando você altera uma regra, não está mudando só software. Está mudando o processo que o software atravessa. Por isso, antes de mexer em qualquer regra conhecida, eu converso com quem usa. Pergunta que funciona:

• “O que você faria diferente se essa tela mudasse amanhã?”
• “Algum outro sistema ou planilha depende desse resultado?”

Por que “vamos refazer tudo” costuma ser perigoso em produção

Todo sistema velho carrega em si anos de decisões que funcionam — em código em produção, cada linha pode ser regra de negócio viva. Refazer tudo é apostar que você consegue reextrair esse conhecimento antes do prazo acabar.

Eu já vi migrações virarem tragédia por esse motivo exato: foi substituído o que ninguém entendeu que era regra de negócio. Modernização que respeita mais o que o sistema já acertou.

O papel do desenvolvedor sênior

O sênior não é o que escreve o código mais bonito. É aquele que sabe estimar o custo operacional de cada mudança, para quem cada alteração vai doer, e o que fazer para doer menos.

Isso significa: ler o sistema antes de julgar, conversar antes de decidir, versionar em vez de substituir. É menos glamuroso. É o que diferencia código entregue de código que sobrevive.

Leitura relacionada

• Seu banco de dados sabe mais sobre sua empresa do que a documentação — cada estrutura antiga esconde uma decisão que ninguém mais sabe explicar.
• Sistema legado não é sinônimo de sistema inútil — código antigo em produção significa código que a empresa inteira aprendeu a confiar.
• IA na modernização de sistemas legados — por que modernizar bem começa por entender, e não por reescrever.

Em produção, o melhor código não é o mais moderno: é o que mantém o trabalho de todo mundo acontecendo. Minha regra, depois de décadas de ERP: eu não troco comportamento conhecido por elegância sem conseguir explicar o ganho operacional para quem usa e sem pagar o custo de transição que essa troca impõe. Compatibilidade não é fraqueza técnica. É maturidade de quem já viu sistemas reais sustentarem empresas inteiras por décadas.