Manutenção e Refatoração de CSS

Transcript

1. Manutenção e refatoração de CSS
2. @lucasmazza
3. http:/ /www.casadocodigo.com.br/products/livro-html-css
7. O que é importante quando se fala de manutenção de software?
8. Semântica Modularidade Performance Produtividade
9. Manuntenção não é trabalho de uma pessoa só
10. Lembre-se que o seu código será continuado por outras pessoas
11. E você dará continuidade ao código dos outros
13. Quem escreveu CSS para features novas?
14. (a equipe inteira)
15. Quem precisou refatorar código?
16. (a equipe inteira)
17. Quem precisou resolver bugs do IE?
18. (a equipe inteira)
19. Qualquer desenvolvedor pode ajudar Mesmo quem não é Front end
20. ZOMG Pull Requests!
21. Código Contexto Discussão
23. Markdown Screenshots GIFs
25. Disseminação de conhecimento Revisão do código escrito pela equipe
26. Abrace a autoria coletiva O código é do projeto/equipe/empresa
27. Evite silos de conhecimento Não seja o “cara de Front end” do seu projeto
28. http:/ /guidelines.plataformatec.com.br/pull-requests
29. Código Código Código Código Código Código Código Código Código Código Código Código Código Código Código Código Código Código
30. Você precisa de algum padrão para o seu código Ou tudo vira bagunça
31. a gente começou a escrever o nosso
32. http:/ /guidelines.plataformatec.com.br/css
33. Organização de propriedades Formato de documentação Práticas para pré-processadores
34. Metodologias não faltam OOCSS BEM Smacss DRYCSS MVCSS FCSS
35. Use o que funcione para você
36. Use o que funcione para você para o seu time
37. Beleza, mas o que você usa?
38. OOCSS-ish/FCSS-ish Apenas classes Scss #noparents Inspirado pela modelagem do backend
39. #noparents http:/ /markdotto.com/2013/10/09/css-and-noparents/
40. .product-list { } .product-list > li { } .product-list li.highlight { } .product-list { } .product-list-item { } .higlighted-list-item { } ✗ ✓
41. Especificidade reduzida Redução de sobreescritas Independente do HTML
42. Trate as entidades do sistema como os componentes da sua interface
43. // app/assets/stylesheets/_calendar.scss .calendar { } .calendar-heading { } .calendar-slot { } .calendar-weekday { } .calendar-weekend { } SCSS
44. <!-- app/views/events/_calendar.html.erb --> <div class='calendar'> <h2 class='calendar-heading'> <%= calendar.month %> </h2> ! <ul> <% calendar.days.each do |day| %> <li class='calendar-slot'><%= day %></li> <% end %> </ul> </div> ERB
45. # app/presenters/calendar.rb class Calendar attr_reader :days attr_reader :month ! def to_partial_path 'events/calendar' end end Ruby
46. Nomenclatura ubíqua Responsabilidades bem definidas Composição + herança do backend
47. Nesting é coisa séria E um dia você ainda vai se arrepender
48. 3 níveis 40/50 linhas E uma boa desculpa (liberado para pseudo selectors)
49. slide roubado do Nando Vieira
50. Modularização é difícil pra #@$#%!
51. Mudanças devem ter consequências previsíveis
52. E para isso precisamos que o código fique bem isolado
53. Muitas peças móveis Arquitetura complexa Alta curva de aprendizado
54. application.scss normalize.scss _functions.scss _defaults.scss modules/_home.scss sprites/_icons.scss
55. application.scss normalize.scss core/_functions.scss core/_defaults.scss modules/_home.scss sprites/_icons.scss
56. application.scss vendor/normalize.scss core/_functions.scss core/_defaults.scss modules/_home.scss modules/_sidebar.scss sprites/_icons.scss vendor/bootstrap/_tooltip.scss
57. Aceite que você não precisa acertar de primeira
58. E que você sempre pode reorganizar o seu código
59. E que você sempre pode melhorar o seu código
60. E que você sempre pode rescrever o seu código
61. Cuide das dependências externas
62. “Estava com o problema XYZ, então editei o código do Bootstrap...”
63. Agora você tem dois problemas
64. NO TOUCHING!
65. Código de terceiros deve ficar isolado
66. E você pode sobreescrever o que precisar
67. @import 'vendor/bootstrap'; ! @import 'overrides/bootstrap'; @import 'mystuff';
68. Escolha dependências do tamanho que você precisa
69. Ou “porque eu não uso Compass”
70. compass-rails Compass O que eu realmente preciso
71. Eu só quero gerenciar meus sprites
72. lucasmazza/spriteful
73. CLI <3 Não é uma dependência de runtime 500 linhas de código
74. Adicione dependências com moderação Não modifique, estenda Mantenha tudo atualizado
75. Documentação <3
76. Documentação é um canal de comunicação
77. Documentação é uma outra abstração do código
78. // ============================================================== // Profile card to display the players in the leaderboard. // // Supports an avatar wrapper, follower count and the user name. // Note that the 'avatar' and the 'follower count' are wrapped // inside an 'a' tag so everything will be clickable. Descrição
79. // <div class='profile-card'> // <a href='#' class='profile-card-avatar'> // <img class='profile-card-avatar' width='120' height='120'> // <span class='profile-card-follower-count'>13220</span> // <p class='profile-card-star'>@HackerNewsOnion</p> // </a> // <a href='#' class='profile-card-name'>Hacker News Onion</a> // </div> // ============================================================== Exemplos
80. Modificadores // ============================================================= // A full fledged replacement for '<select>' using a list of // unordered items. // // Modifiers: // // :hover - Subtle hover highlight. // .expanded - Expanded state, displaying the choices list. // .right-aligned - Aligns the 'toggle' icon to the right. // ============================================================= ! // Expanded state for the 'combo-selector'. // ============================================================== .combo-selector.expanded { }
81. E qualquer outra informação relevante
82. você também pode criar o styleguide do seu projeto
85. http:/ /pattern-lab.info/resources.html Exemplos e referências @ PatternLab
86. Foque em documentar o que é relevante
87. Módulos complexos Variações importantes Mixins e funções Qualquer outro hotspot
88. O importante é escrever alguma coisa
89. Mas isso não é uma ciência exata
90. Problemas diferentes irão surgir em casos diferentes
91. Escute o seu código
92. Kent Beck @ Smalltalk Best Practice Patterns “Code doesn't lie. If you're not listening, you won't hear the truths it tells.”
93. Converse com o seu time
94. Kyle Neath @ http:/ /warpspire.com/posts/kss/ “Maintainability comes from shared understanding.”
97. Refatore Reescreva Melhore Documente
98. Obrigado! https:/ /twitter.com/lucasmazza https:/ /speakerdeck.com/lucas