Apenas uma ideia (Jeff Casimir et. Al.)
Aplicativo – UMA proposição de valor (monolítico é uma porcaria)
Módulo – coleção de ideias
Classe – um domínio
Método – um propósito
Linha – um pensamento
Clareza sobre a brevidade: (Jeff Casimir et. Al.)
– Não há mais STI (apenas trilhos)
– Módulo self.included pattern prejudicial por causa de efeitos colaterais => Delegação, Injection ao invés => esclarecer responsabilidade
– Transforme escopos em métodos de classe
– Brevity is efeito colateral da refatoração, não objetivo.
Acoplamento e coesão (Kent Beck et. Al.)
– orientado por probabilidade (quais são as chances de eu mudar a arquitetura do meu servidor de banco de dados, YAGNI)
– Apenas uma ideia pode ser a regra para separação ou fusão de código
– acoplamento mais fraco facilita o teste
– maior coesão deve tornar as coisas mais compreensíveis (localidade das coisas)
Diga, não pergunte (por exemplo, Alec Sharp, Smalltalk by Example, 1997)
– Não pergunte a objetos sobre seu estado, tome uma decisão e diga ao objeto o que fazer; em vez disso, mova este código para o objeto, uma vez que é provavelmente a responsabilidade do objeto
– getters públicos apenas para coletar informações sobre o estado do objeto, mas não para basear decisões
– cheiro de código ou sinal de falta de coesão, acoplamento excessivo (entre “perguntar” chamador e objeto “contado”)
– inveja de recursos, já que a funcionalidade provavelmente pertence ao objeto para maior coesão e responsabilidade clara
– quebrar a lei de demeter pode ser um sinal para isso (também conhecido como alcançar objetos getters ou mesmo subobjetos, “tree.apples. maduro.primeiro. comer! “)
Padrões de design como caixa de ferramentas (Martin Fowler et. Al.)
– a maioria dos problemas já foram resolvidos por alguém
– não apenas por causa do padrão, mas como regra para uma melhor estrutura do código em evolução
– prazos para refatoração
– refatoração inicial como prática de melhorar as habilidades e reduzir o débito técnico, aumentar ainda mais a flexibilidade, agilidade para mudanças e adaptações funcionais
=> Faça a implementação desaparecer, mais perto da linguagem natural / do que você está fazendo.
=> Código naturalmente legível torna a refatoração muito mais fácil. Portanto, primeiro passo: tente explicar nomeando o que o código está fazendo (ou deveria). Sempre que isso for difícil ou muito geral ou implicar em ExtractMethod / ExtractClass, terá-se um ponto de partida para uma refatoração.