Este post é a tradução de um trecho do post “Dr. Strangecode, or How I Learned to Stop Worrying and Love Old Code” do Chris Boran, em ele que conta como foi descobrir a maravilha que é refatorar!

Castelo de Cartas

Alguns anos atrás, eu estava em minha livraria predileta quando vi o livro “Refactoring: Improving the Design of Existing Code” do Martin Fowler. Este livro mudou a minha carreira. Até então, eu tinha muito medo de mudanças. Eu enxergava o código antigo como um castelo de cartas – se não fosse extremamente cuidadoso, tudo poderia desmoronar. Sempre que meu chefe me pedia uma opinião sobre determinada área de código, minhas respostas eram mais ou menos assim:

O risco de fazer qualquer mudança, por menor que seja, é enorme – então, ou fazemos alguma gambiarra e nos arrependemos mais tarde, ou reimplementamos tudo.

E previsivelmente, a resposta do meu chefe era mais ou menos assim:

Tudo bem, nós podemos conviver com a gambiarra por enquanto, e mais pra frente nós vamos arrumar um tempo pra fazer isso da forma certa.

Evidentemente, a cada release, nós eramos forçados a fazer varias decisões como essas. Quando a próxima release viesse, teriamos como prioridade corrigir código que já estaria em produção. Na prática poderíamos ter sorte e de gastar um montão de tempo reescrevendo um único e pequeno subsistema, mas introduzir pequenas gambiarras, poderiam comprometer outros sistemas. O resultado final é carinhosamente referido como uma “Grande Bola de Lama (Big Ball of Mud)”. Isso mesmo! É tão agradável como parecer ser. A vida pode ser bem miserável quando você sabe que está trabalhando todos os dias apenas alimentando a bola de lama (com + e + gambiarras). Você não gosta disso! Sua equipe não gosta disso! O seu chefe não gosta disso! Mas por algum motivo, você sente que as coisas nunca estam progredindo.

Eu pensava que o código velho precisava ser jogado fora e não re-vitalizado, mas eu queria ver se esse negócio de refectoring funcionava mesmo, então resolvi tentar. Fui bastante cuidadoso para seguir as técnicas exatamente como estavam descritas no livro. Assegurei que não estava usando a palavra refatorar quando eu queria dizer apenas re-escrever. Eu fui cuidadoso para refatorar o código toda a vez que eu queria mudar alguma coisa no código e não apenas procrastinar para mais tarde. Eu me assegurei de que os meus refactorings eram pequenos. E assim fui fazendo…

Obviamente esta forma de trabalhar também exigiu que eu fizesse testes unitários muito bons, mas eu já sabia alguma coisa sobre Test Driven Development e já tinha escrito testes unitários antes de corrigir bugs em uma tentativa de prevenir regressões. Rodar esses testes depois de cada refactroing não foi um desafio tão grande assim pra mim. Pouco a pouco eu fui descobrindo a verdade: Aplicando técnicas de refactoring, eu poderia pegar trechos de código que pensava precisar reescrever completamente e melhorá-los enquanto resolvia bugs. Eu podia matar dois coelhos numa tacada só.

Daí eu descobri o Eclipse. Suas ferramentas de refactoring me incentivaram ainda mais. Encontrei uma forma bem fácil de fazer a maioria dos refactorings mais comuns. Estava comprometido refatorar, e por isso, as taxas de defeito no código que eu escrevia diminuíram drasticamente. Desde então, refactoring tem sido uma técnica essencial no meu dia-a-dia. Agora eu não tenho mais medo de mudar código antigo.