"Tudo num arquivo só: por que \"um simples ajuste vira pesadelo\" e como separar sem reescrever"

"No projeto da postagem toda a lógica, os componentes e os estilos de cada tela estão misturados dentro de um único arquivo. [...] Um simples ajuste pode virar um pesadelo porque você não sabe onde mexer sem correr o risco de quebrar algo."

É um comentário no TabNews, olhando um app feito com IA. Já usei essa fala aqui pra ensinar a encolher o pedido, e o pedido pequeno resolve metade do problema. A outra metade é o arquivo: se tudo mora junto, até o pedido pequeno cai no meio de tudo.

Este post é a outra metade. O que tem dentro desse arquivo, o que separar primeiro e o pedido que separa sem reescrever uma linha.

Não foi você que bagunçou

Ninguém escolheu pôr tudo num arquivo. Ele cresceu assim. O primeiro pedido foi "uma tela de orçamento", e a IA fez a tela inteira num lugar só, o que no dia 1 era razoável: eram 80 linhas. Aí vieram o desconto, o PDF, o campo de observação, a cor do botão. Cada pedido acrescentou um pedaço no mesmo lugar, porque é onde a tela já estava. Ninguém disse "isso aqui vai em outro arquivo", então não foi.

Quem programa separa por reflexo, porque já se queimou. Você não se queimou ainda, ou está se queimando agora. É só isso.

O mapa: três coisas que moram juntas

Abra o arquivo grande na cabeça como se fosse uma gaveta. Dentro tem três tipos de coisa misturados:

1. O que decide (a lógica). O cálculo do total, a regra do desconto, a conferência de "esse horário está livre". É o que o seu negócio é. Errou aqui, o cliente paga o valor errado.

2. O que aparece (os componentes). Componente é um pedaço de tela com nome: o cartão do cliente, o formulário, o botão de salvar. Quando ele mora solto no arquivo, aparece copiado em três telas, e você conserta uma cópia só.

3. Como aparece (o estilo). Cor, tamanho, espaçamento. Errou aqui, fica feio. Não fica errado.

Repare na ordem de gravidade: lógica, componente, estilo. É a mesma ordem da separação. Se você já leu o mapa das peças que se puxam, isso é o mesmo desenho visto por dentro de um arquivo só: a regra é a camada que puxa mais coisa, então é a primeira que ganha casa própria.

Separar não é reescrever

Isso tem nome em programação: refatorar. A definição do Martin Fowler, que escreveu o livro de referência sobre o assunto, é mudar a estrutura interna do código "sem mudar o seu comportamento externo". E ele acrescenta duas coisas que são a regra deste post: é feito em uma série de transformações pequenas, e o sistema fica funcionando inteiro depois de cada uma.

Traduzindo: mover, não melhorar. O cálculo sai do arquivo grande e vai pra um arquivo dele, exatamente igual. Se a IA "aproveitar pra melhorar", não é mais separação, é reescrita escondida, e reescrita é onde mora a quebra.

Faça hoje: a primeira mudança de gaveta

1. Ache o arquivo. No modo que conversa sem mexer no código (no Lovable, o Plan; pela documentação, nele a IA investiga e escreve um plano que você aprova antes de qualquer mudança):

Não altere nada. Liste os 5 maiores arquivos do projeto,
com o número de linhas de cada um. Para o maior, diga em
palavras simples o que tem dentro: quais cálculos e regras,
quais pedaços de tela, quanto é estilo.

Acima de umas trezentas linhas misturando cálculo e tela, eu já desconfio. Não é regra oficial, é calo.

2. Marque o ponto de retorno. Antes de mover qualquer coisa. No Lovable, favorite a versão atual no histórico; com o código na máquina, o commit do git.

3. Escolha UMA regra. A que mais importa pro dinheiro: o cálculo do total, quase sempre. Uma só.

4. Peça a mudança cercada:

Mova o cálculo do total do orçamento para um arquivo novo,
só dele. A tela continua usando esse cálculo, agora a partir
do arquivo novo.
Não mude nenhum comportamento, nenhum texto, nenhuma cor.
Não corrija nem melhore nada no caminho. Se achar algo
errado, me avise no fim, sem mexer.
No fim, liste os arquivos que mudaram.

A documentação do Lovable diz que edição pequena e focada costuma custar menos crédito que mudança grande. Aqui o barato e o seguro coincidem.

5. Confira. Duas coisas. A lista de arquivos tem que ter dois: o grande (que perdeu um pedaço) e o novo. Se apareceu um terceiro, pergunte por quê antes de aceitar. Depois, rode o teste de 5 cliques e faça um orçamento com o mesmo valor de antes. O total tem que dar igual, centavo por centavo. Deu diferente, volte pro ponto do passo 2.

Uma regra por dia. Em duas semanas, as regras que valem dinheiro moram cada uma na sua casa, e "mexe no desconto" vira mexer num arquivo de quarenta linhas, não num de novecentas.

O que fica pra depois

Os componentes repetidos são a segunda leva, no mesmo formato: um por pedido. O estilo é o último, e às vezes nem precisa. Arquivo feio que só tem estilo dentro não quebra regra de ninguém.

Era uma gaveta de várias

Separar tira a bagunça que já existe. Não impede a próxima: sem ninguém dizendo "cálculo vai em arquivo próprio", a IA volta a juntar no pedido seguinte. Isso se resolve com uma linha no arquivo de regras do projeto. E a regra que agora mora sozinha é a candidata perfeita pro primeiro teste automático, porque dá pra provar que ela continua certa sem clicar em nada.

Separar, cercar, provar. Três paredes vizinhas, e nessa ordem. A de hoje é uma regra só, movida sem mudar nada.

Fontes

• Comentário em post de FelipeBarso, TabNews, sobre um app feito com IA (registrado na pesquisa do blog, pesquisa/01-dores-nao-devs-br.md; é relato, não estatística)
• Refactoring.com, Martin Fowler (definição: mudar a estrutura interna sem mudar o comportamento externo, em pequenas transformações, com o sistema funcionando depois de cada uma): https://refactoring.com/
• Lovable — Plan mode (a IA investiga e escreve um plano; o código só muda depois da aprovação): https://docs.lovable.dev/features/plan-mode
• Lovable — FAQ (edições pequenas e focadas costumam custar menos que mudanças maiores): https://docs.lovable.dev/introduction/faq