The Zen and Art of Refactoring

5a90a67fa1a92e6a4b605cfd8da5e375?s=47 Lucas Mazza
September 24, 2016

The Zen and Art of Refactoring

Refactoring is often seen as a process where we make bad code better by waving our wands and casting our secret spells while facing our editors, which usually happens when things are on fire and the pressure is on.

Changing software should be easier and not scary, and one of the first steps to do it is not to try to write future-proof code, but we can adopt different steps to think about the changes we want to do and how we can do them.

In this talk we will discuss how we can approach the code to-be-changed and see our refactoring tasks as a common transformation process instead of a rescue mission and different questions we should ask ourselves before picking Design Patterns or architectural jargon for the changes we want to do on our software.

5a90a67fa1a92e6a4b605cfd8da5e375?s=128

Lucas Mazza

September 24, 2016
Tweet

Transcript

  1. The Zen and Art of Refactoring

  2. @lucasmazza http://afterhours.io/

  3. https://sp.femug.com https://github.com/femug/femug

  4. https://plataformatec.workable.com

  5. None
  6. Era uma vez…

  7. None
  8. None
  9. None
  10. None
  11. https://twitter.com/fnando/status/760972305501741057

  12. None
  13. “Resolving technical debt” http://classicprogrammerpaintings.com/ https://www.flickr.com/photos/33255628@N00/7923536516

  14. None
  15. None
  16. The Zen and Art of Refactoring

  17. refatorando com menos dor e mais precisão

  18. Sem Falar de código

  19. None
  20. None
  21. DRY SOLID TDD ABC Metrics

  22. http://www.sandimetz.com/99bottles/ http://confreaks.tv/presenters/sandi-metz http://confreaks.tv/presenters/katrina-owen

  23. Tudo isso é o suficiente?

  24. Não

  25. None
  26. None
  27. ❓ ❓❓

  28. Prioridade Justin Searls - Surgical Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco

  29. Bug Fixes Prioridade Justin Searls - Surgical Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco

  30. Bug Fixes Novas Features Prioridade Justin Searls - Surgical Refactors

    http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco
  31. Bug Fixes Novas Features Testes Prioridade Justin Searls - Surgical

    Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco
  32. Bug Fixes Novas Features Testes Refactoring Prioridade Justin Searls -

    Surgical Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco
  33. Bug Fixes Novas Features Testes Refactoring Prioridade Justin Searls -

    Surgical Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html Custo/Risco
  34. None
  35. None
  36. None
  37. Backlog Técnico

  38. Backlog Técnico Sprints de Refatoração

  39. Backlog Técnico Sprints de Refatoração Refactoring implícito

  40. Backlog Técnico Sprints de Refatoração Refactoring implícito Refactoring Da madrugada

  41. Backlog Técnico Refactoring implícito Refactoring Da madrugada

  42. Backlog Técnico Refactoring implícito

  43. Backlog Técnico Visibilidade Colaboração Refactoring implícito Sob demanda

  44. Backlog Técnico Visibilidade Colaboração Refactoring Explicito Sob demanda

  45. None
  46. Refactorings precisam ser:

  47. Refactorings precisam ser: esclarecidos

  48. Refactorings precisam ser: esclarecidos auto contidos

  49. Refactorings precisam ser: esclarecidos auto contidos previsíveis

  50. Refactorings precisam ser: esclarecidos auto contidos previsíveis baixo custo

  51. Refactorings precisam ser: esclarecidos auto contidos previsíveis baixo custo contínuos

  52. Refactorings são um meio, não um fim.

  53. Bug Fixes Novas Features Testes + Refactoring Prioridade Custo/Risco Justin

    Searls - Surgical Refactors http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html
  54. “There’s so much talk about the system. And so little

    understanding.” Robert M. Pirsig Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
  55. None
  56. O código é o nosso entendimento do sistema negócio problema

  57. None
  58. None
  59. Entender o propósito do software é crucial.

  60. Muitas vezes não adianta mudar um sem mudar o outro.

  61. Ubiquitous Language, a melhor parte do DDD

  62. None
  63. Nomeie e renomeie sempre que precisar

  64. Nomeie e renomeie sempre que precisar Guarde o jargão técnico

    de patterns para APIs privadas
  65. Nomeie e renomeie sempre que precisar Guarde o jargão técnico

    de patterns para APIs privadas Evite sinônimos
  66. Nomeie e renomeie sempre que precisar Guarde o jargão técnico

    de patterns para APIs privadas Evite sinônimos Nomenclatura é um problema fullstack: models, controllers, views, CSS, etc…
  67. Nomeie e renomeie sempre que precisar Guarde o jargão técnico

    de patterns para APIs privadas Evite sinônimos Nomenclatura é um problema fullstack: models, controllers, views, CSS, etc… Pode parecer difícil, mas dá resultado
  68. None
  69. None
  70. Ambientes caóticos complicam mudanças no software

  71. “Toxic workplaces and processes are much more responsible for ball

    of mud Rails apps than Active Support. Maybe we should try fixing those?” Andrew White (@pixeltrix) https://twitter.com/pixeltrix/status/734613266094301185
  72. times de desenvolvimento precisam de paz para trabalhar

  73. “Peace of mind produces right values, right values produce right

    thoughts. Right thoughts produce right actions and right actions produce work which will be a material reflection for others to see of the serenity at the center of it all.” Robert M. Pirsig Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
  74. “What we call workability of the machine is just an

    objectification of this peace of mind.” Robert M. Pirsig Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
  75. “organizations which design systems ... are constrained to produce designs

    which are copies of the communication structures of these organizations” Conway’s Law
  76. Ambientes caóticos vão criar projetos caóticos

  77. None
  78. 340 360 380 400 420 Jul Ago Set Out Nov

    Dez Code Smells - acme-co/webapp
  79. 340 360 380 400 420 Jul Ago Set Out Nov

    Dez Code Smells - acme-co/webapp
  80. 340 360 380 400 420 Jul Ago Set Out Nov

    Dez Code Smells - acme-co/webapp powered by ebert
  81. None
  82. None
  83. Pamela Vickers - Your Company Culture is 'Awesome' (But is

    'Company Culture' a lie?) https://www.youtube.com/watch?v=h1UayuSXBcg
  84. Refactoring é como arrumar o seu quarto.

  85. Refactoring é como arrumar o seu quarto. Toda semana.

  86. Refactoring é como arrumar o seu quarto. Toda semana. Para

    sempre.
  87. None
  88. None
  89. None
  90. None
  91. https://comonavidareal.com/2015/07/23/em-busca-do-hamburguer-perfeito-2-z-deli-sandwich-shop/

  92. Melhoria contínua “Big Scary Refactor”

  93. Mais fácil de:

  94. Mais fácil de: revisar

  95. Mais fácil de: revisar testar

  96. Mais fácil de: revisar testar vender

  97. Mais fácil de: revisar testar vender jogar fora e tentar

    denovo
  98. “when this day is over and you look at how

    little you have accomplished - do not be bothered, it just means you get to do it again.” Austin Kleon
  99. “Real refactoring is comfortingly predictable, and saves brainpower for peskier

    challenges.” Sandi Metz & Katrina Owen - 99 Bottles of OOP
  100. None
  101. Obrigado! @lucasmazza