Segue abaixo a transcrição de uma conversa sobre refatoração. Claro que teve o consentimento do interlocutor.
Comecei dando 4 motivos para refatorar. Ele replicou e acabou a brincadeira na tréplica. O que está em negrito, foi o que ele respondeu. A minha tréplica está no final de tudo, porque escrevi um texto e não fui respondendo pergunta a pergunta.
[list]Aprender as boas práticas, aumentando a possibilidade de escrever corretamente na próxima vez;[/list]
Aprender boas práticas é obrigação do Programador independente de refatoração. As boas práticas existiram muito antes do que a refatoração.
[list]Em algumas situações, como em if e/ou for aninhados, só vemos com clareza a divisão do código com o mesmo pronto ou semi-pronto. Vemos melhor se precisamos passar parâmtros, retornar alguma coisa, etc. Até com essa característica, apesar de demandar mais treinamento, o código de primeira pode começar a sair mais claro;[/list]
Se o programador for sagaz e consistente no desenho irá enxergar previamente os pontos em que precisa avaliar valores e tomar decisões, sem precisar de chegar ao ponte de ter que escrver o código para depois consertá-lo.
[list]Pegar prática na refatoração ajuda na refatoração de códigos legados;[/list]
Talvez o único ponto que faça sentido desde que o tempo refatorando não seja superior do que simplesmente tratar o código legado.
[list]As vezes, é mais fácil refinar a hierarquia de classes vendo a estrutura pronta. Fica mais fácil de mover um método para outra classe. Introduzir classes abstratas. Acho que assim a abstração fica um pouco mais suave. E é por isso que uma segunda opnião, geralmente, é importante.[/list]
Idem ao ponto 2, se o programador perder um mínimo de tempo desenhando as classes e avaliando a responsabilidade de cada uma não será necessário ficar refatorando infinitamente.
Análise
Após análise vemos que o RUP endereça todos esses pontos com muito mais agilidade e eficácia poi começa com um desenho consistente e o vai refinando a cada interção.
A minha tréplica
[i]Cara, com relação ao RUP, você falou a mesma coisa que eu, só trocou a palavra refatoração por refinamento. O problema do RUP, na minha opnião, é o número excessivo de documentação que no fim, geralmente, se mostram desnecessárias.
Nem sempre, por mais tempo que percamos na análise, conseguimos uma modelagem perfeita. Diria até que quase nunca. É claro que, com experiência, a primeira modelagem melhora. Mas experiência só vem com prática e tempo. O mesmo se aplica para o “programador sagaz”. A refatoração ajuda a memorizar e a experimentar as boas práticas. Dessa forma o programador ve na frente dele como não se deve fazer e como se deve fazer. Com isso identificado, fica mais fácil dele acertar de primeira.
Discordo da sua primeira réplica. As boas práticas são relativamente novas. Antes de meados da década de 90, o importante era fazer código complexo e ilegível. Era mito na época que isso demonstrava a alta capacidade do programador. A necessidade de refatoração sempre existiu. Entretanto, devido ao mito, era dada pouca importância, justamente porque código claro e soluções simples eram coisas de “amadores”.
Geralmente, refatorar e corrigir leva menos tempo que dar manutenção em código mal feito. Além disso, o tempo ganho com as próximas manutenções transformam esse “tempo perdido” em algo irrisório. Mais além, existem códigos que de tão incoerentes e pessimamente escritos, se tornam impossíveis de se manter.
Nunca falei que é necessário refatorar infinitamente. Claro que existe um fim.
[/i]
Não sei se falei muita besteira. Respondi intuitivamente, com o que já estudei até hoje e baseei minhas opniões na “compilação” de tudo que já li até a presente data. Esse diálogo aconteceu há cerca de 1 mês e, ainda, não mudaria um ponto do que disse. Pode ser que o pessoal experiente faça ressalvas. E estarei mais do que pronto a ouvir.
Obrigado.
[EDITADO: Redução de termos que poderiam parecer arrogantes no texto e no título.]
Abraços
