Um bom design

Design é um conceito de ampla discussão, e extremamente subjetivo. De forma análoga, discutir se um design é bom ou não é um tópico que gera profundas discussões, muitas vezes porque somos influenciados por nossas perspectivas e experiências anteriores. Então, como chegar a um consenso sobre o que é um bom design? E qual a importância disso?

Nessa talk discuto princípios que nos ajudam a entender e diagnosticar uma proposta de design, trazendo insights para um maior aprofundamento no tema

Transcript

1. O bom design
2. { “name”: “Gabriel Ferreira”, “github”: “@gleopoldo”, “company”: “Locaweb” }
3. https://ferreiratoons.com.br/ @FerreiraToons
5. Vamos falar de design
7. Vamos falar de design de código
8. Uma breve introdução… Por que falar em design de código?
9. brincadeiras à parte…
11. agora falando sério…
12. https://martinfowler.com/bliki/DesignStaminaHypothesis.html
13. Boa parte dos problemas virão da gestão de dependências
14. código não reutilizável…
15. duplicações…
16. arquitetura não muito clara…
17. sensação de “ser difícil fazer qualquer coisa no projeto”…
18. vão chamar aquilo de LEGADO
19. vão querer dar um “rails new”
20. O que garantiria que não vamos repetir os mesmos erros??
21. como garantir reusabilidade e flexibilidade a uma solução que desenvolvemos??
22. Design de código
23. [BOM] Design de código
24. O que faz um bom design?
25. https://www.youtube.com/watch?v=dKRbsE061u4 SOLID Ruby Jim Weirich - RubyConf 2009
26. aparentemente, um [BOM] design é algo subjetivo
27. temos uma tendência a repetir experiências que deram certo em outros lugares…
28. mas nem sempre uma solução para o problema A é válida para o problema B…
31. um [BOM] design não é algo fácil de se atingir…
32. um [BOM] design estaria associado a quais abstrações empregamos…
33. O que seria uma abstração?
35. https://stackify.com/oop-concept-abstraction/
36. abstrair seria o ato de omitir detalhes de implementação…
37. assim não…
38. ASSIM!!
41. INPUT DE DADOS
42. CONFIGURAR TEMPO
43. AQUECER INPUT
44. OUTPUT DE DADOS
46. um bom DESIGN é feito de boas ABSTRAÇÕES
47. boas ABSTRAÇÕES favorecem a uma BOA COMPREENSÃO
48. não precisa ser bonito…
50. precisa ser funcional, prático…
51. Como seria uma abstração de um microondas?
53. class Microwave end
54. class Microwave def initialize(food); end end
55. class Microwave def initialize(food); end def setup_timer(time_in_secs); end end
56. class Microwave def initialize(food); end def setup_timer(time_in_secs); end def heat(); end end
57. class Microwave attr_writer :food def initialize(food); end def setup_timer(time_in_secs); end def heat(); end end
61. o design está relacionado à TROCA DE MENSAGENS
62. “I'm sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is ‘messaging’” Kay, Alan
63. class Microwave attr_writer :food def initialize(food); end def setup_timer(time_in_secs); end def heat(); end end
64. class Microwave attr_writer :food def initialize(food); end def setup_timer(time_in_secs); end def heat(); end end
65. o [bom] design está relacionado à [uma boa] TROCA DE MENSAGENS
66. Como fazer [um bom design] uma boa troca de mensagens?
67. https://www.youtube.com/watch?v=v-2yFMzxqwU SOLID Object Oriented Design Sandi Metz - GORUCO 2009
68. S.O.L.I.D.
69. S. O. L. I. D.
70. S. O. L. I. D. ingle responsibility principle
71. S. O. L. I. D. ingle responsibility principle pen/closed principle
72. S. O. L. I. D. ingle responsibility principle pen/closed principle iskov substitution principle
73. S. O. L. I. D. ingle responsibility principle pen/closed principle iskov substitution principle nterface segregation principle
74. S. O. L. I. D. ingle responsibility principle pen/closed principle iskov substitution principle nterface segregation principle ependency inversion principle
75. O que leva a um bom design?
76. Ask, don’t tell saber fazer uma boa troca de mensagens
78. Ouvir seus testes! Quais insights seus testes podem dar?
80. Não resista a mudanças Sim, seu código vai mudar, mais breve do que pensa
81. “Make the change easy, then make the easy change” Beck, Kent The creator of Extreme Programming and TDD
82. Prática, muita prática!
83. https://github.com/emilybache/GildedRose-Refactoring-Kata
84. Não abstrair demais às vezes código duplicado pode ser melhor que a abstração errada
85. https://www.youtube.com/watch?v=8bZh5LMaSmE All the little things Sandi Metz - RailsConf 2014
86. S.O.L.I.D.
87. São bons princípios que fazem um bom design
88. Dúvidas? Github: @gleopoldo Speaker Deck: gleopoldo Linkedin: gabriel-leopoldo Gabriel Ferreira https://ferreiratoons.com.br/