[ UFS -Semana UP ] - O seu código não é só para você entender - 28/05/2020

Transcript

1. O seu código não é só para você entender melhores práticas para aplicações que todos entendam e facilitem a manutenção @kamilah_santos
2. Kamila Santos Dev Backend
3. Agenda • solid • dry • refatoração • design patterns • clean code • code smells • testes • componentização •documentação •code review @kamilah_santos
4. S.O.L.I.D @kamilah_santos
5. SOLID Look professional and presentable. Conjunto de boas práticas de desenvolvimento que facilitam a adição de novas features, manutenção e correção de bugs @kamilah_santos
6. S = Single responsibility principle - Prinípio da responsabilidade única Uma classe deve ter uma e somente uma responsabilidade, se tiver mais de uma devemos refatorar. @kamilah_santos
7. O = Open/closed principle - Princípio do Aberto/Fechado Devemos ser capazes de estender um comportamento de determinada classe sem precisar modificá-lo, pode ter seu comportamento alterado com facilidade se necessário porém através herança,interface…. @kamilah_santos
8. L : Liskov substitution principle Princípio da substituição de Liskov Look professional and presentable. As classes derivadas devem poder ser substituíveis pelas classes bases @kamilah_santos
9. I : Interface segregation principle - Princípio da segregação de interfaces Look professional and presentable. Melhor ter várias interfaces específicas do que um interface geral, crie interfaces granulares para cada “cliente” @kamilah_santos
10. D: Dependency inversion principle - Princípio da inversão de dependência Dependa das abstrações, não das implementações, as abstrações tem menores alterações e facilitam a implementação. @kamilah_santos
11. D . R . Y Don't Repeat YourSelf Cada pedaço de código deve ter uma única representação, sem ambiguidades no resto do sistema, não teremos que alterar em várias partes uma responsabilidade que está espalhada pelo sistema @kamilah_santos
12. REFATORAÇÃO @kamilah_santos
13. REFATORAÇÃO Refatoração se trata do processo de alterar um sistema de software de uma forma que ela não tenha seu comportamento externo alterado, mas tenha a sua estrutura interna melhorada. @kamilah_santos
14. Refatoração no TDD @kamilah_santos
15. @kamilah_santos
16. Técnicas de refatoração @kamilah_santos
17. Renomear método Para deixar o código mais expressivo, vamos renomear este método de modo que fique mais fácil de identificar qual é o seu propósito: @kamilah_santos
18. @kamilah_santos
19. @kamilah_santos
20. Extrair método Esta técnica pode ser utilizada quando precisamos quebrar um método que possui mais de uma responsabilidade. @kamilah_santos
21. @kamilah_santos
22. @kamilah_santos
23. @kamilah_santos
24. Mover método Esta técnica pode ser utilizada quando se tem um método que usa mais informações de uma classe externa do que da sua própria classe. Essa alteração reduz a complexidade do nosso código, pois ele vai acessar as informações da nova classe de forma direta @kamilah_santos
25. @kamilah_santos
26. Mover método Para isso, devemos criar a classe Clientes e mover o método clientes_para_inativar para dentro dela, transferindo sua responsabilidade. @kamilah_santos
27. @kamilah_santos
28. Mover método Depois desta separação, a classe InativarClientesWorker ficaria assim: @kamilah_santos
29. @kamilah_santos
30. Mover campo é necessário quando temos um campo (atributo) que é mais usado em uma classe externa do que na sua própria classe. @kamilah_santos
31. Mover campo Seu maior benefício é que, ao ser criado na nova classe, temos a garantia de que ele ficará protegido de modificações externas ou criamos um atributo de leitura e – se preciso – de escrita na classe de destino, e alteramos todos os locais em que ele é referenciado. @kamilah_santos
32. @kamilah_santos
33. @kamilah_santos
34. Extrair classe É a união do Extrair método. É utilizada quando uma classe tem mais de uma responsabilidade. Então, para a construção dessa nova classe, utilizamos o Mover Método e Mover Campo. @kamilah_santos
35. Extrair classe Vamos separar a parte de baixar o log de vendas da parte que salva esse log no banco de dados. Primeiro vamos criar uma nova classe para essa responsabilidade e passar os respectivos métodos para ela. @kamilah_santos
36. @kamilah_santos
37. @kamilah_santos
38. @kamilah_santos
39. Extrair classe Com as responsabilidades separadas e com os métodos simplificados, podemos ver nomes mais claros para as nossas classes. @kamilah_santos
40. Extrair classe A classe BaixarArquivoServidorFtp é bem genérica para ser usada em outros locais – pode permanecer com o mesmo nome. Já a BaixarLogVendaWorker pode ser renomeada para SalvarRegistroVendasWorker. @kamilah_santos
41. @kamilah_santos
42. DESIGN PATTERNS @kamilah_santos
43. Padrões de projeto Soluções/modelos generalistas para questões recorrentes no desenvolvimento de software @kamilah_santos
44. Factory Tem como objetivo extrair criação de objetos para métodos e classes específicos. Os objetos criados são chamados de produtos e as classes que os criam são as fábricas. @kamilah_santos
45. Factory Method Ter um mesmo tipo de produto, mas com várias fábricas, cada uma com seu funcionamento próprio, Dessa forma, além das configurações passadas, cada uma das fábricas terá uma lógica específica que afeta o produto final. @kamilah_santos
46. Template Method É um padrão comportamental, que tem como objetivo simplificar as responsabilidades dos objetos @kamilah_santos
47. Template Method Contexto: podemos separar um comportamento base , que é comum aos demais algoritmos do sistema, criando um template com pontos de extensão @kamilah_santos
48. @kamilah_santos
49. Template Method A base define os métodos que serão chamados, a ordem de execução e o que será retornado por eles, tudo isso numa mesma classe que será utilizada pelas outras para executar esses algoritmos @kamilah_santos
50. Template Method Cada um dos demais algoritmos específicos herda essa classe base e sobrescreve os métodos necessários para implementar essa própria lógica. @kamilah_santos
51. Template Method Estes métodos que são sobrescritos são denominados métodos gancho, como a base permanece inalterada, o código de utilização permanece o mesmo em qualquer utilização, trazendo maior flexibilidade para a aplicação. @kamilah_santos
52. Strategy Semelhante ao anterior, é um padrão de comportamento, visa resolver problemas de distribuição de responsabilidades. Devemos ter de forma clara como separar essas responsabilidades. @kamilah_santos
53. Strategy Devemos encapsular cada um deles pelas estratégias de modo que possamos realizar a troca entre elas facilmente. @kamilah_santos
54. Adapter É recomendável de ser utilizado quando temos duas classes com interfaces diferentes, porém que precisam trabalhar em conjunto. @kamilah_santos
55. Adapter Devemos isolar as responsabilidades de uma interface para outra do restante da lógica do nosso negócio. @kamilah_santos
56. Adapter A utilização do Adapter faz define o que é esperado pela classe cliente e o que esse adaptador precisa definir. A criação de novos adaptadores não requer criação de novos clientes, mas precisamos que os dados sejam retornados da maneira esperada. @kamilah_santos
57. CLEAN CODE @kamilah_santos
58. Código limpo Código limpo é simples e fácil de acompanhar, com escopo isolado, fácil de ser testado, e bem (auto) documentado @kamilah_santos
59. Código limpo “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler @kamilah_santos
60. @kamilah_santos
61. Seja consistente @kamilah_santos
62. Regra do escoteiro @kamilah_santos
63. DRY @kamilah_santos
64. RASAP @kamilah_santos
65. KISS @kamilah_santos
66. 1. Use nomes que revelam a intenção @kamilah_santos
67. 2. Use nomes Pronunciáveis/Procuráveis @kamilah_santos
68. 3. Siga as convenções @kamilah_santos
69. 4 - Não use o que você acha mais bonito/fofo @kamilah_santos
70. 5 - Escolha uma palavra por Ideia/Conceito @kamilah_santos
71. CODE SMELLS @kamilah_santos
72. Code Smell - Bloaters @kamilah_santos
73. Code Smell - Object-Orientation Abusers @kamilah_santos
74. Code Smell - Change Preventers @kamilah_santos
75. Code Smell - Dispensables @kamilah_santos
76. Code Smell - Couplers @kamilah_santos
77. TESTES @kamilah_santos
78. TESTES DE INTERFACE @kamilah_santos
79. TESTES DE INTERFACE @kamilah_santos
80. TESTES DE INTERFACE @kamilah_santos
81. TESTES DE INTEGRACAO @kamilah_santos
82. TESTES DE INTEGRACAO @kamilah_santos
83. TESTES DE INTEGRACAO @kamilah_santos
84. TESTES UNITARIOS @kamilah_santos
85. TESTES UNITARIOS @kamilah_santos
86. TESTES UNITARIOS @kamilah_santos
87. TESTES UNITARIOS @kamilah_santos
88. TESTES UNITARIOS @kamilah_santos
89. TESTES UNITARIOS @kamilah_santos
90. TESTES UNITARIOS @kamilah_santos
91. TESTES UNITARIOS @kamilah_santos
92. TESTES UNITARIOS @kamilah_santos
93. COMPONENTIZAÇÃO @kamilah_santos
94. SMART COMPONENTS @kamilah_santos
95. DUMB COMPONENTS @kamilah_santos
96. Documentação @kamilah_santos
97. Documentação @kamilah_santos
98. Documentação @kamilah_santos
99. Documentação @kamilah_santos
100. Code review @kamilah_santos
101. Referencias https://gist.github.com/Ka milahsantos/6b50816b9d21 b7866fa8446f7b92283c @kamilah_santos
102. Obrigada <3 @kamilah_santos https://linktr.ee/kamila.dev