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

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