Saia do Brownfield com Refactoring
Transferir como PPTX, PDF0 gostou38 visualizações
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.
Saia do Brownfield com Refactoring
- 1. Saia do Brownfield Com Refactoring
- 2. egomesbrandao 33 anos Desenvolvedor de software www.egomesbrandao.net/blog twitter.com/egomesbrandao linkedin.com/in/egomesbrandao github.com/egomesbrandao bitbucket.org/egomesbrandao shelfari.com/egomesbrandao
- 3. Greenfield
- 4. Brownfield
- 5. Pareto
- 8. M. Golding “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
- 12. Você sentiu... Code Smell?
- 13. Refactoring
- 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?
- 16. Grace Hopper
- 17. “It’s easier to beg forgiveness than to ask permission.”, Grace Hopper
- 18. Já era hora... Demo!(pelo menos um kata) #comemocao
- 19. E não o contrário
- 23. Medo?
- 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
- 25. Para saber mais
- 26. Mais?
- 27. Obrigado!
Notas do Editor
- #6: Você vai estar 80% da sua vida profissional em softwares existentes Baseado nas estimativas do Gartner 80% do tempo em código Brownfield
- #9: 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
- #11: The Tipping Point by Malcolm Gladwell
- #13: 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
- #14: É 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,
- #16: 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
- #21: Objetivo é reduzier o acoplamento não essencial, sempre haverá acoplamento! Use interface, desenvolva para o comportamento não para a implementação