Um ano depois: os aprendizados e impactos de um Design System

Conceitualmente já ouvimos muito sobre Design System. Mas na prática, como ele funciona? Como montar um time? Como medir resultados? Como gerir? Perguntas como essas serão respondidas através da experiência de um ano de Design System em uma empresa com mais de 100 desenvolvedores. Irei mostrar os impactos que essa abordagem trouxe no desenvolvimento de uma aplicação web, no design, concepção de produto, back-end e front-end.

Transcript

1. os aprendizados e impactos de um Design System. um ano depois:
2. Fernando Rodrigues Front-end Engineer @fernahh fernahh.com.br
4. Um ano antes.
5. https://engineering.contaazul.com/componentizando-o-contaazul-bf26b58231d
6. enquanto isso nas plannings...
7. já podemos usar o novo autocomplete? sai maluco, todo dia isso
8. aprendizado #1 Os objetivos dos times de produto não incluirão entrega de componentes.
9. comece buscando entender como os times de produto trabalham.
10. montar um time de design system com pessoas de produto pode acelerar o início.
11. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
12. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
13. “se temos componentes por que não somos produtivos?”
14. Escalabilidade e produtividade.
15. Henry Ford (1863 - 1947)
17. https://ark-invest.com/research/automotive-consolidation
18. NATO Software Engineering Conference (1968)
19. component-based development: eficiência e facilidade para escalar.
20. aprendizado #2 Defina o que é componente na visão do time.
21. Atomic Design Brad Frost
23. Atomic Design. Átomos: são pequenos componentes que não podem mais ser quebrados sem deixar de funcionar.
24. Lorem Ipsum
25. Lorem Ipsum
26. Lorem Ipsum Send
27. Moléculas: grupos de átomos que juntos funcionam como uma unidade. Exemplos: search form. Atomic Design.
28. Lorem Ipsum Send
29. Organismos: componentes complexos que podem ser composto por átomos e/ou grupos de moléculas e outros organismos. Exemplo: header com logo, menu, search form. Atomic Design.
30. Lorem Ipsum Send
31. “isso é uma molécula ou um organismo?”
32. Templates: “page-levels objects” que colocam componentes em um layout e modelam a estrutura do conteúdo. Atomic Design.
34. Pages: instâncias específicas de templates que mostram a aparência de uma interface com conteúdo real. Atomic Design.
36. Redundância Trata-se da repetição inútil e desnecessária de algum termo ou ideia. https://www.dicionarioinformal.com.br/redund%C3%A2ncia/
37. tudo é componente.
38. quanto mais fácil for tomar uma decisão, melhor.
39. aprendizado #3 Entenda o nível de maturidade dos seus componentes.
40. Bootstrap https://getbootstrap.com
41. <button class="btn btn-primary"> Primary </button>
42. https://derickbailey.com/2015/08/26/building-a-component-based-web-ui-with-modern-javascript-frameworks/
43. “O que o torna algo em um componente é o encapsulamento de seu comportamento, seu visual e qualquer outro código ou configuração em algo que é facilmente orquestrado dentro de um sistema maior”. Derick Bailey
44. https://martinfowler.com/bliki/MaturityModel.html
45. Modelo de Maturidade de Componentes
46. Nível 0: caos. - Não há estruturas HTML padronizadas que podem ser replicadas. - Não há classes CSS pré definidas que funcionam em conjunto com aquelas estruturas HTML padronizadas. - Não há encapsulamento de marcação, lógica e estilo. Modelo de Maturidade de Componentes.
47. Nível 0: caos. (efeitos colaterais) - CSS desnecessário. - Scripts desnecessários. - Zero reuso. - Mudanças muito caras. Modelo de Maturidade de Componentes.
48. Nível 1: CSS Components. - Estruturas HTML padronizadas. - Classes CSS pré definidas. - Não há encapsulamento de marcação, lógica e estilo. Modelo de Maturidade de Componentes.
49. <button class="btn btn-primary"> Primary </button>
50. Nível 1: CSS Components. (efeitos colaterais) - Menos CSS escrito. - Marcação desnecessária. - Scripts desnecessários. - Mudanças caras. Modelo de Maturidade de Componentes.
51. Nível 2: Custom Elements. - Estruturas HTML padronizadas. - Classes CSS pré definidas. - Marcação, lógica e estilo encapsulados. Modelo de Maturidade de Componentes.
52. <Button variant="primary" />
53. Nível 2: Encapsulamento. (efeitos colaterais) - Cada componente torna-se a única autoridade sobre uma única responsabilidade do sistema. - Tudo se torna reutilizável. - Mudanças são baratas. Modelo de Maturidade de Componentes.
54. https://rafaelcamargo.com/modelo-de-maturidade-de-componentes
55. aprendizado #4 Mantenha-se em contato constante com os times de produto.
56. as decisões devem ser tomadas em conjunto e os resultados devem ser compartilhados.
57. “Um Design System é uma ferramenta para empoderamento, não uma arma para controlar o design.” Matt Bond
59. uma vez que o time entende que não é uma limitação e sim colaboração, torna-se necessário e uma nova forma de trabalhar.
60. aprendizado #5 Mantenha-se simples.
61. - npm
62. - npm - React
63. - npm - React - React Router
64. - npm - React - React Router - Jest
65. - npm - React - React Router - Jest - Enzyme
66. - npm - React - React Router - Jest - Enzyme - ESLint
67. - npm - React - React Router - Jest - Enzyme - ESLint - webpack
69. - npm - React - React Router - Jest - Enzyme - ESLint - webpack
70. - npm - React - React Router - Jest - Enzyme - ESLint - webpack - TypeScript
71. - npm - React - React Router - Jest - Enzyme - ESLint - webpack - TypeScript - TS Jest
72. - npm - React - React Router - Jest - Enzyme - ESLint - webpack - TypeScript - TS Jest - Styled Components
73. - npm - React - React Router - Jest - Enzyme - ESLint - webpack - TypeScript - TS Jest - Styled Components - Jest Styled Components
75. cada ferramenta a mais no projeto é um ponto de fricção para contribuições.
76. https://fernahh.com.br/desenvolva-software-como-os-ramones-faziam-musicas/
77. aprendizado #6 Aplique princípios de desenvolvimento de software.
78. “mas e a especificidade do CSS? como resolver sem CSS-in-JS?”
79. Open-Closed Principle Entidades de software devem estar abertas para extensão, mas fechadas para modificação; isto é, essa entidade pode permitir que seu comportamento seja estendido sem modificar seu código-fonte.
80. Image uma garrafa. Open-Closed Principle.
81. Open-Closed Principle.
82. Uma garrafa aceita uma infinidade de líquidos diferentes em seu interior sem precisar alterá-la. Open-Closed Principle.
83. <div class="bottle"> <div class="bottle-content"> ... </div> </div>
85. <div class="fruki-bottle"> <div class="bottle"> <div class="boottle-content"> ... </div> </div> </div>
86. .fruki-bottle .bottle-content { background-img: url(logo); }
87. https://medium.com/@rcamargo/entre-garrafas-e-princ%C3%ADpios-como-organizar-melhor-seu-css-4f1572159a04
88. vários problemas em front-end surgem porque violamos princípios de software.
89. aprendizado #7 Mantenha uma boa cobertura de testes.
90. https://martinfowler.com/articles/practical-test-pyramid.html
91. testes de front-end devem garantir e documentar o comportamento esperado pelo usuário.
92. show
93. ✓ show Test message
94. it('should toggles the state of show', () => { const testMessage = 'Test Message' const wrapper = shallow( <HiddenMessage>{testMessage}</HiddenMessage> ) wrapper.instance().toggle() wrapper.update() expect(wrapper.state().show).toBe(true) })
95. it('should toggles the state of show', () => { const testMessage = 'Test Message' const wrapper = shallow( <HiddenMessage>{testMessage}</HiddenMessage> ) wrapper.instance().toggle() wrapper.update() expect(wrapper.state().show).toBe(true) })
96. it('should toggles the state of show', () => { const testMessage = 'Test Message' const wrapper = shallow( <HiddenMessage>{testMessage}</HiddenMessage> ) wrapper.instance().toggle() wrapper.update() expect(wrapper.state().show).toBe(true) })
97. it('should toggles the state of show', () => { const testMessage = 'Test Message' const wrapper = shallow( <HiddenMessage>{testMessage}</HiddenMessage> ) wrapper.instance().toggle() wrapper.update() expect(wrapper.state().show).toBe(true) })
98. “O usuário não se importa nem um pouco com o que as coisas chamam.” Kent C. Dodds
99. it('shows the children when the checkbox is checked', () => { const testMessage = 'Test Message' const { getByLabelText, getByText } = render( <HiddenMessage>{testMessage}</HiddenMessage> ) fireEvent.click(getByLabelText(/show/i)) expect(getByText(testMessage)).toBeInTheDocument() })
100. it('shows the children when the checkbox is checked', () => { const testMessage = 'Test Message' const { getByLabelText, getByText } = render( <HiddenMessage>{testMessage}</HiddenMessage> ) fireEvent.click(getByLabelText(/show/i)) expect(getByText(testMessage)).toBeInTheDocument() })
101. it('shows the children when the checkbox is checked', () => { const testMessage = 'Test Message' const { getByLabelText, getByText } = render( <HiddenMessage>{testMessage}</HiddenMessage> ) fireEvent.click(getByLabelText(/show/i)) expect(getByText(testMessage)).toBeInTheDocument() })
102. it('shows the children when the checkbox is checked', () => { const testMessage = 'Test Message' const { getByLabelText, getByText } = render( <HiddenMessage>{testMessage}</HiddenMessage> ) fireEvent.click(getByLabelText(/show/i)) expect(getByText(testMessage)).toBeInTheDocument() })
103. Testing Library https://testing-library.com
104. “o que é uma boa cobertura de testes?”
105. 100%.
106. por que um número abaixo de 100% de cobertura é melhor?
107. Recapitulando.
108. 1. Os objetivos dos times de produto não incluirão entrega de componentes.
109. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time.
110. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time. 3. Entenda o nível de maturidade dos seus componentes.
111. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time. 3. Entenda o nível de maturidade dos seus componentes. 4. Mantenha-se em contato constante com os times de produto.
112. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time. 3. Entenda o nível de maturidade dos seus componentes. 4. Mantenha-se em contato constante com os times de produto. 5. Mantenha-se simples.
113. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time. 3. Entenda o nível de maturidade dos seus componentes. 4. Mantenha-se em contato constante com os times de produto. 5. Mantenha-se simples. 6. Aplique princípios de desenvolvimento de software.
114. 1. Os objetivos dos times de produto não incluirão entrega de componentes. 2. Defina o que é um componente na visão do time. 3. Entenda o nível de maturidade dos seus componentes. 4. Mantenha-se em contato constante com os times de produto. 5. Mantenha-se simples. 6. Aplique princípios de desenvolvimento de software. 7. Mantenha uma boa cobertura de testes.
115. aprendizado #8 Design System nunca acaba.
116. produtos mudam.
117. tecnologias são depreciadas.
118. pessoas entram e saem, consequentemente a cultura muda.
119. aprendizado #9 Surpreenda nas entregas! ou no mínimo, faça funcionar.
125. Os impactos.
126. o time se torna referência técnica.
127. o time ganha influência estratégica no planejamento produto.
128. produto começa a pensar em inovação ao invés de atividades corriqueiras.
129. o back-end começa a padronizar APIs.
135. “Para que serve a utopia? Serve para isso: para que eu não deixe de caminhar.”
136. obrigado, BrazilJS, por me incentivar a não deixar de caminhar!
137. Obrigado! @fernahh fernahh.com.br