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

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

[ 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