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

[CODECON-2020] - o seu código não é só pra você entender

[CODECON-2020] - o seu código não é só pra você entender

Tweet

Transcript

  1. Kamila Santos O seu código não é só para você

    entender @kamilah_santos
  2. @kamilah_santos Backend Developer Kamila Santos

  3. @kamilah_santos S.O.L.I.D D.R.Y Refatoração Design patterns Clean code Code smells

    Testes Documentação Agenda:
  4. S.O.L.I.D Conjunto de boas práticas de desenvolvimento que facilitam a

    adição de novas features, manutenção e correção de bugs @kamilah_santos
  5. 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
  6. 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
  7. L : LISKOV SUBSTITUTION PRINCIPLE PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV

    As classes derivadas devem poder ser substituíveis pelas classes bases @kamilah_santos
  8. I : INTERFACE SEGREGATION PRINCIPLE - PRINCÍPIO DA SEGREGAÇÃO DE

    INTERFACES Melhor ter várias interfaces específicas do que um interface geral, crie interfaces granulares para cada “cliente” @kamilah_santos
  9. 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
  10. 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
  11. 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
  12. REFATORAÇÃO NO TDD @kamilah_santos

  13. TÉCNICAS DE REFATORAÇÃO @kamilah_santos

  14. RENOMEAR MÉTODO Problema: o nome do método não diz o

    que ele faz Solução: renomear o método @kamilah_santos
  15. RENOMEAR MÉTODO Fonte: https://refactoring.guru/rename-method @kamilah_santos

  16. RENOMEAR MÉTODO Verifique onde está sendo utilizado e altere o

    nome ou crie um novo método com outro nome e mesma funcionalidade e substitua cada parte por vez dele. @kamilah_santos
  17. EXTRAIR MÉTODO Problema: Você tem um fragmento de código que

    pode ser separado em um novo método. Solução: separar esse pedaçõ/responsabilidade para um novo método e fazer a chamada nele nos locais necessários @kamilah_santos
  18. EXTRAIR MÉTODO Crie um novo método com aquela funcionalidade, localize

    os locais que utilizavam aquele trecho do código e substitua pelo novo código @kamilah_santos
  19. MOVER MÉTODO Problema: o método é mais utilizado em outra

    classe do que na classe que ele foi definido. Solução: crie um novo método numa classe em que ele for mais utilizado, transfira todas as referências do antigo para o novo método e remova tudo do antigo método @kamilah_santos
  20. MOVER MÉTODO https://refactoring.guru/move-method @kamilah_santos

  21. MOVER MÉTODO Após verificar todos os locais onde eram utilizados

    o método antigo, atualizar as chamadas para onde o novo método foi criado. @kamilah_santos
  22. MOVER CAMPO Extremamente similar ao mover método, mas nesse caso

    se trata de campos/variáveis. @kamilah_santos
  23. MOVER CAMPO https://refactoring.guru/move-field @kamilah_santos

  24. EXTRAIR CLASSE Problema: Uma classe tem mais de uma responsabilidade

    Solução: Criar um nova classe para separar essas responsabilidades @kamilah_santos
  25. EXTRAIR CLASSE https://refactoring.guru/extract-class @kamilah_santos

  26. EXTRAIR CLASSE Cria um nova classe, estabeleça uma relação entre

    elas, utilize o mover método e mover campo para separar essas responsabilidades na nova classe @kamilah_santos
  27. DESIGN PATTERNS Podemos definir design patterns como uma solução "generalista"

    para problemas recorrentes que passaram a ser um padrão utilizado por pessoas desenvolvedoras @kamilah_santos
  28. CRIACIONAIS São aqueles que fornecem mecanismos de criação de objetos,

    aumentando a flexibilidade e reutilização do código @kamilah_santos
  29. FACTORY METHOD É um padrão que fornece uma interface para

    criar objetos em uma superclasse, porém permite que as subclasses alterem o tipo de objetos que sejam criados. Fonte: https://refactoring.guru/pt-br/design-patterns/factory-method @kamilah_santos
  30. FACTORY METHOD Use factory method quando não souber os tipos

    de dependência exatas dos objetos com os quais a aplicação deve funcionar. @kamilah_santos
  31. FACTORY METHOD Quando deseja economizar recursos do sistema reutilizando objetos

    em vez de recria- los sempre que necessário @kamilah_santos
  32. ABSTRACT FACTORY Padrão de projeto criacional que possibilita que você

    produza grupos de objetos relacionados sem ter que especificar suas classes concretas Fonte: https://refactoring.guru/pt-br/design-patterns/abstract-factory @kamilah_santos
  33. ABSTRACT FACTORY Utilize quando sua aplicação precisa trabalhar com várias

    famílias de produtos relacionados, mas você não quer depender de classes concretas daqueles produtos, eles podem ser desconhecidos a princípio. @kamilah_santos
  34. BUILDER Permite construit objetos complexos step-by-step , possibilita que você

    desenvolva diferentes tipos e representações de um objeto utilizando o mesmo código de construção Fonte: https://refactoring.guru/pt-br/design-patterns/builder @kamilah_santos
  35. BUILDER Utilize quando desejar que seu código seja capaz de

    criar variadas representações de um mesmo produto. @kamilah_santos
  36. PROTOTYPE Possibilita copiar objetos existentes sem que seu código fique

    dependente de suas classes Fonte:https://refactoring.guru/pt-br/design-patterns/prototype @kamilah_santos
  37. PROTOTYPE Utilize quando precisar reduzir o número de subclasses que

    só diferem na forma de inicialização dos sues respectivos objetos. @kamilah_santos
  38. SINGLETON Possibilita a você garantir que uma classe tenha apenas

    uma instância enquanto prove um ponto de acesso global para essa instância Fonte:https://refactoring.guru/pt-br/design-patterns/singleton @kamilah_santos
  39. SINGLETON Utilize quando um classe da sua aplicação deve ter

    somente uma instância disponível para todos seus clientes, ex: um objeto de base de dados único compartilhado por vários partes do programa. @kamilah_santos
  40. SINGLETON Utilize quando necessita de um controle mais restrito sobre

    as variáveis globais. @kamilah_santos
  41. ESTRUTURAIS Demonstram como estruturar objetos e classes em estruturas maiores

    porém mantendo estas eficientes e flexíveis. @kamilah_santos
  42. ADAPTER Permite que objetos com interfaces incompatíveis colaborem entre si.

    Fonte:https://refactoring.guru/pt-br/design-patterns/adapter @kamilah_santos
  43. ADAPTER Utilize quando querer reutilizar várias subclasses existentes que não

    tenham alguma funcionalidade comum que não possa ser adicionada a superclasse. @kamilah_santos
  44. BRIDGE Fonte:https://refactoring.guru/pt-br/design-patterns/bridge Permite que você divida uma classe grande em

    um conjunto de classes diretamente ligadas em hierarquias separadas (abstração e implementação) que podem ser desenvolvidas independentemente uma da outra. @kamilah_santos
  45. BRIDGE Utilize esse pattern quando precisar organizar/dividir uma classe monolítica

    que tenha diversas variações de uma mesma funcionalidade. @kamilah_santos
  46. COMPOSITE Permite que você componha objetos em estruturas de árvores

    e trabalhe com elas como se fossem estruturas objetos individuais. Fonte:https://refactoring.guru/pt-br/design-patterns/composite @kamilah_santos
  47. COMPOSITE Utilize quando deseja que o código cliente trate tanto

    os objetos simples quanto os compostos de forma uniforme. @kamilah_santos
  48. DECORATOR Permite que você acople novos comportamentos para objetos ao

    coloca-los dentro desses recipientes de objetos que contém esses comportamentos. Fonte: https://refactoring.guru/pt-br/design-patterns/decorator @kamilah_santos
  49. DECORATOR Utilize quando é complicado utilizar herança. @kamilah_santos

  50. FACADE Fornece interface simplificada para um framework, biblioteca ou qualquer

    outro conjunto complexo de classes Fonte: https://refactoring.guru/pt-br/design-patterns/facade @kamilah_santos
  51. FACADE Utilize quando precisar ter uma interface mais simples para

    um subsistema complexo e precisar organizar ele em camadas. @kamilah_santos
  52. FLYWEIGHT Permite colocar mais objetos na quantidade de RAM disponível

    ao compartilhar partes comuns de estado dentre múltiplos objetos ao invés de manter todos os dados em cada objeto. Fonte: https://refactoring.guru/pt-br/design-patterns/flyweight @kamilah_santos
  53. FLYWEIGHT Utilize quando sua aplicação deve suportar um grande número

    de objetos que mal cabem na RAM disponível. @kamilah_santos
  54. PROXY Permite que você tenha um programa substituto, que controla

    o acesso ao objeto original . Fonte: https://refactoring.guru/pt-br/design-patterns/proxy @kamilah_santos
  55. PROXY Sua maior utilização é para ser uma espécie de

    proxy de proteção, que controla o acesso aos outros serviços. @kamilah_santos
  56. COMPORTAMENTAIS São voltados para organização dos algoritmos e separação de

    responsabilidades entre os objetos. @kamilah_santos
  57. CHAIN OF RESPONSIBILITY Permite que você passse requisições por uma

    espécie de corrente de handlers , ao receber cada pedido o handler decide se processa ou passa para frente (próximo handler). Fonte: https://refactoring.guru/pt-br/design-patterns/chain-of- responsibility @kamilah_santos
  58. COMMAND Transforma um pedido em um objeto independente que contém

    os dados desse pedido. Essa transformação permite a parametrização dos métodos com diferentes pedidos e organize eles numa espécie de filas. Fonte: https://refactoring.guru/pt-br/design-patterns/command @kamilah_santos
  59. ITERATOR Permite percorrer elementos de uma coleção (lista,pilha.árvore) sem expor

    as informações dele. Fonte: https://refactoring.guru/pt-br/design-patterns/iterator @kamilah_santos
  60. MEDIATOR Restringe comunicações diretas entre objetos e os força a

    colaborar somente por meio do objeto mediador. Fonte: https://refactoring.guru/pt-br/design-patterns/mediator @kamilah_santos
  61. MEMENTO Permite que salve e restaure o estado anterior de

    um objeto sem revela detalhes da sua implementação. Fonte: https://refactoring.guru/pt-br/design-patterns/memento @kamilah_santos
  62. OBSERVER Permite que você defina um mecanismo de assinatura (subscriber)

    para notificar múltiplos objetos sobre qualquer evento que aconteça com o objeto que eles estão observando. Fonte: https://refactoring.guru/pt-br/design-patterns/observer @kamilah_santos
  63. STATE Permite que um objeto altere seu comportamento quando seu

    estado interno muda. Fonte: https://refactoring.guru/pt-br/design-patterns/state @kamilah_santos
  64. STRATEGY Permite que você defina uma família de algoritmos, os

    separe em classes e faça seus objetos intercambiáveis. Fonte: https://refactoring.guru/pt-br/design-patterns/strategy @kamilah_santos
  65. TEMPLATE METHOD Define o esqueleto de um algortimo em sua

    superclasse mas deixa as subclasses sobrescreverem passos específicos do algoritmo sem alterar sua estrutura. Fonte: https://refactoring.guru/pt-br/design-patterns/template- method @kamilah_santos
  66. VISITOR Permite que você separe algoritmos dos objetos nos quais

    eles operam. Fonte: https://refactoring.guru/pt-br/design-patterns/visitor @kamilah_santos
  67. CLEAN CODE @kamilah_santos

  68. 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
  69. 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
  70. CÓDIGO LIMPO Seja consistente Regra do escoteiro RASAP KISS @kamilah_santos

  71. CÓDIGO LIMPO 1. Use nomes que revelam a intenção 2.

    Use nomes Pronunciáveis/Procuráveis 3. Siga as convenções 4 - Não use o que você acha mais bonito/fofo 5 - Escolha uma palavra por Ideia/Conceito @kamilah_santos
  72. CODE SMELLS @kamilah_santos

  73. CODE SMELL - BLOATERS Long Method, Large Class,Long Parameters List,

    Data Clumps Fonte: https://refactoring.guru/refactoring/smells @kamilah_santos
  74. CODE SMELL - OBJECT-ORIENTATION ABUSERS Switch Statements, Temporary Field Fonte:

    https://refactoring.guru/refactoring/smells/oo-abusers @kamilah_santos
  75. CODE SMELL - CHANGE PREVENTERS Divergent Changes, Shotgun Surgery, Parallel

    Inheritance Hierarchies Fonte: https://refactoring.guru/refactoring/smells/change-preventers @kamilah_santos
  76. CODE SMELL - DISPENSABLES Comments, Duplicate Code, Dead Code Fonte:

    https://refactoring.guru/refactoring/smells/dispensables @kamilah_santos
  77. CODE SMELL - COUPLERS Feature Envy, Innapropriate Intimacy Fonte: https://refactoring.guru/refactoring/smells/couplers

    @kamilah_santos
  78. TESTES @kamilah_santos @kamilah_santos

  79. @kamilah_santos

  80. @kamilah_santos

  81. DOCUMENTAÇÃO @kamilah_santos

  82. DOCUMENTAÇÃO @kamilah_santos

  83. CODE REVIEW @kamilah_santos

  84. REFERÊNCIAS @kamilah_santos https://gist.github.com/Kamilahsantos/6b50816b9d21b7 866fa8446f7b92283c

  85. OBRIGADA <3 @kamilah_santos https://linktr.ee/kamila.dev