Refactoring como meio e Design como Fim

Ainda é muito comum discussões sobre refactoring. Mas sinceramente acredito que boa parte delas perderam o ponto a muito tempo. Refactoring como o próprio Fowler disse é uma técnica sistemática para reestruturar código sem mudar o seu comportamento. Sempre que escolhemos uma abordagem de design como por exemplo: DBC, TDD, RDD, DDD, etc.. estamos levando a solução através modelos consolidados. Esses modelos tem prós e contras e dependendo da situação um vai ser melhor do que o outro.

Eu partircularmente gosto muito do modelo do RDD. Mas como chegamos a um modelo solido e eficaz? O design não nasce pronto, deve ser feito de forma incremental utilizando refactoring por exemplo, mas o refactoring não deveria mudar a semantica, logo precisamos de algo mais que refactoring, nesse caso estamos falando de design incremental.

Como fazer um bom Design?

Para fazer um bom design é necessário conhecimento do dominio! Sem conhecimento do dominio é impossível fazer um design robusto e sustentável. Outro fator é fundamental na construção de um bom design é o conhecimento de patterns como do GOF, EAI, EIP, MOM, etc... Outro compomente que ajuda na criação de um bom design é conhecer como boms frameworks foram feitos e segui-los. Um ótimo framework em termos de design é o Spring Framework.



Como eu recomendo que isso aconteça?

Primeiro faça funcionar. Antes de tentar sair aplicando um design mais robusto faça as coisas funcionarem. Ok as coisas estõ funcionando agora faça testes unitários de forma que os testes cubram as coisas que você fez, então agora aplique refactoring e design incremental para melhorar o seu design.

Que ponto se perdeu com refactoring?

Vejo que em muitas discussões sobre refactoring se perdeu o real objetivo que é um método sistemico para que no final das contas nos melhoremos o design. Design não se aplica exclusivamente a métodos e classes.

Onde se Aplica o Design?



Precisamos trabalhar o design em todos esse níveis! Algumas coisas já vem dos requisitos como por exemplo a responsabilidade de cada sistema e outras vão sendo evoluídas ao longo do projeto. Não que essa seja uma tarefa fácil, por que o design vai ficando melhor a medida que você vai conhecendo o domínio mas algumas coisas você pode fazer meio que up to front. Normalmente essas coisas up to front se aplicam a arquitetura e não a regras de negócio.

Duas soluções excelentes para fazer isso são o Spring Framework, claro que você deve utilizar interfaces e classes abstratas e a outras é o Maven, que ajuda a qquebrar e gerenciar diversos jars de dependências em um projeto.


Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java