O documento discute refatoração de código existente (brownfield) através de testes para introduzir mudanças com segurança. Apresenta breve biografia do autor e conceitos-chave como code smell, princípio de Pareto e citações sobre mudança e teste de Grace Hopper.
15. Feathers
e o risco da mudança:
Quais as mudanças que temos que
fazer?
Como vamos saber que fizemos
corretamente?
E como vamos saber se não
quebramos nada?
24. "Humans are allergic to
change. They love to say,
'We've always done it this
way.' I try to fight that. That's
why I have a clock on my wall
that runs counter-clockwise.",
Grace Hopper
Você vai estar 80% da sua vida profissional em softwares existentes
Baseado nas estimativas do Gartner 80% do tempo em código Brownfield
Você já sentiu vontade de torcer o pescoço de um colega que talvez você nem saiba quem é?
Pode ter sido seu atual chefe quando era dev que codificou isso
The Tipping Point by Malcolm Gladwell
Divergent change: a classe é alterada de diferentes formas, fazendo coisas demais, extraia uma ou mais classes
Shotgun surgery: é preciso fazer diversas alterações para uma única mudança, o que sugere que a lógica está espalhada pelo código, encapsule em uma classe
Feature envy: um método está mais interessado em em dados de outra classe do que na própria classe, extraia e mova
Data clumps: grupos de dados, vários parâmetros que aparecem sempre juntos: objeto de parâmetros
Primitive obsession: números de telefone ou CEP
Switch statements: quase sempre substituível por polimorfismo
Lazy class: classe perdida
Speculative: provável funcinalidade algum dia (falar do campo genérico do banco de dados que acomoda vários campos)
Temporary Field
É um processo de mudança no código de um software de uma forma que não altere o comportamento
Se você não sabia o que é, você já fez Refactoring sem perceber, ao alterar o nome de uma variável para melhorar a legibilidade do código,
Medo da mudança
“Se não está quebrado não consete”
Não sabe como então copie, cole e crie um novo com outro nome
Você fica o tempo todo tentando evitar o problema, fugindo dele...
Só que fazer vai melhorar seu conhecimento, auto-estima do time, e principalmente o seu futuro trabalho
Objetivo é reduzier o acoplamento não essencial, sempre haverá acoplamento! Use interface, desenvolva para o comportamento não para a implementação