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

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

188900fc4ed166ff159a9b74aa38a9bd?s=47 fernahh
November 30, 2019

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.

188900fc4ed166ff159a9b74aa38a9bd?s=128

fernahh

November 30, 2019
Tweet

Transcript

  1. os aprendizados e impactos de um Design System. um ano

    depois:
  2. Fernando Rodrigues Front-end Engineer @fernahh fernahh.com.br

  3. None
  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)

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

  22. None
  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.
  33. None
  34. Pages: instâncias específicas de templates que mostram a aparência de

    uma interface com conteúdo real. Atomic Design.
  35. None
  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
  58. None
  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
  68. None
  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
  74. None
  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>

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

  120. None
  121. None
  122. None
  123. None
  124. None
  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.

  130. None
  131. None
  132. None
  133. None
  134. None
  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