O que aprendi sobre refactoring antes de saber o que era
Tinha um módulo que eu evitava tocar. Em 2019 precisei mexer nele e entendi porque código deteriora — e por que ninguém fala sobre isso no começo da carreira.
Tinha um arquivo Python no projeto que ninguém queria mexer.
Não era secreto. Era tipo... implícito. Quando alguém precisava de algo daquele módulo, copiava a função para outro arquivo e modificava lá. O arquivo original ficava parado, cheio de funções que talvez ninguém mais usasse, com lógica duplicada espalhada pelo resto do projeto.
Em setembro de 2019 precisei mexer nele. Não tinha escolha — o bug estava lá.
O arquivo tinha 400 linhas. Sem comentários. Variáveis com nomes como data2, temp_result, final_val. Funções que faziam três coisas diferentes mas tinham nome de uma só.
Levei mais tempo entendendo o código do que consertando o bug.
Quando terminei, perguntei pro sênior do time: "por que esse arquivo tá assim?" Ele disse: "cresceu". E explicou que no começo era pequeno, simples, funcionava. Aí vieram mudanças rápidas, prazo curto, "vou limpar depois", e "depois" nunca chegou.
Aí aprendi o conceito de dívida técnica antes de aprender o nome.
Refactoring não é reescrever. É esse ponto que me confundiu por muito tempo.
Reescrever é jogar fora e começar do zero. Refactoring é reorganizar sem mudar o comportamento externo. Mesma entrada, mesma saída — por dentro melhor.
O teste que uso até hoje: se eu precisasse explicar essa função para alguém em 30 segundos, conseguiria? Se não, ela provavelmente precisa de atenção.
| Antes | Depois |
|-------|--------|
| data2 = process(data) | normalized_lead = normalize_crm_fields(raw_lead) |
| Função com 80 linhas | 3 funções de 20-30 linhas com responsabilidade clara |
| if x == 1 or x == 2 or x == 3 | if x in VALID_STATUSES |
Parece óbvio quando você vê assim. Não é óbvio quando você está no meio de um prazo.
O que ninguém me contou no começo é que código limpo não é sobre estética — é sobre custo de manutenção.
Código bagunçado é caro porque toda vez que alguém precisa mexer, gasta o dobro do tempo só para entender. Multiplicado por dez pessoas em um ano, o código confuso custa meses de trabalho que nunca aparecem em nenhum relatório.
Hoje quando escrevo código novo, penso: a próxima pessoa que mexer aqui (que provavelmente sou eu em seis meses) vai entender em 5 minutos? Se não, alguma coisa pode ser mais clara.
Não é perfectionism. É gestão de custo futuro.