Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Kamila Santos Dev Backend

Slide 3

Slide 3 text

Agenda • solid • dry • refatoração • design patterns • clean code • code smells • testes • componentização •documentação •code review @kamilah_santos

Slide 4

Slide 4 text

S.O.L.I.D @kamilah_santos

Slide 5

Slide 5 text

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

Slide 6

Slide 6 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 7

Slide 7 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 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 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 11

Slide 11 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 12

Slide 12 text

REFATORAÇÃO @kamilah_santos

Slide 13

Slide 13 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 14

Slide 14 text

Refatoração no TDD @kamilah_santos

Slide 15

Slide 15 text

@kamilah_santos

Slide 16

Slide 16 text

Técnicas de refatoração @kamilah_santos

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

@kamilah_santos

Slide 19

Slide 19 text

@kamilah_santos

Slide 20

Slide 20 text

Extrair método Esta técnica pode ser utilizada quando precisamos quebrar um método que possui mais de uma responsabilidade. @kamilah_santos

Slide 21

Slide 21 text

@kamilah_santos

Slide 22

Slide 22 text

@kamilah_santos

Slide 23

Slide 23 text

@kamilah_santos

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@kamilah_santos

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

@kamilah_santos

Slide 28

Slide 28 text

Mover método Depois desta separação, a classe InativarClientesWorker ficaria assim: @kamilah_santos

Slide 29

Slide 29 text

@kamilah_santos

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

@kamilah_santos

Slide 33

Slide 33 text

@kamilah_santos

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

@kamilah_santos

Slide 37

Slide 37 text

@kamilah_santos

Slide 38

Slide 38 text

@kamilah_santos

Slide 39

Slide 39 text

Extrair classe Com as responsabilidades separadas e com os métodos simplificados, podemos ver nomes mais claros para as nossas classes. @kamilah_santos

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

@kamilah_santos

Slide 42

Slide 42 text

DESIGN PATTERNS @kamilah_santos

Slide 43

Slide 43 text

Padrões de projeto Soluções/modelos generalistas para questões recorrentes no desenvolvimento de software @kamilah_santos

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Template Method É um padrão comportamental, que tem como objetivo simplificar as responsabilidades dos objetos @kamilah_santos

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

@kamilah_santos

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Strategy Devemos encapsular cada um deles pelas estratégias de modo que possamos realizar a troca entre elas facilmente. @kamilah_santos

Slide 54

Slide 54 text

Adapter É recomendável de ser utilizado quando temos duas classes com interfaces diferentes, porém que precisam trabalhar em conjunto. @kamilah_santos

Slide 55

Slide 55 text

Adapter Devemos isolar as responsabilidades de uma interface para outra do restante da lógica do nosso negócio. @kamilah_santos

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

CLEAN CODE @kamilah_santos

Slide 58

Slide 58 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 59

Slide 59 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 60

Slide 60 text

@kamilah_santos

Slide 61

Slide 61 text

Seja consistente @kamilah_santos

Slide 62

Slide 62 text

Regra do escoteiro @kamilah_santos

Slide 63

Slide 63 text

DRY @kamilah_santos

Slide 64

Slide 64 text

RASAP @kamilah_santos

Slide 65

Slide 65 text

KISS @kamilah_santos

Slide 66

Slide 66 text

1. Use nomes que revelam a intenção @kamilah_santos

Slide 67

Slide 67 text

2. Use nomes Pronunciáveis/Procuráveis @kamilah_santos

Slide 68

Slide 68 text

3. Siga as convenções @kamilah_santos

Slide 69

Slide 69 text

4 - Não use o que você acha mais bonito/fofo @kamilah_santos

Slide 70

Slide 70 text

5 - Escolha uma palavra por Ideia/Conceito @kamilah_santos

Slide 71

Slide 71 text

CODE SMELLS @kamilah_santos

Slide 72

Slide 72 text

Code Smell - Bloaters @kamilah_santos

Slide 73

Slide 73 text

Code Smell - Object-Orientation Abusers @kamilah_santos

Slide 74

Slide 74 text

Code Smell - Change Preventers @kamilah_santos

Slide 75

Slide 75 text

Code Smell - Dispensables @kamilah_santos

Slide 76

Slide 76 text

Code Smell - Couplers @kamilah_santos

Slide 77

Slide 77 text

TESTES @kamilah_santos

Slide 78

Slide 78 text

TESTES DE INTERFACE @kamilah_santos

Slide 79

Slide 79 text

TESTES DE INTERFACE @kamilah_santos

Slide 80

Slide 80 text

TESTES DE INTERFACE @kamilah_santos

Slide 81

Slide 81 text

TESTES DE INTEGRACAO @kamilah_santos

Slide 82

Slide 82 text

TESTES DE INTEGRACAO @kamilah_santos

Slide 83

Slide 83 text

TESTES DE INTEGRACAO @kamilah_santos

Slide 84

Slide 84 text

TESTES UNITARIOS @kamilah_santos

Slide 85

Slide 85 text

TESTES UNITARIOS @kamilah_santos

Slide 86

Slide 86 text

TESTES UNITARIOS @kamilah_santos

Slide 87

Slide 87 text

TESTES UNITARIOS @kamilah_santos

Slide 88

Slide 88 text

TESTES UNITARIOS @kamilah_santos

Slide 89

Slide 89 text

TESTES UNITARIOS @kamilah_santos

Slide 90

Slide 90 text

TESTES UNITARIOS @kamilah_santos

Slide 91

Slide 91 text

TESTES UNITARIOS @kamilah_santos

Slide 92

Slide 92 text

TESTES UNITARIOS @kamilah_santos

Slide 93

Slide 93 text

COMPONENTIZAÇÃO @kamilah_santos

Slide 94

Slide 94 text

SMART COMPONENTS @kamilah_santos

Slide 95

Slide 95 text

DUMB COMPONENTS @kamilah_santos

Slide 96

Slide 96 text

Documentação @kamilah_santos

Slide 97

Slide 97 text

Documentação @kamilah_santos

Slide 98

Slide 98 text

Documentação @kamilah_santos

Slide 99

Slide 99 text

Documentação @kamilah_santos

Slide 100

Slide 100 text

Code review @kamilah_santos

Slide 101

Slide 101 text

Referencias https://gist.github.com/Ka milahsantos/6b50816b9d21 b7866fa8446f7b92283c @kamilah_santos

Slide 102

Slide 102 text

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