[RubyConfBR 2017] Refatorando Rails apps com confiança

Transcript

1. Flavia Fortes
3. ESTAMOS CONTRATANDO! http://careers.plataformatec.com.br
4. Refatorando Rails apps com confiança
5. 1. Quando fazer
6. 1. Quando fazer 2. O que não fazer
7. 1. Quando fazer 2. O que não fazer 3. Um pouco do que fazer
8. @flafortes
9. Quais as motivações?
10. • Melhorar design do código para facilitar adições e extensões
11. • Satisfação em deletar código
12. Vida real • Cobrança por entrega
13. Vida real • Cobrança por entrega • Projeto com deadline
14. Vida real • Cobrança por entrega • Projeto com deadline • Bugs em produção
15. Vida real • Cobrança por entrega • Projeto com deadline • Bugs em produção • Problemas de performance
16. Refatoração reativa
17. Impactos: • Trabalhoso
18. Impactos: • Trabalhoso • Demorado
19. Impactos: • Trabalhoso • Demorado • Difícil de testar
20. Impactos: • Trabalhoso • Demorado • Difícil de testar • Pode não entregar valor para o usuário final
21. Então, como evitar refatoração reativa?
22. Refatorando sempre, aos poucos, ativamente.
23. Quais são os sinais do dia-a-dia que me indicam quando eu preciso refatorar meu código?
24. Code smells
25. Métodos muito longos
26. Métodos com muitos parâmetros
27. Métodos que usam mais dados de outro objeto (Feature envy)
28. O que costumamos fazer?
29. Extraímos lógica para outros métodos menores
30. Models gigantescos
31. Muitos testes unitários, suite de testes cada vez maior.
32. O que não costumamos fazer?
33. Pensar nas nossas classes com poucos métodos públicos e muitos métodos privados.
34. Pensar na nomenclatura da API pública das nossas classes com carinho.
35. Código mais legível é menos complexo
36. Classes gigantes
37. Classes com muitas propriedades
38. O que costumamos fazer?
39. Concerns
40. "Any application with an app/concerns is concerning."
41. Composição > Herança
42. Service Objects
43. "The wrong object causes more trouble than no object at all." - Avdi Grimm
44. Enough with the service objects already https://avdi.codes/service-objects/
45. O que não costumamos fazer?
46. Extrair classes ruby puras
47. Classes de domínio != Classes utilitárias
48. Single Responsibility Principle
49. "A class should do the smallest possible thing." - Sandi Metz
50. Código complexo nas views
51. O que costumamos fazer?
52. Presenters (Decorators)
53. "Cleaning up view code does not mean hiding it in another folder."
54. Thoughts about Rails Presenters https://gist.github.com/somebox/5 a7ebf56e3236372eec4
55. YAGNI (You ain't gonna need it) • think of better abstractions? • consider different naming? • maybe you just need a new model?
56. Código duplicado
57. DRY Don't Repeat Yourself
58. Vale lembrar: Em testes, código duplicado não é necessariamente algo ruim!
59. Alerta de polêmica: Comentários no código
60. "Comments are always failures" - Robert C. Martin
61. Comentários vs Documentação
62. Queime seus ídolos.
63. Código morto
64. O que não costumamos fazer?
65. Análise estática de código
66. Evitar metaprogramação
67. Teste complexo:
68. Teste complexo: • Setup muito grande
69. Teste complexo: • Setup muito grande • Muitos stubs
70. Recapitulando...
71. Com refatorar melhor?
72. Estar atento aos sinais (code smells).
73. Hábito continuo.
74. Exemplo: Tenho um projeto com uma classe User muito grande.
75. Meta: Na próxima feature que envolver User, diminuir e não aumentar a classe User.
76. Saber aplicação de design patterns != Saber refatorar
77. Pensamento crítico vale mais que qualquer técnica de refatoração ou Design Pattern vendido como bala de prata.
78. "There is no refactoring that is always a great idea. You always have to say: is this worth it given the components of my system as they are?" - Ben Orenstein
79. Quero saber mais sobre técnicas de refactoring...
81. Fearless refactoring Rails Controllers http://rails-refactoring.com/
83. Curso: Refactoring Rails - Ben Orenstein http://www.refactoringrails.io/
84. Obrigada!