Em primeira análise, a refatoração exige uma boa dose de pensamento, mas a realidade é que pensar demais também pode ser prejudicial. Esta é opinião de Kent Beck e J.B. Rainsberger.
Kent Beck sugere que um dos desafios da refatoração é o sequenciamento, ou seja, como dividir o trabalho em passos seguros e ordenar esses passos. Avançar rápido demais nas refatorações pode resultar em código instável. Por outro lado, pensar demais pode tornar o processo mais lento que o aceitável.
Meus colegas de programação são testemunhas do meu hábito irritante de dizer "pare de pensar" durante a refatoração. Eu sempre soube que isso não é exatamente o que eu quero dizer, porque afinal não se pode parar de pensar literalmente. Mas até agora eu não tinha uma explicação melhor.
Kent explica o conceito de "refatoração horizontal e vertical". A refatoração vertical envolve ações como mover o método ou atributo para cima ou para baixo numa pilha de invocações; na refatoração horizontal se faz algo similar entre itens no mesmo nível. Para Beck, ao refatorar não se deve misturar os dois tipos de refatoração.
Quando se tem várias invocações para refatorar, ou várias implementações, é o momento de ter cuidado para evitar a alternância entre a refatoração vertical e a horizontal. Deve-se manter os dois tipos separados e ficar atento à profundidade das refatorações verticais.
Mas fazer isso não é fácil. Algo que pode se particularmente útil, diz Beck, são os cartões indexados.
Manter um cartão perto do meu computador me ajuda a manter o foco. Quando vejo uma oportunidade de refatoração vertical no meio de uma fase horizontal (ou vice-versa), anoto a ideia e volto para o que estava fazendo. Isso me permite terminar uma tarefa antes de partir para a próxima, sem perder nenhuma boa ideia. É um processo que lembra a meditação, em que você se concentra na respiração e não se deixa levar pela espiral dos próprios pensamentos.
Nos comentários, J. B. Rainsberger concorda e acrescenta:
Não importa no que você está trabalhando: se quer ter foco, tenha uma caneta e um cartão por perto. Quando surgir algo na sua cabeça que não for necessário fazer imediatamente, anote a ideia em cinco palavras ou menos e volte para o que estava fazendo. Funciona muito bem.
Em princípio, isto é bem semelhante à abordagem de "mudanças estreitas" (narrow changes) sugerida por Joshua Kerievsky. Nela, o foco é restrito a um pequeno número de pontos de mudança de cada vez; em seguida usa-se essa informação para selecionar a próxima mudança (estreita ou paralela) para a refatoração.
Portanto, refatorar envolve (claro) o pensamento, mas manter o foco é essencial para refatorações saudáveis. Nas palavras de Beck:
Na metade do caminho, meu colega começou a ter boas ideias de como mover parte da funcionalidade. Neste ponto disse a ele para parar de pensar. Na verdade, só queria que focasse no que estávamos fazendo. Não faz sentido começar a fixar uma estaca (no alpinismo) e parar na metade para verificar onde colocar a próxima estaca.
boa!
by camilo lopes,
Ótima abordagem
by Bruno Arueira,
boa!
by camilo lopes,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
realmente, muito bom bom essa visão do Kent. E ele trouxe alguns momentos que entrei nessa confusão quando estava refatorando. Realmente, quando temos que fazer grandes refatorações, ir rápido demais ou pensar muito atrapalha de fato, perdemos o foco e daí temos um terreno bem fácil, para nascer aqueles bugs, que o código ainda funciona, mas é um bug que só será descoberto bom tempo depois. realmente foi um bom post :)
Ótima abordagem
by Bruno Arueira,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Realmente, muitas vezes por tentarmos abstrair demais as coisas e torná-las mais reutilizáveis estamos na verdade ficando num ciclo vicioso de refatorar excessivamente a ponto que acontece o que foi demonstrado, refatorar algo que já está sendo refatorado.