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

Slide 1

Slide 1 text

Kamila Santos O seu código não é só para você entender @kamilah_santos

Slide 2

Slide 2 text

@kamilah_santos Backend Developer Kamila Santos

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

L : LISKOV SUBSTITUTION PRINCIPLE PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV As classes derivadas devem poder ser substituíveis pelas classes bases @kamilah_santos

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

REFATORAÇÃO NO TDD @kamilah_santos

Slide 13

Slide 13 text

TÉCNICAS DE REFATORAÇÃO @kamilah_santos

Slide 14

Slide 14 text

RENOMEAR MÉTODO Problema: o nome do método não diz o que ele faz Solução: renomear o método @kamilah_santos

Slide 15

Slide 15 text

RENOMEAR MÉTODO Fonte: https://refactoring.guru/rename-method @kamilah_santos

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

MOVER MÉTODO https://refactoring.guru/move-method @kamilah_santos

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

MOVER CAMPO Extremamente similar ao mover método, mas nesse caso se trata de campos/variáveis. @kamilah_santos

Slide 23

Slide 23 text

MOVER CAMPO https://refactoring.guru/move-field @kamilah_santos

Slide 24

Slide 24 text

EXTRAIR CLASSE Problema: Uma classe tem mais de uma responsabilidade Solução: Criar um nova classe para separar essas responsabilidades @kamilah_santos

Slide 25

Slide 25 text

EXTRAIR CLASSE https://refactoring.guru/extract-class @kamilah_santos

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

CRIACIONAIS São aqueles que fornecem mecanismos de criação de objetos, aumentando a flexibilidade e reutilização do código @kamilah_santos

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

FACTORY METHOD Quando deseja economizar recursos do sistema reutilizando objetos em vez de recria- los sempre que necessário @kamilah_santos

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

BUILDER Utilize quando desejar que seu código seja capaz de criar variadas representações de um mesmo produto. @kamilah_santos

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

PROTOTYPE Utilize quando precisar reduzir o número de subclasses que só diferem na forma de inicialização dos sues respectivos objetos. @kamilah_santos

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

SINGLETON Utilize quando necessita de um controle mais restrito sobre as variáveis globais. @kamilah_santos

Slide 41

Slide 41 text

ESTRUTURAIS Demonstram como estruturar objetos e classes em estruturas maiores porém mantendo estas eficientes e flexíveis. @kamilah_santos

Slide 42

Slide 42 text

ADAPTER Permite que objetos com interfaces incompatíveis colaborem entre si. Fonte:https://refactoring.guru/pt-br/design-patterns/adapter @kamilah_santos

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

BRIDGE Utilize esse pattern quando precisar organizar/dividir uma classe monolítica que tenha diversas variações de uma mesma funcionalidade. @kamilah_santos

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

COMPOSITE Utilize quando deseja que o código cliente trate tanto os objetos simples quanto os compostos de forma uniforme. @kamilah_santos

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

DECORATOR Utilize quando é complicado utilizar herança. @kamilah_santos

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

FACADE Utilize quando precisar ter uma interface mais simples para um subsistema complexo e precisar organizar ele em camadas. @kamilah_santos

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

FLYWEIGHT Utilize quando sua aplicação deve suportar um grande número de objetos que mal cabem na RAM disponível. @kamilah_santos

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

COMPORTAMENTAIS São voltados para organização dos algoritmos e separação de responsabilidades entre os objetos. @kamilah_santos

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

STATE Permite que um objeto altere seu comportamento quando seu estado interno muda. Fonte: https://refactoring.guru/pt-br/design-patterns/state @kamilah_santos

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

VISITOR Permite que você separe algoritmos dos objetos nos quais eles operam. Fonte: https://refactoring.guru/pt-br/design-patterns/visitor @kamilah_santos

Slide 67

Slide 67 text

CLEAN CODE @kamilah_santos

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

CÓDIGO LIMPO Seja consistente Regra do escoteiro RASAP KISS @kamilah_santos

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

CODE SMELLS @kamilah_santos

Slide 73

Slide 73 text

CODE SMELL - BLOATERS Long Method, Large Class,Long Parameters List, Data Clumps Fonte: https://refactoring.guru/refactoring/smells @kamilah_santos

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

CODE SMELL - CHANGE PREVENTERS Divergent Changes, Shotgun Surgery, Parallel Inheritance Hierarchies Fonte: https://refactoring.guru/refactoring/smells/change-preventers @kamilah_santos

Slide 76

Slide 76 text

CODE SMELL - DISPENSABLES Comments, Duplicate Code, Dead Code Fonte: https://refactoring.guru/refactoring/smells/dispensables @kamilah_santos

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

TESTES @kamilah_santos @kamilah_santos

Slide 79

Slide 79 text

@kamilah_santos

Slide 80

Slide 80 text

@kamilah_santos

Slide 81

Slide 81 text

DOCUMENTAÇÃO @kamilah_santos

Slide 82

Slide 82 text

DOCUMENTAÇÃO @kamilah_santos

Slide 83

Slide 83 text

CODE REVIEW @kamilah_santos

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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