Li um artigo interessante sobre refactoring escrito pelo Marcos Tapajós. Ele fala sobre como o dito popular "em time que está ganhando não se mexe" não nos encoraja a continuar evoluindo.
Especificamente no desenvolvimento de software a técnica de refactoring, muitas vezes é aplicada em "código que está ganhando", mas que pode melhorar.
Sem dúvida temos que quebrar este costume de não mexer em código que funciona. Eu tinha um colega que costumava a brincar falando "está funcionando? Tira a mão do teclado para não estragar!". Esta brincadeira mostra a cultura comum, porém errada, que temos em nosso meio.
Mas existem alguns pontos importantes nesta discussão (Estes são apenas pontos de atenção e não argumentos contra o refactoring):
Segurança versus Coragem
Mais do que coragem é necessário ter segurança para refactorar um código que está atendendo o usuário. E segurança vem de uma boa cobertura em testes automatizados. Um checkin deve SEMPRE deixar o produto melhor ou igual ao que estava antes. Então se o risco de você adicionar bugs ao produto fazendo refactorings é alto, eu sugiro que você não faça até ele ser necessário.
Não existe almoço grátis
É uma frase famosa de um economista falando sobre o capitalismo. Do mesmo jeito que não existe almoço grátis, também não existe refactoring grátis. Existe um custo, que deve sempre ser avaliado. Aquela "uma horinha" fazendo um refactoring poderia ser utilizada em outra tarefa, portanto devemos sempre tomar decisões racionais: "é melhor refactorar aquele trecho de código, do que gastar esta hora naquela feature que está no product backlog..."
Design é um ciência não determinística
Eu li isto no code complete, do Steve McConnell. O que ele quer dizer é que o mesmo problema pode ser resolvido de diversas formas e provavelmente cada desenvolvedor vai escolher uma diferente. Até mesmo você é capaz de mudar de opinião olhando seu código no dia seguinte. É necessário saber a hora de parar.
Qualidade de código versus estilo de código
Esta é complicada, cada um tem seu estilo de código. Você pode amar "switch" e odiar "if-elseif", porém isto é uma questão de estilo, não existe argumento forte o suficiente para gastar tempo trocando cada statement if-else por switch.