[quote=pcalcado]Uhm… na verdade as técnicas destes livros aumentam as me´tricas mas não ensinam exatamente como evitar estes problemas. Dois Livros:
[/quote]
Não concordo totalmente. Considero não tanto o catálogo, mas os primeiros capítulos do livro Retoração como os mais importantes.
Ali o autor deixa claro a preocupação e a filosofia por traz de refatorar, dividir e separar o código, de modo a deixa-lo mais modular, limpo e menos acoplado.
Na verdade, o livro propõe a troca (ou o complemento) da abordagem “up-down” para a “bottom-up” para o projeto. Ou seja, ele propõe que também é possível, de maneira um tanto kaizen, sair de um código rebuscado e chegar num código e projeto de qualidade.
Também concordo que isso não é 100% verdade. Cedo ou tarde, você deve quebrar a premissa de que “refatoração não afeta as interfaces” e partir para uma modelagem. Aliás, algumas refatorações em si quebram essa premissa, tão bem explicada no início do livro.
Mas no caso do colega, que já tem um código pronto, muitas vezes é muito interessante começar limpando a casa, refatorando, para depois partir para um projeto de classes e mais elegante.
A questão é difícil. Em termos do que é melhor? Talvez seja conhecer as duas abordagens. São métodos complementares e não excludentes e, portanto, ambos devem ser respeitados.
Eu considero complementares porque, você pode até saber projetar bem, mas nem sempre terá o conhecimento suficiente para fazer isso no início. Nesse caso, é melhor partir logo para um projeto menos eficiente e aprimora-lo através de refatorações, padrões e afins. Por outro lado, mais você também deve saber qual refatoração usar e quando, por exemplo, deve começar a dividir uma classe ou utilizar um padrão. E isso, só o conhecimento sistemico é capaz de te fornecer.