Todas As Coisas Tem Nome

Por que eu parei de aceitar nomes genéricos em sistemas

Eu trabalhava num projeto de integração de bancos de dados há uns anos quando precisei rastrear uma falha que aparecia apenas em produção e nunca no ambiente de homologação. O problema era simples: existiam trezentos e sessenta e dois objetos chamados "registro_01", "registro_01 (cópia)", "registro_final" e coisas parecidas, espalhados por três schemas diferentes. Cada um deles tinha comportamento distinto porque vinha de origens diferentes, mas o nome não refletia nada disso. Tive que passar um fim de semana inteiro mapeando campos técnicos para entender qual era qual. Nada de dramático, só perda de tempo real. Isso me ajudou a enxergar que todas as coisas tem nome e que o nome errado é pior do que não ter nome nenhum. Quando você dá um rótulo vago para algo específico, cria a ilusão de que entende o sistema. Na prática, só criou mais work para o próximo cara.

todas as coisas tem nome: como fazer isso funcionar na vida real

Primeiro, a parte prática. Eu uso um padrão de nomenclatura baseado em quatro componentes: origem + entidade + atributo discriminador + versão ou sufixo contextual. Um arquivo de exportação da SAP viraria "sap_notafiscal_554821_v2.csv". Um registro duplicado corrigido manual_mente viraria "crm_lead_44201_manual_fix". Um snapshot de banco de dados seria "db_users_backup_20241103". O formato é sempre assim: fonte, o quê, qual variação, quando ou como chegou ali. Segundo, a parte que ninguém conta. O maior erro não é nomear errado. É nomear tentando prever usos futuros. Eu vi gente criar convenções nominais com dezenas de campos aninhados que ninguém lia. O nome ficou tão completo que nem os autores recordavam o significado depois de três meses. A regra prática é simples: um nome serve para quem precisa identificar algo rapidamente, não para quem quer documentar a história completa daquele objeto. Se o nome precisar de manual de interpretação, ele já falhou.

Terceiro, um exemplo concreto que aconteceu comigo. Tinhamos um job de ETL que processava feeds de parceiros. Cada feed vinha como "arquivo_importacao.txt". Havia seis parceiros, e três deles enviavam formatos ligeiramente diferentes dependendo do período do ano. Eu resolvi renomeando tudo com base no partner_id, no tipo de feed e na data de processamento, gerando automaticamente nomes como "partner12_pf_vendas_diario_20241105.parquet". A mudança levou uma tarde. A depuração que antes levava seis horas passou a levar quinze minutos em média. O ganho não foi mágico, foi apenas remover ambiguidade. Quarto, limitações. Esse sistema não funciona bem em ambientes extremamente dinâmicos onde os objetos mudam de natureza com frequência. Se um registro nasce como lead, vira oportunidade, depois contrato e por aí vai, um nome fixo baseado na origem pode criar mais confusão do que solução. Nesses casos, o mais honesto é usar identificadores técnicos imutáveis e reservar os nomes legíveis para visualização, não para lógica interna. Não adianta forçar um padrão que o domínio não sustenta.

Quinto, uma prática que eu adotei e recomendo. Antes de validar qualquer nome novo, faça o teste dos trinta segundos. Mostre o nome para alguém que não conhece o sistema e pergunte o que aquela coisa faz. Se a resposta for um palpite ou um "acho que é...", o nome não funciona. Ajuste até a resposta ser direta. Eu faço isso em every review de naming de projeto, e já evitou pelo menos meia dúzia de problemas sérios. Sexto, ferramentas. Eu uso scripts básicos de validação de nomenclatura em Python que varrem diretórios inteiros e apontam violações: nomes que não seguem o padrão, duplicatas, caracteres especiais e comprimento fora da faixa aceitável. Rodar o script leva uns doze segundos em uma pasta com milhares de arquivos. A revisão manual que eu fazia antes levava cerca de quarenta minutos. A diferença é bruta.

Se você precisa de um ponto de partida, um repositório simples com os regex de validação e um README com exemplos práticos pode ser encontrado em vários repositórios públicos. Eu costumo começar com o padrão do projeto atual, copiar, ajustar as regras e rodar o script de auditoria antes de qualquer merge. Não é solução perfeita, mas elimina a maior parte dos erros óbvios antes que virem dor de cabeça. O resultado final é quase sempre o mesmo: depois de duas semanas de ajuste, o sistema de nomes se torna invisível. Você para de pensar neles e começa a trabalhar direto com o conteúdo. Esse é o indicador de que o padrão está funcionando. Se você ainda pensa nos nomes todo dia, algo ainda não está resolvido.