Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[RubyConfBR 2017] Refatorando Rails apps com confiança

78feb03b0e2d133b3a53de62fde6d055?s=47 Flavia Fortes
November 17, 2017
180

[RubyConfBR 2017] Refatorando Rails apps com confiança

78feb03b0e2d133b3a53de62fde6d055?s=128

Flavia Fortes

November 17, 2017
Tweet

Transcript

  1. Flavia Fortes

  2. None
  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...

  80. None
  81. Fearless refactoring Rails Controllers http://rails-refactoring.com/

  82. None
  83. Curso: Refactoring Rails - Ben Orenstein http://www.refactoringrails.io/

  84. Obrigada!