Blog/Artigos · Engenharia
A definição de Martin Fowler, a metáfora da dívida de Ward Cunningham, os code smells, os passos pequenos sob a rede de testes e a regra do escoteiro.
No livro dos Reis, o rei Yehoash organiza a coleta para reparar a fenda da casa, o Templo que se deteriorava com o tempo. Não era construção nova; era manutenção da estrutura existente, feita com regularidade, para que a casa não ruísse por descuido acumulado. Todo sistema de software é essa casa. A cada prazo apertado, a cada atalho, surge uma fenda: um trecho duplicado, um nome confuso, uma abstração que vazou. Sozinha, cada fenda é pequena; ignoradas, elas se somam até a casa ficar perigosa de habitar. Refatorar é reparar a fenda da casa continuamente, mudando a estrutura por dentro sem mudar o que ela faz por fora, para que o software não chegue ao ponto em que só resta derrubá-lo e começar do zero.
Refatoração tem uma definição precisa, e ignorá-la causa metade da confusão sobre o tema. Martin Fowler, no livro que deu nome à disciplina, define refatorar como mudar a estrutura interna do código sem alterar seu comportamento externo. Essa segunda parte é a que importa: o que o sistema faz permanece idêntico; só o como fica mais limpo. Refatorar não é adicionar feature, não é corrigir bug, não é reescrever. É melhorar o desenho do que já funciona, mantendo-o funcionando exatamente igual, verificável pelos testes que continuam passando.
Essa distinção é o que torna a refatoração segura e o que a separa da reescrita perigosa. Como o comportamento não muda, cada passo pode ser verificado: refatorou, rodou os testes, tudo verde, o comportamento se manteve. É reparar a fenda da casa com a casa habitada, sem derrubar parede mestra. A alternativa que muitos escolhem por desespero, reescrever do zero, é quase sempre um erro: joga fora anos de conhecimento embutido no código, subestima a complexidade escondida, e produz um novo sistema com bugs novos enquanto o antigo, imperfeito, ao menos funcionava. Refatorar continuamente é o que evita chegar ao ponto onde a reescrita parece a única saída.
| Atividade | Muda o comportamento? | O que é |
|---|---|---|
| Refatorar | não, o externo é idêntico | melhorar a estrutura interna do que já funciona |
| Adicionar feature | sim, faz algo novo | outra atividade; não misturar com refatoração |
| Corrigir bug | sim, muda o comportamento errado | outra atividade; refatore antes ou depois, separado |
| Reescrever do zero | sim, e arrisca tudo | joga fora o conhecimento embutido; quase sempre erro |
Ward Cunningham cunhou a metáfora mais útil da engenharia: dívida técnica. Escrever código apressado para entregar rápido é como pegar dinheiro emprestado, você ganha velocidade agora e paga com juros depois, na forma de manutenção mais lenta e mudanças mais arriscadas. A metáfora é poderosa porque captura que a dívida nem sempre é ruim: às vezes vale a pena contrair dívida deliberada para atingir um prazo de mercado, desde que se saiba que ela existe e se planeje pagá-la. O veneno é a dívida que ninguém reconhece nem paga, cujos juros se acumulam até consumir toda a capacidade de entregar.
Martin Fowler refinou a metáfora num quadrante, cruzando se a dívida foi deliberada ou inadvertida com se foi prudente ou imprudente. A dívida deliberada e prudente, sabemos que estamos cortando este canto e vamos consertar depois, é gestão legítima. A imprudente e inadvertida, não sabíamos que havia um jeito certo e nem percebemos que erramos, é a pior, porque nasce da falta de conhecimento e se acumula invisível. Nomear a dívida, torná-la visível num registro, com o juro que ela cobra, é o que permite decidir conscientemente quando pagá-la, em vez de descobrir sua existência só quando a entrega já travou e ninguém sabe por quê.
Fowler catalogou os code smells, os cheiros de código: sinais na superfície que sugerem um problema estrutural embaixo. Não são bugs, o código funciona, mas indicam que a estrutura vai doer na próxima mudança. Método longo demais, classe grande demais fazendo coisas demais, lista longa de parâmetros, código duplicado espalhado, inveja de recurso quando um método usa mais dados de outra classe que da sua. Cada cheiro tem uma refatoração conhecida que o resolve, e reconhecer o cheiro é o gatilho para aplicá-la.
O valor dos smells é dar nome ao desconforto. Todo engenheiro experiente sente quando um código está errado antes de conseguir explicar por quê; o catálogo de cheiros transforma esse instinto em vocabulário compartilhado e acionável. Ver duplicação em três lugares deixa de ser um incômodo vago e vira extrair o comum. Ver uma classe que só cresce vira separar responsabilidades. Os smells conectam o SOLID, que diz como o código deveria ser, à refatoração, que diz como chegar lá a partir de onde está. Eles são a fenda visível na parede: o sinal de que é hora de reparar, antes que a fenda vire buraco.
A refatoração segura tem um método, e ele depende de duas coisas: passos pequenos e rede de testes. Passos pequenos porque cada micro-refatoração, renomear uma variável, extrair um método, é reversível e verificável na hora; um passo grande demais mistura mudanças e, se algo quebra, não se sabe qual. Rede de testes porque é ela que prova, a cada passo, que o comportamento não mudou. Refatorar sem teste é reparar a casa no escuro: você pode estar consertando uma fenda e abrindo três. Por isso teste vem antes: sem a rede, a refatoração vira aposta.
A prática que mantém a casa reparada sem projetos heroicos de refatoração é a regra do escoteiro: deixe o código um pouco melhor do que o encontrou. Não é parar tudo para uma grande limpeza; é, a cada vez que você toca num trecho por outro motivo, melhorar uma coisinha de passagem, um nome, uma extração pequena. Somadas, essas melhorias contínuas mantêm a casa em ordem sem nunca exigir a reforma dramática. É a diferença entre a manutenção regular do Templo, que Yehoash instituiu, e deixar a fenda crescer até precisar de uma campanha de reconstrução. A dívida técnica se paga melhor em prestações pequenas e constantes do que num grande esforço que nunca chega.
A relação com dívida e refatoração amadurece da negação à gestão. No começo a dívida é invisível e ninguém refatora, a casa apodrece até a crise. Depois vem a refatoração heroica, o grande projeto de limpeza que para tudo, raramente termina e frustra a todos. No meio vem a rede de testes que torna refatorar seguro. No topo é a refatoração contínua, integrada ao dia a dia pela regra do escoteiro, com a dívida visível num registro e paga em prestações conscientes. Cada degrau troca a crise inevitável pela manutenção regular, mais barata e menos dolorosa.
Refatoração é o tecido conjuntivo deste eixo. Ela depende dos testes, que dão a rede; realiza o SOLID, movendo o código real na direção dos princípios; aplica os design patterns, introduzindo-os onde o cheiro pede; e viabiliza tudo o mais, porque nenhum sistema evolui sem a manutenção que a mantém maleável. A metáfora do Templo é exata: a casa que se repara continuamente dura séculos; a que se deixa apodrecer precisa ser derrubada. Reparar a fenda da casa, em prestações pequenas e constantes, sob a rede que prova que nada quebrou, é a disciplina sem glamour que decide se o software envelhece com dignidade ou vira o legado que todos temem tocar.
Refatoração é reparar a fenda da casa, como Yehoash mandou fazer no Templo: mudar a estrutura por dentro sem mudar o que ela faz por fora, em passos pequenos, sob a rede de testes que prova que nada quebrou. A dívida técnica de Ward Cunningham cobra juros, e o quadrante de Fowler distingue a dívida legítima da venenosa; os code smells dão nome ao desconforto; e a regra do escoteiro paga a dívida em prestações. A IA fareja o cheiro e executa a micro-refatoração. Mas decidir qual desenho é melhor, e quando a dívida vale a pena por prazo, continua sendo julgamento de quem responde pela casa.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaבְּחִינָה
Sem teste, toda mudança é uma aposta no escuro e o medo trava a evolução. Teste automatizado é a rede que devolve a coragem de mexer. A pirâmide diz onde investir, o TDD usa o teste como pressão de design, e a lição dura é que cobertura não é confiança.
Engenhariaאֵין חָדָשׁ
O problema de projeto que você enfrenta hoje já foi resolvido mil vezes. Design patterns são as formas conhecidas dessas soluções recorrentes, catalogadas pela Gang of Four, e seu maior valor não é o código, é o vocabulário que faz o time inteiro entender uma ideia dizendo uma palavra.
