Douglas Siviotti, profile picture
Carregado porDouglas Siviotti
1,159 visualizações

Clean Code na Prática

Este documento apresenta conceitos de código limpo em exemplos de código. Apresenta 4 partes: 1) Filosofia, 2) Teoria, 3) Prática com exemplos de código, 4) Laboratório de refatoração. Fornece conceitos como DDD, SRP, DRY, testes, refatoração e regras de simplicidade aplicados a exemplos de código.

Incorporar apresentação

Baixado 17 vezes
1 / 145
2 / 145
3 / 145
4 / 145
5 / 145
6 / 145
7 / 145
8 / 145
9 / 145
10 / 145
11 / 145
12 / 145
13 / 145
14 / 145
15 / 145
16 / 145
17 / 145
18 / 145
19 / 145
20 / 145
21 / 145
22 / 145
23 / 145
24 / 145
25 / 145
26 / 145
27 / 145
28 / 145
29 / 145
30 / 145
31 / 145
32 / 145
33 / 145
34 / 145
35 / 145
36 / 145
37 / 145
38 / 145
39 / 145
40 / 145
41 / 145
42 / 145
43 / 145
44 / 145
45 / 145
46 / 145
47 / 145
48 / 145
49 / 145
50 / 145
51 / 145
52 / 145
53 / 145
54 / 145
55 / 145
56 / 145
57 / 145
58 / 145
59 / 145
60 / 145
61 / 145
62 / 145
63 / 145
64 / 145
65 / 145
66 / 145
67 / 145
68 / 145
69 / 145
70 / 145
71 / 145
72 / 145
73 / 145
74 / 145
75 / 145
76 / 145
77 / 145
78 / 145
79 / 145
80 / 145
81 / 145
82 / 145
83 / 145
84 / 145
85 / 145
86 / 145
87 / 145
88 / 145
89 / 145
90 / 145
91 / 145
92 / 145
93 / 145
94 / 145
95 / 145
96 / 145
97 / 145
98 / 145
99 / 145
100 / 145
101 / 145
102 / 145
103 / 145
104 / 145
105 / 145
106 / 145
107 / 145
108 / 145
109 / 145
110 / 145
111 / 145
112 / 145
113 / 145
114 / 145
115 / 145
116 / 145
117 / 145
118 / 145
119 / 145
120 / 145
121 / 145
122 / 145
123 / 145
124 / 145
125 / 145
126 / 145
127 / 145
128 / 145
129 / 145
130 / 145
131 / 145
132 / 145
133 / 145
134 / 145
135 / 145
136 / 145
137 / 145
138 / 145
139 / 145
140 / 145
141 / 145
142 / 145
143 / 145
144 / 145
145 / 145
Clean Code na Prática Conceitos de Clean Code Apresentados em Exemplos de Código Douglas Siviotti Maio de 2019 V1.0
Sobre esta Apresentação 1. Conteúdo: Clean Code (Código Limpo) 2. Área/Foco: Engenharia de Software, Desenvolvimento Ágil 3. Público alvo: Desenvolvedores (nível intermediário de experiência em OO) 4. Conteúdo relacionado: OO, Programação Funcional, DDD, SOLID, GRASP Organização Parte 1 – Um Pouco de Filosofia Parte 2 – Um Pouco de Teoria Parte 3 – Clean Code na Prática em Exemplos de Código Parte 4 – Laboratório de Refatoração Material de apoio desta apresentação: https://github.com/refactown/cleancode
Sintomas comuns equipe entregando cada vez menos pontos a cada sprint estimativas frustradas: o esforço é sempre maior que o previsto erros frequentes em produção correção de um bug causa outros problemas não previstos incidentes resolvidos e o mesmo erro voltando a aparecer muito “To Do” espalhado pelo código e/ou código morto dificuldade de evolução ou incorporação de novas funcionalidades
Código Ruim manutenção difícil + retrabalho e - produtividade Código Ruim manutenção difícil + retrabalho e - produtividade Procrastinação aversão a mudanças criação de dívida técnica Procrastinação aversão a mudanças criação de dívida técnica Falta de Testes design pobre e inflexível falta de segurança p/ o dev Falta de Testes design pobre e inflexível falta de segurança p/ o dev Pressão bugs, incidentes, pouco valor, baixa evolução: insatisfação Pressão bugs, incidentes, pouco valor, baixa evolução: insatisfação ciclo vicioso da dívida técnica
Código Limpo fácil de entender e manter expressa o negócio Código Limpo fácil de entender e manter expressa o negócio Refatoração adaptação ao novo problema tratamento de dívida técnica Refatoração adaptação ao novo problema tratamento de dívida técnica Teste de Unidade guiando o design (feedback) com boa cobertura Teste de Unidade guiando o design (feedback) com boa cobertura Entregas c/ Valor evolução sustentável cliente satisfeito Entregas c/ Valor evolução sustentável cliente satisfeito ciclo da eficácia no software sob medida
Clean Code fácil de entender e manter expressa o negócio Clean Code fácil de entender e manter expressa o negócio Refatoração adaptação ao novo problema tratamento de dívida técnica Teste de Unidade guiando o design (feedback) com boa cobertura Entregas c/ Valor evolução sustentável cliente satisfeito ciclo da eficácia no software sob medida
Um PoucoUm Pouco de Filosofiade Filosofia Parte 1
Pequenas CoisasPequenas Coisas ImportamImportam “Deus está nos detalhes” “Menos é mais” (Ludwig Mies van der Rohe) Quem não faz bem as pequenas coisas, não faz bem coisa alguma
código é detalhamentocódigo é detalhamento dos requisitos e devedos requisitos e deve expressar o negócioexpressar o negócio
código deve ser feito para ser lido por outra pessoacódigo deve ser feito para ser lido por outra pessoa comunique, não codifique!
código ruim geracódigo ruim gera baixa produtividadebaixa produtividade que gera código piorque gera código pior seja um glóbulo branco prevenir é melhor que remediar por que
CódigoCódigo Limpo?Limpo? “elegante e eficiente faz apenas uma coisa” Bjarne Stroustrup “simples e direto - legível” Grady Booch “inteligível ao seres humanos” Dave Thomas “escrito por alguém que se importava” Michael Feathers “sem duplicação, expressivo, pequenas abstrações” Ron Jeffries “a linguagem parece que foi feita para o problema” Ward Cunningham O que é
A T I T U D EA T I T U D E teoria da janela quebrada regra do escoteiro quando programador profissional quem quando
técnica, treino e tempotécnica, treino e tempo livros de arte não fazem um artista trabalho artesanal mas profissional como
Um Pouco de Teoria*Um Pouco de Teoria* *Oriunda de muita prática*Oriunda de muita prática Parte 2
Título do Slide (Arial 18) 16/145 2.1 DDD: Negócio ao Código 2.2 Linguagem Onipresente 2.3 Princípio SRP 2.4 Princípio DRY 2.5 Indireção / Delegação 2.6 Lei de Demeter 2.7 Acoplamento e Coesão 2.8 Imutabilidade 2.9 OO + Funções Puras 2.10 Testes Tempestivos 2.11 Refatoração Tempestiva 2.12 Regras da Simplicidade Conceitos relacionados
O requisito está no código, mas muito código não vem do requisito O domínio de um problema organiza os conceitos sobre os quais é baseada a solução de software Foco no Negócio Parte do código deve expressar o negócio Isolamento do Domínio O código de domínio é idiossincrático e particular Infraestrutura à Parte Tecnologias vêm e vão, o negócio permanece Do Negócio ao Código Via DDD 2.1 Negócio ao Código Domain
DDD e os Nomes das Coisas 2.2 Linguagem Onipresente Ubiquos Language Service Entity Value Object Agregate Factory Model-driven Design Bounded Context RepositoryDomain Events Layered Architecture Core Domain Context Map Continuos Integration Linguagem Onipresente (Ubíqua) - Termos e conceitos usados pelos desenvolvedores e pelos especialistas no negócio - Presente na fala de todos e no código de domínio Contexto Delimitado - Partes bem delimitadas de um domínio - Candidatos a microsserviços Tijolos de Construção - Entidades, Objetos de Valor, Agregados - Eventos de Domínio - Serviços, Fábricas, Repositórios
Princípio da Responsabilidade Única (SRP) 2.3 Princípio SRP “Cada módulo de um software deve ter um e apenas um motivo para mudar” 1 O que seria apenas “uma” responsabilidade?
Menos é Mais 2.4 Princípio DRY DRY = Don’t Repeat Yourself “Não Se Repita” (código, requisito, teste etc) Toda parte do conhecimento deve ter uma representação única e livre de ambiguidades em todo o sistema Problemas - Mais trabalho: alterar mais vezes - Mais risco: encontrar todos os lugares - Mais teste: testar várias vezes a mesma coisa - Mais esforço de comunicação
Indireção ou Delegação 2.5 Indireção / Delegação SRP Fazer apenas uma coisa em um certo lugar SRP Fazer apenas uma coisa em um certo lugar DRY Fazer apenas em um lugar uma certa coisa DRY Fazer apenas em um lugar uma certa coisa Coisa única em um único lugar “A” Coisa única em um único lugar “A” Outra coisa única em um único lugar “B” Outra coisa única em um único lugar “B” Indireção ou Delegação 1. Não pode conter 2. Não pode copiar 3. Precisa referenciar Indireção Indireção Calculo de Frete Busca de EndereçoEfetuar Pedido
Lei de Demeter – Princípio do Menor Conhecimento 2.6 Lei de Demeter Um módulo não deve enxergar o interior dos objetos que ele manipula Um método “f” de uma classe “C” só deve chamar: - “C” - Um objeto criado por “f” - Um objeto passado por parâmetro para “f” (e.g. “p”) - Um objeto dentro de uma variável de instância de “C” Train Wreck (Acidente de Trem): p.getY().getZ() Classe “C” Atributo A: A Método “f” (p: X) Classe X Atributo Y : Y Classe Y Atributo Z : Z
Baixo Acoplamento e Alta Coesão 2.7 Acoplamento e Coesão Alto Acoplamento Baixa Coesão (entre classes) Poucas classes e grandes Mais dependência por classe Maior conhecimento Baixo Acoplamento Alta Coesão (entre classes) Muitas classes e pequenas Menos dependência por classe Menor conhecimento Coesão de uma Classe: - Poucas variáveis de instância - Cada método manipula uma ou mais Uma classe pouco coesa sugere que uma nova classe deve “nascer”
Quanto Mais Imutável Melhor 2.8 Imutabilidade Evite Surpresas Imutabilidade é uma defesa contra efeitos colaterais Vantagens - Mais seguro e confiável - Mais legível: minimiza testes e garantias diminui o código por tabela - Paralelismo e escalabilidade private final int idade;
Quanto Mais Puro Melhor 2.9 OO + Funções Puras Função Pura 1. Para um certo Input sempre retorna o mesmo Output 2. Não causa nenhum efeito colateral 3. Não depende de nenhum dado externo (autocontida) Vantagens - Mais simples e menores - Mais fácil de entender e testar Quando usar em código OO? Sempre que possível Em muitas situações não é possível: BD, integração, estados etc Possível em regras de negócio, métodos utilitários, internos etc Function Input Output IMUTABILIDADE - efeitos colaterais
TDD e Testes Tempestivos 2.10 Testes Tempestivos TDD – Test Driven Development (Desenvolvimento Guiado por Testes) - Escreve um teste que falha antes do código produtivo - Faz o teste passar ao construir o código produtivo - Refatora o código até o teste falhar (ou não) Testes Tempestivos (TDD inclusive) (teste que ajuda na construção, logo cedo) 1. Atividade de engenharia (código e design) 2. Feedback rápido sobre o código testado (erra cedo) 3. Gera código limpo através da “dificuldade” de testar 4. Antecipa o custo gasto em correções e debug 5. Ainda serve como teste de regressão Refatora Falha Passa Ciclos Curtos
Refatoração Tempestiva 2.11 Refatoração “Refatoração (refactoring) é a disciplina técnica para reestruturar um determinado código, alterando sua estrutura interna sem mudar seu comportamento externo” Martin Fowler Problema Inicial Solução Inicial Problema Refinado Refatoração Mudança Solução Final Validar Solução Refinamento Ciclo de Sprint Ajuste da solução em função de: - uma nova visão sobre o problema - preparar para uma evolução ou mudança Pequenas mudanças que fazem diferença no longo prazo
Quatro Regras da Simplicidade (Martin Fowler : Kent Beck) 2.12 Simplicidade Testes Tempestivos Refatoração Tempestiva https://martinfowler.com/bliki/BeckDesignRules.html
Conceitos Relacionados Conceitos DDDDDD Linguagem Onipresente Linguagem Onipresente Indireção Abstração, especialização Indireção Abstração, especialização Lei de Demeter Mínimo conhecimento Lei de Demeter Mínimo conhecimento Princípio SRP Responsabilidade Única Princípio SRP Responsabilidade Única Princípio DRY Não Se Repita Princípio DRY Não Se Repita Acoplamento e Coesão Acoplamento e Coesão Funções Puras OO ou funcional Funções Puras OO ou funcionalInfraInfra DomínioDomínio AppApp Refatoração Tempestiva Refatoração Tempestiva Teste Tempestivo Teste Tempestivo 4 Regras da Simplicidade 4 Regras da Simplicidade Imutabilidade - efeitos colaterais Imutabilidade - efeitos colaterais Clean Code Clean Code
PráticaPrática Parte 3
Título do Slide (Arial 18) 31/145 3.1 Código Limpo 3.2 Nomes Significativos 3.3 Funções* 3.4 Comentários 3.5 Formatação 3.6 Objetos e E. de Dados 3.7 Tratamento de Erro 3.8 Fronteiras (Limites) 3.9 Testes de Unidade 3.10 Classes 3.11 Sistemas Complexos 3.12 Simplicidade Prática - filosofia - bad smell - boa prática - exemplo - exercício Cognição Entendimento e leitura Integração Contratos e expectativas Design Escala e expansão
Código LimpoCódigo Limpo Parte 3.1Parte 3.1
Filosofia sobre Código Limpo 3.1 Código Limpo - O código não fica nem se mantém limpo sozinho - Todos na equipe devem praticar e cobrar - Manter o código limpo é uma atividade diária - Funciona como na “Teoria das janelas quebradas” - Atitude é mais relevante do que “patrocínio” - Sempre dá pra começar (regra do escoteiro) - Ler e entender consome mais tempo que escrever - Precisa de tempo, técnica e treino pra fazer bem
Código Ruim 3.1 Código Limpo Problemas - Nomes ruins - Função grande e complexa (SRP) - Comentários questionáveis - Formatação inexistente Dificuldades - Legibilidade: confuso - Testabilidade: alta complexidade
Código Menos Ruim 3.1 Código Limpo Problemas - Nomes ruins - Função grande e complexa (SRP) - Comentários questionáveis - Formatação inexistente Dificuldades - Legibilidade: confuso - Testabilidade: alta complexidade
Código Melhorado 3.1 Código Limpo O que aina pode ser melhorado?
Possíveis Melhorias 3.1 Código Limpo
NomesNomes SignificativosSignificativos Parte 3.2Parte 3.2
Filosofia sobre Nomes 3.2 Nomes Significativos - Nomes são muito importante (especialmente em OO) - Use nomes que revelam seu propósito - Evite informações erradas (itemList: Map) - Faça distinções significativas (evite a1, a2 a3...) - Nomes pronunciáveis e passíveis de busca - Evite codificações (e.g. notação húngara e similares) - classes = substantivos, métodos = verbos - Selecione uma palavra por conceito (get, set, find) - Nomes do problema (Pedido, Item) e da solução (DAO) - Adicione ou evite contexto quando necessário
Bad Smell 3.2 Nomes Significativos Problemas - Nomes genéricos “i”, “x”, “d” etc - Nomes impronunciáveis - Número Mágico (perdido no código) - Notação Húngara - Interface prefixada - Nome com contexto redundante
Boa Prática 3.2 Nomes Significativos Alternativas - Nomes que revelam propósito - Nomes pronunciáveis - Constantes para número mágico (passíveis de busca) - Sem Notação Húngara - Interface = Conceito - Nomes com o mínimo necessário
Problema x Solução 3.2 Nomes Significativos Problema Solução
Modelo de Exemplo 3.2 Nomes Significativos Nomes a partir do domínio do problema (Pedido, Item etc) Nomes a partir do domínio da solução (Controller, Delegate, DAO) Classes = Substantivos, Métodos = Verbos Nomes pronunciáveis e passíveis de busca
Parte 3.3Parte 3.3 FunçõesFunções
Filosofia sobre Funções 3.3 Funções - Funções devem ser pequenas (<= 20 linhas) - Funções devem fazer apenas uma coisa - Devem ter nomes descritivos do que fazem - Somente um nível de abstração por função - Funções devem ter poucos parâmetros - Efeitos colaterais devem ser evitados ao máximo - Quanto mais funções puras, melhor - Quanto mais autocontida mais fácil de testar
Clean Code (2008) Programação Funcional (1958) Pura Sem efeitos colaterais 1 nível de abstração Faz apenas 1 coisa Pequena Clean Code + Programação Funcional 3.3 Funções
Regra 1 3.3 Funções Faz Apenas 1 Coisa - Nomes, comentários e formatação são importantes para a leitura, mas as funções são o que o programa realmente faz - É melhor ler e entender uma coisa de cada vez - É melhor testar uma coisa de cada vez 1 Nível de Abstração - Cada conceito em seu lugar apropriado Abstração é a capacidade de separar o essencial do que não é essencial. Separar conceitos dos detalhes.
Exemplo de Função “Suja” 3.3 Funções Grande (30 linhas) Faz muitas coisas: 1. Decide qual classe deve ser avaliada 2. Lista os campos de uma classe e superclasses 3. Lista os “tipos inteiros” 4. Infere se é constante 5. Faz a contagem Níveis de abstração 1 2 3 4 5
Exemplo de Função “Limpa” 3.3 Funções Pequena (11 linhas) Faz 1 coisa: 1. Decide qual classe deve ser avaliada 2. Lista os campos de uma classe e superclasses 3. Lista os “tipos inteiros” 4. Infere se é constante 5. Faz a contagem 1 nível de abstração 1 coisa e 1 nível de abstração Indireção
Regra Decrescente 3.3 Funções Indireção Nível de abstração 1 Nível de abstração 2 Leitura de cima para baixo Nomes descritivos do que fazem
Switch Highlander 3.3 Funções Um “Switch” deve estar em uma classe de nível mais baixo de abstração e nunca ser repetido Opção procedural Opção polimórfica
Fibonacci (Funções Puras) 3.3 Funções 1. Para um certo Input sempre retorna o mesmo Output 2. Não causa nenhum efeito colateral 3. Não depende de nenhum dado externo (escopo)
Pedra, Papel e Tesoura 3.3 Funções Cabeçalho da Função: rockPaperScissors(char,char):int Contrato da Função: - Recebe dois caracteres (R, P ou S) - Se empata retorna 0 - Se o primeiro ganha retorna -1 - Se o segundo ganha retorna 1 - Se um dos caracteres é inválido gera uma exceção “IllegalArgumentException” (melhor que código de erro) - R vence S, S vence P, P vence R
Pedra, Papel e Tesoura 3.3 Funções √ 1 Nível de abstração É uma função pura? √ Faz apenas 1 coisa Prefira exceções a retorno de códigos de erro!
Parâmetros 3.3 Funções Função Mônade P1 Função Díade Função Tríade P1 P2 P3 P1 P2 A quantidade de parâmetros deve ser a menor possível. Se a quantidade de parâmetros é muito grande, pode ser usado um objeto como parâmetro. Objeto como Parâmetro O parâmetro tem suas regras e seus próprios conceitos
Parâmetros Seletores e de “Saída” 3.3 Funções Parâmetro de “Saída” Saída deve ser no retorno Parâmetro Seletor É preferível dividir em duas funções Um parâmetro seletor já indica logo na assinatura que uma função faz duas coisas. O ideal é fazer duas funções separadas.
Separação Comando-Consulta 3.3 Funções Comando + Consulta Apenas Consulta Apenas Comando As funções devem somente fazer ou responder algo, mas não ambos. Ou altera o estado de um objeto ou retorna informação sobre ele.
Tratamento de Erro é 1 Coisa Só 3.3 Funções O “try” deve ser a primeira linha da função e não deve haver nada depois fim do bloco “try/catch/finally”
O Cerne de Boas Funções 3.3 Funções Evite Repetição (DRY) - Indireção, extração etc podem gerar duplicação - Funções menores e especializadas requerem reúso (SRP) Faça e Refaça com Confiança - Comece fazendo funcionar e depois refatore - Tenha cobertura de testes para ter confiança Funções são verbos do domínio - Uma hierarquia de funções conta uma estória - Níveis de abstração ajudam na leitura da estória
Parte 3.4Parte 3.4 ComentáriosComentários
Filosofia sobre Comentários 3.4 Comentários “Qualquer um pode escrever código que o computador entenda. Bons programadores escrevem códigos que os humanos entendem.” Martin Fowler - Comentários são a última opção do programador - O programador deve expressar-se no código - Comunique, não codifique (outros devem ler) - Comentário pode estar compensando código ruim - Alguns comentários são bons ou necessários
Explique-se no Código 3.4 Comentários Alguns comentários existem para explicar código ruim. Um comentário deve explicar “o porquê” e nunca “o que” Não comente, refatore!
Comentários Bons: Legais e APIs Públicas 3.4 Comentários
Comentários Bons: Alguns “TODO”, Alertas e Destaques 3.4 Comentários
Comentário Ruim: Murmúrio e Redundância 3.4 Comentários
Comentário Ruim: Código Morto e/ou com Autoria 3.4 Comentários Use o controle de versão!
Outros Comentários Ruins 3.4 Comentários - Ruidosos, muito longos ou repetitivos - Imperativos (e.g. em todas as funções) - Marcadores de Posição //////////////// ou ************ - Ao lado de chaves de fechamento (e.g. //for) - Comentários em HTML - Informações excessivas - Conexões nada óbvias - Cabeçalhos de funções (prefira um bom nome) - Javadoc em código não público
Parte 3.5Parte 3.5 FormataçãoFormatação
Filosofia sobre Formatação 3.5 Formatação - Atenção ao “code convention” da linguagem - O projeto deve ter um “code style” (bom ou ruim) - Qualquer “code style” é melhor que nenhum - A formatação automática evita muitas brigas - Formatação vertical Metáfora do jornal, distância vertical, espaçamento e continuidade vertical - Formatação horizontal Indentação, espaçamento e continuidade horizontal
Formatação Vertical: Metáfora do Jornal 3.5 Formatação
Formatação Vertical: Continuidade e Espaçamento Vertical 3.5 Formatação Linhas de código relacionadas devem permanecer unidas Pensamentos completos devem ser separados por espaços em branco
Formatação Vertical: Distância Vertical 3.5 Formatação Declaração de Variável O mais próximo possível de onde será usada Variáveis de Instância Antes dos métodos Funções Dependentes Verticalmente próximas Afinidade Conceitual Mesma convenção de nomes atuam na mesma tarefa devem ficar próximas
Formatação Horizontal 3.5 Formatação Evite - Espaçamentos manuais - Indentação do “seu gosto” - Mais de 120 caracteres por linha Deixe a IDE trabalhar - Espaçamentos automáticos - Indentação padrão - Quebras de linha
Regra da Tela 3.5 Formatação <= 20 Cabe na tela <= 500 100-120 Cabe na tela
Code Convention + Regra da Equipe 3.5 Formatação Mantenha a paz no seu projeto: tenha um “code style” combinado pela equipe
Objetos e EstruturasObjetos e Estruturas de Dadosde Dados Parte 3.6Parte 3.6
Filosofia sobre Objetos e Estruturas de Dados 3.6 Objetos e E. de Dados Os objetos usam abstrações para esconder seus dados e expõem funções que operam sobre eles Estruturas de dados expõem seus dados e não possuem funções significativas (get/set = acessores) - Objetos buscam o menor conhecimento - Estruturas de dados (DTO) buscam imutabilidade
Estruturas de Dados nas Linguagens 3.6 Objetos e E. de Dados Kotlin tem uma palavra reservada para definir uma estrutura de dados: “data”. A sintaxe deixa clara a diferença entre uma estrutura de dados e demais classes/objetos
Procedural x Orientado a Objetos (OO) 3.6 Objetos e E. de Dados E se precisar calcular o perímetro? (as estruturas de dados não serão afetadas) E se precisar criar a classe triângulo?
Espectros de Objetos / Estrutura de Dados 3.6 Objetos e E. de Dados Encapsulamento Estrutura de Dados ObjetosHíbridos Imutabilidade Facilita a adição de novas funcionalidades Facilita a adição de novas classes Triângulo Perímetro
Feature Envy (Inveja de Funcionalidade) 3.6 Objetos e E. de Dados https://martinfowler.com/bliki/TellDontAsk.html Uma parte do código tem “inveja” da funcionalidade de outra parte No exemplo abaixo, “isValidOrder” tem inveja da funcionalidade que diz se um pedido é válido Princípio “Tell Don’t Ask” Indireção
Feature Envy no Modelo de Figuras (Shape) 3.6 Objetos e E. de Dados
Feature Envy + Efeitos Colaterais 3.6 Objetos e E. de Dados
Lei de Demeter 3.6 Objetos e E. de Dados x = a.getB().getC().getD()x = a.b.c.d Train Wrecks (Acidente de Trem) a b c d NullPointer Exception (null) Estrutura de Dados Objetos - Imutabilidade - Proibição de “null” - Estados mutáveis - Possibilidade de “null” x = a?.b?.c?.d (Navegação Segura)
Parte 3.7Parte 3.7 Tratamento de ErroTratamento de Erro
Filosofia sobre Tratamento de Erro 3.7 Tratamento de Erros - Use exceções em vez de retornar códigos - Prefira exceções não verificadas (unchecked) - Forneça exceções com contexto e sem abafamento - Pense no design do “try-catch-finally” antes - Defina exceções pensando no chamador (e.g. Libs) - Cada “catch” faz apenas uma coisa - Não retorne nem passe “null” - Dê preferência às exceções já fornecidas (efective java)
Código de Exceção Ruim 3.7 Tratamento de Erros Problemas - Não retorna uma exceção - Abafa exceção do Gson - Retorna “null” - Imprime direto no console Consequências - Contrato baseado em “null” - Omissão do erro raiz (causa) - Força a testar nulidade: kotlin: ?. java: if (result != null) - Log inadequado e ineficiente
Código de Exceção com Perda da Causa Raiz 3.7 Tratamento de Erros Problemas - Não retorna uma exceção - Abafa exceção do Gson - Retorna “null” - Imprime direto no console Consequências - Contrato baseado em “null” - Omissão do erro raiz (causa) - Força a testar nulidade: kotlin: ?. java: if (result != null) - Log inadequado e ineficiente
Código Melhorado (Repassando a Causa Raiz) 3.7 Tratamento de Erros O que acontece se “json” ou “clazz” forem nulos? Por que nunca se deve passar “null” como parâmetro?
Código de Teste Obtendo a Causa Raiz (Gson) 3.7 Tratamento de Erros
Questão Sobre a Criação de Classes de Exceção 3.7 Tratamento de Erros Existe realmente a necessidade de criar a exceção “JsonException”? Não seria melhor usar as exceções prontas do Gson?
Parte 3.8Parte 3.8 FronteirasFronteiras
Filosofia sobre Fronteiras 3.8 Fronteiras - Código de terceiro quase sempre é “infraestrutura” - Infraestrutura deve ser isolada do negócio - Testes de aprendizado são uma boa dica
Estudo de Caso do Parsing de Json 3.8 Fronteiras Necessidade Fazer parsing e serialização de Json em várias partes da aplicação Inicialmente usando o “Gson” Opcionalmente pode ser usado outra biblioteca como “Jackson” A infraestrutura deve ser isolada Domain ControllerController JsonParser Interface toJson() fromJson() JsonParser Interface toJson() fromJson() GsonParserGsonParser JacksonParserJacksonParser
Estudo de Caso do Parsing de Json 3.8 Fronteiras Terceiros Infraestrutura Infraestrutura Aplicação API de Terceiros
Estudo de Caso do Parsing de Json 3.8 Fronteiras GsonParserGsonParser JacksonParserJacksonParser
Parser Baseado no Gson 3.8 Fronteiras GsonParserGsonParser Encapsula o Gson É um JsonParser
Injetando Dependência 3.8 Fronteiras Criação manual Injeção de dependência Controller Parser Interface toJson() fromJson() GsonParser JacksonParser
Teste de Aprendizado do Gson 3.8 Fronteiras
Parte 3.9Parte 3.9 Testes de UnidadeTestes de Unidade
Filosofia sobre Testes de Unidade 3.9 Testes de Unidade - Teste de unidade dá feedback sobre o design - O feedback deve chegar o quanto antes - TDD é uma boa opção para tornar mais fácil - Testes de unidade são atividade de construção - Cobertura de testes provê confiança - Refatoração sem cobertura pode ser uma aventura - Teste também é código e deve ser limpo
Cenário de Construção com TDD em 3 Iterações 3.9 Testes de Unidade Requisitos do Contador de Constantes 1. Criar uma função que conte todas as constantes inteiras de uma classe passada como parâmetro (atributos estáticos e “final”) 2. Parâmetro “null”, classes abstratas e enuns são ignorados e deve ser retornado “-1” como resultado da função 3. A contagem deve incluir todas as superclasses
As 3 Regras do TDD 3.9 Testes de Unidade Refatora Falha Passa 1. Você não pode escrever nenhum código até ter escrito um teste que detecte uma possível falha. 2. Você não pode escrever mais testes de unidade do que o suficiente para detectar a falha – não compilar é não ter efeito. 3. Você não pode escrever mais código do que o suficiente para passar nos testes.
TDD – Escrever a Primeira Versão do Teste e Falhar 3.9 Testes de Unidade Falha 1. Criar uma função que conte todas as constantes inteiras de uma classe (estáticos e “final”)
TDD – Escrever o Código Real e Passar 3.9 Testes de Unidade Passa
TDD – Refatorar o Código Real e Passar (Apenas Melhoria) 3.9 Testes de Unidade Passa Extração da lista Extração do método
TDD – Refatorar o Teste para o Requisito 2 (Iteração 2) 3.9 Testes de Unidade 2. Classes abstratas e enuns são ignorados (retornar -1), inclusive “null” Refatora
TDD – Teste Refatorado Vai Falhar 3.9 Testes de Unidade Falha Falha Aqui
TDD – Ajuste do Código para Atender o Teste (Iteração 2) 3.9 Testes de Unidade Passa Adição do requisito 2
TDD – Refatorar o Teste para o Requisito 3 (Iteração 3) 3.9 Testes de Unidade 3. A contagem deve incluir as superclasses Refatora
TDD – Teste Refatorado Vai Falhar (Iteração 3) 3.9 Testes de Unidade Falha Tem 2 constantes Falha Aqui
TDD – Ajuste do Código para Atender o Teste (Iteração 3) 3.9 Testes de Unidade Passa Adição do requisito 3
Parte 3.10Parte 3.10 ClassesClasses
Filosofia sobre Classes 3.10 Classes - Classes devem ser pequenas - Devem ter somente uma responsabilidade (SRP) - Ter apenas um motivo para mudar - Devem ter coesão interna - Devem encapsular seus dados ao máximo - Devem ter baixo acoplamento a outras classes
Jogando “Pedra, Papel e Tesoura” 3.10 Classes Requisitos do Melhor de 3 (Pedra, Papel e Tesoura) 1. Criar uma simulação de dois jogadores jogando “pedra, papel e tesoura” por um número variável de rodadas (3, 5 etc). 2. O jogo deve parar se um jogador já for o vencedor antes da última rodada (cenário de vitória antecipada). 3. Ao final deve ser indicado o vencedor (ou empate) e listados os resultados de todas as rodadas.
Código Fornecido 3.10 Classes Enums Hand: Possibilidades de escolha (Pedra, Papel ou Tesoura) MatchResult: Resultados de um match (Primeiro Vence, Empate ou Segundo Vence) Result: Resultado em relação ao primeiro jogador (Perde: -1, Empata: 0 ou Vence: 1). Abstração de rockPaperScissors
Implementação Procedural Simples 3.10 Classes rockPaperScissors(char,char):int Problemas - Um método faz tudo - Muitos conceitos juntos: “Jogador”, “Match”, “Resultados” - “Rodadas” constantes - Nomes “hard coded” - Não pára em vitória antecipada Questões Como se livrar do código legado rockPaperScissors ? A solução é muito procedural? Como testar isso? 2 escolhas aleatórias
Modelo Lógico: Possível Solução OO 3.10 Classes Níveis de Abstração - O Jogo e os resultados - Uma Disputa entre jogadores - O resultado de uma disputa - Jogador com nome e escolha - A opção de jogada
Modelo Lógico: Análise dos Conceitos do Jogo 3.10 Classes Inicialização e Contexto Conceito: 1 JogadorConceito: 1 Disputa Conceito: O Jogo em si Várias rodadas e resultado Código “Legado”: Lógica do jogo Conceito: Resultado de uma Disputa Abstração sobre -1,0,1 Opções do Jogo: R, P e S
Implementação OO 3.10 Classes
Classe BestOfThree 3.10 Classes Responsabilidade: representa um jogo de “Pedra, Papel e Tesoura” com a definição do número de rodadas (3 por padrão) e armazena os resultados (estado) API - Executa o jogo (play) - Retorna se tem vencedor - Retorna o vencedor (se houver) - Retorna os resultados Delega para a classe Match o conhecimento sobre a disputa entre dois jogadores e seu resultado Indireção para Match Requisito número 2
Classe Match 3.10 Classes Representa uma disputa entre dois jogadores e seu resultado (imutável) API: Executa a disputa (play) e gera um resultado Delega para os jogadores a escolha da “mão” que será jogada. Delega para a função rockPaperScissors a lógica de quem venceu a disputa com base nestas escolhas
Classe Player 3.10 Classes Representa um jogador que deve fazer uma escolha de qual mão usar na disputa Delega para Hand a escolha de forma aleatória, mas encapsula esta decisão O jogador poderia ser criado com a escolha já feita anteriormente
Solução OO x Procedural 3.10 Classes A solução OO tem mais código, mas cada parte é mais fácil de entender que o todo Permite testes de unidade por classe Cada abstração está em uma classe Cada classe tem uma responsabilidade A necessidade de manutenção tende a impactar somente uma parte do código
Refatoração: Livrando-se do Código Legado 3.10 Classes Como remover rockPaperScissors? Qual classe deve conhecer esta regra de quem vence quem? Como implementar a regra de forma a gerar o menor impacto possível? Qual seria o impacto de alterar e testar na solução procedural?
Refatoração: Livrando-se do Código Legado 3.10 Classes
Responsabilidade da Classe “Hand” 3.10 Classes Código expressivo sobre a regra do jogo Função (API) que externaliza a regra
Impacto: Nova Classe “Match” 3.10 Classes Função (API) que externaliza a regra Código expressivo sobre a regra do jogo Implementação alternativa (extensão) de “Match” livre do código legado O método “play” expressa o negócio de forma simples e elegante
Impacto da Refatoração 3.10 Classes Criação da classe “SmartMatch” Troca de “Match” por “SmartMatch” Opções: - Injeção de dependência - Segregação de contexto - Implementação funcional
Parte 3.11Parte 3.11 SistemasSistemas
Filosofia sobre Testes de Unidade 3.11 Sistemas Complexos - Sistemas precisam de separação de preocupações - Separe a inicialização do uso de um sistema - Sistemas beneficiam-se do uso de uma DSL
Separação do Preocupações (Modularização) 3.11 Sistemas Complexos - Criação de objetos e escopos superiores - Conexão com BD, I/O e efeitos colaterais Separação de Preocupações do DDD Main main() Negocio Módulo A Domain Service Módulo B Função X1 Classe X Função X2 Função X3 Factory Create Módulo C Função Y1 Classe Y Função Y2 Função Y3 Repository Save
Separe a Construção do Uso no Sistema 3.11 Sistemas Complexos Inicialização e Contexto Conceito: 1 JogadorConceito: 1 Disputa Conceito: O Jogo em si Várias rodadas e resultado Código “Legado”: Lógica do jogo Conceito: Resultado de uma Disputa Abstração sobre -1,0,1 Opções do Jogo: R, P e S As demais classes não devem conhecer sobre contexto e inicialização Devem ser projetadas como se isso fosse ser resolvido para elas… E será! Main conhece o sistema Sistema ignora o Main Função pura ignora tudo fora do seu escopo
Injeção de Dependência Via Construtor 3.11 Sistemas Complexos O uso de CDI com @inject faz o mesmo trabalho automaticamente Injeção de dependência minimiza o acoplamento entre classes além de facilitar os testes de unidade
DSL – Domain Specific Language 3.11 Sistemas Complexos DSL: Código Expressivo Feature Envy DSL encapsula a lógica Main main() Negocio Módulo A Domain Service Módulo B Função X1 Classe X Função X2 Função X3 Factory Create Módulo C Função Y1 Classe Y Função Y2 Função Y3 Repository Save Classes e Funções são negócio destilado O domínio do problema é descrito na solução
Parte 3.12Parte 3.12 SimplicidadeSimplicidade
Filosofia sobre Simplicidade 3.12 Simplicidade - Todos os testes devem passar (deve haver testes) - Nenhuma duplicação de código ou configuração - O código deve expressar o negócio e sua intenção - A solução deve usar o mínimo de elementos - Simples não é Simplório (pelo contrário) - Simplicidade é a sofisticação máxima
As 4 Regras da Simplicidade 3.12 Simplicidade Testes Tempestivos Refatoração Tempestiva https://martinfowler.com/bliki/BeckDesignRules.html
Regra 1 de Projeto Simples: Efetue Todos os Testes 3.12 Simplicidade 1 2 3 Teste 1: Afere se a regra entre as opções está funcionando: Pedra vence Tesoura, Tesoura vence Papel e Papel vence Pedra Teste 2: Afere se o SmartMatch retorna o resultado certo dado que já se sabe o que os jogadores vão escolher (mock) Teste 3: Afere que, de 7 rodadas, irá parar na quarta com 4 vitórias de “Bob”
Regras de 2 a 4 de Projeto Simples: Refatoração 3.12 Simplicidade Conceitos - O Jogo e os resultados - Uma Disputa entre jogadores - O resultado de uma disputa - Jogador com nome e escolha - A opção de jogada DSL: Código Expressivo A: Reúso B: Refactoring Regra 1 conceito p/ classe
já sei clean code? técnicatécnica, treino e tempo, treino e tempo abordagem de atuação profissional não é sobre códigonão é sobre código é sobreé sobre fazer códigofazer código
RefatoraçãoRefatoração Parte 4
Laboratório de Refatoração 4 Refatoração treinotreino github.com/refactown/lab
REFERÊNCIAS BECK, Kent. Padrões de Implementação. Porto Alegre, Bookman, 2013. EVANS, E. Domain-Driven Design – Atacando as complexidades no coração do software. 2a edição, Rio de Janeiro, Alta Books, 2010. FOWLER, Martin. BeckDesignRules, https://martinfowler.com/bliki/BeckDesignRules.html FOWLER, Martin. TellDontAsk, https://martinfowler.com/bliki/TellDontAsk.html HUNT, Andrew; THOMAS, David, O Programador Pragmático, Bookman, 2010 MARTIN, Robert, O Codificador Limpo, Alta Books, Rio de Janeiro 2012 MARTIN, Robert, Código Limpo, Alta Books, Rio de Janeiro 2011
Programação Funcional X Orientação a Objetos 145/145 1 42 3 5 Prática para encerrar... Obrigado! Douglas Siviotti douglas.siviotti@gmail.com github.com/siviotti Teoria

Mais conteúdo relacionado

PDF
Paradigmas de programação
porSérgio Souza Costa
 
PPTX
Apresentação Clean Code
porAndré Leoni
 
PPTX
Boas práticas técnica para um código limpo (Clean Code)
porRodrigo Kono
 
PDF
clean code
porDouglas Siviotti
 
PPTX
Arquitetura de Software EXPLICADA
porFábio Nogueira de Lucena
 
PPTX
Princípios SOLID
porEdmilson Filho
 
PDF
Modelos de processos de software
porNécio de Lima Veras
 
PPTX
SOLID - Teoria e Prática
porEduardo Pires
 
Paradigmas de programação
porSérgio Souza Costa
 
Apresentação Clean Code
porAndré Leoni
 
Boas práticas técnica para um código limpo (Clean Code)
porRodrigo Kono
 
clean code
porDouglas Siviotti
 
Arquitetura de Software EXPLICADA
porFábio Nogueira de Lucena
 
Princípios SOLID
porEdmilson Filho
 
Modelos de processos de software
porNécio de Lima Veras
 
SOLID - Teoria e Prática
porEduardo Pires
 

Mais procurados

PPTX
TDD - Test Driven Development
porElias Nogueira
 
PDF
Aula 1 requisitos
porlicardino
 
PDF
Scrum
porElaine Cecília Gatto
 
PPTX
1 requisitos funcionais e não funcionais ok
porMarcos Morais de Sousa
 
PDF
02 - Orientação a objetos e revisão de C# v1.5
porCésar Augusto Pessôa
 
PDF
Mapa Mental Scrum
porRildo (@rildosan) Santos
 
PDF
طرح درس روزانه بسته 3جلد2
porpem515
 
PDF
Node.js - #1 - Introdução - Rodrigo Branas
porRodrigo Branas
 
PPTX
Métodos Ágeis e Scrum - Introdução
porYuri Morais
 
PPTX
Linguagem Assembly
porSuzana Viana Mota
 
PPTX
SOLID
porMarco Oliveira
 
PDF
Minicurso Python
porguestac3de
 
PDF
Programação Orientada a objetos em Java
porDenis L Presciliano
 
PDF
Curso de Node JS Básico
porVictor Hazin da Rocha
 
PDF
Paradigmas de Programação - Imperativo, Orientado a Objetos e Funcional
porGustavo Coutinho
 
PDF
POO - 13 - Arrays em Java
porLudimila Monjardim Casagrande
 
PDF
ICC - Aula 04 - Expressões literais, comando de atribuição e de entrada/saída
porFelipe J. R. Vieira
 
PDF
07 diagrama de classes de análise
porFilipe Soares
 
PPTX
JAVA - Orientação a Objetos
porElaine Cecília Gatto
 
PPTX
Java: Heranca e polimorfismo
porArthur Emanuel
 
TDD - Test Driven Development
porElias Nogueira
 
Aula 1 requisitos
porlicardino
 
Scrum
porElaine Cecília Gatto
 
1 requisitos funcionais e não funcionais ok
porMarcos Morais de Sousa
 
02 - Orientação a objetos e revisão de C# v1.5
porCésar Augusto Pessôa
 
Mapa Mental Scrum
porRildo (@rildosan) Santos
 
طرح درس روزانه بسته 3جلد2
porpem515
 
Node.js - #1 - Introdução - Rodrigo Branas
porRodrigo Branas
 
Métodos Ágeis e Scrum - Introdução
porYuri Morais
 
Linguagem Assembly
porSuzana Viana Mota
 
SOLID
porMarco Oliveira
 
Minicurso Python
porguestac3de
 
Programação Orientada a objetos em Java
porDenis L Presciliano
 
Curso de Node JS Básico
porVictor Hazin da Rocha
 
Paradigmas de Programação - Imperativo, Orientado a Objetos e Funcional
porGustavo Coutinho
 
POO - 13 - Arrays em Java
porLudimila Monjardim Casagrande
 
ICC - Aula 04 - Expressões literais, comando de atribuição e de entrada/saída
porFelipe J. R. Vieira
 
07 diagrama de classes de análise
porFilipe Soares
 
JAVA - Orientação a Objetos
porElaine Cecília Gatto
 
Java: Heranca e polimorfismo
porArthur Emanuel
 

Semelhante a Clean Code na Prática

PDF
Codigo limpo
pordiegomcunha
 
PPTX
Clean Coder
porCamilo de Melo
 
PDF
Análise de sistemas oo 1
porMaurício Linhares
 
PDF
A Arte do Código Limpo
porJuliana Fideles
 
PDF
Qualidade de código
porKete Martins Rufino
 
PPTX
Clean Code: Por um mundo com códigos melhores - The Developers Conference - P...
porThiago Barradas
 
PDF
Clean Code
porDaniel Tamiosso
 
PPTX
Clean Code - Boas práticas para desenvolvimento
porPaulo Henrique da Silva
 
PPTX
Clean Code: Por um mundo com códigos melhores - SETI 2017
porThiago Barradas
 
PPTX
Clean code em C#
porGustavo Araújo
 
PPT
Apresentacao tdc 2012
porJorge Oleques
 
PPT
Scrum e o Ambiente de Desenvolvimento Ágil
porabacrazy
 
PPTX
DevTalk Zoox 04/2016
porLeandro Silva
 
PPTX
Introdução ao TDD
porgustavoferrazfontes
 
PDF
Código limpo: Boas práticas e sua importância no desenvolvimento de software.
porPedro Edson Silva Barros
 
PPTX
Codigo limpo.pptx
porRennan Cardoso Guarani Kaiowá
 
PDF
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
porJoberto Diniz
 
PPTX
Clean Code e Object Calisthenics - Aplicados no PHP
porRafael Neris
 
PPTX
Aprensentacao oo-trincheiras
porHigor César
 
PDF
Clean code, o que é e como aplicar?
porRodrigoMartins358
 
Codigo limpo
pordiegomcunha
 
Clean Coder
porCamilo de Melo
 
Análise de sistemas oo 1
porMaurício Linhares
 
A Arte do Código Limpo
porJuliana Fideles
 
Qualidade de código
porKete Martins Rufino
 
Clean Code: Por um mundo com códigos melhores - The Developers Conference - P...
porThiago Barradas
 
Clean Code
porDaniel Tamiosso
 
Clean Code - Boas práticas para desenvolvimento
porPaulo Henrique da Silva
 
Clean Code: Por um mundo com códigos melhores - SETI 2017
porThiago Barradas
 
Clean code em C#
porGustavo Araújo
 
Apresentacao tdc 2012
porJorge Oleques
 
Scrum e o Ambiente de Desenvolvimento Ágil
porabacrazy
 
DevTalk Zoox 04/2016
porLeandro Silva
 
Introdução ao TDD
porgustavoferrazfontes
 
Código limpo: Boas práticas e sua importância no desenvolvimento de software.
porPedro Edson Silva Barros
 
Codigo limpo.pptx
porRennan Cardoso Guarani Kaiowá
 
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
porJoberto Diniz
 
Clean Code e Object Calisthenics - Aplicados no PHP
porRafael Neris
 
Aprensentacao oo-trincheiras
porHigor César
 
Clean code, o que é e como aplicar?
porRodrigoMartins358
 

Mais de Douglas Siviotti

PDF
Dev In The Loop - Quando e Como o Desenvolvedor Atua no Ciclo de Desenvolvime...
porDouglas Siviotti
 
PDF
workshop-dev-in-the-loop-tdc-brasilia-26-11-2025.pdf
porDouglas Siviotti
 
PDF
Dev In The Loop: Quando e como o desenvolvedor (Dev) atua no ciclo de desenvo...
porDouglas Siviotti
 
PDF
tdc-2023-bh-ciclomatica-ou-cognitiva.pdf
porDouglas Siviotti
 
PDF
tdc-2022-poa-quem-tem-medo-low-code.pdf
porDouglas Siviotti
 
PDF
tdc-2022-poa-lgpd-metaverso.pdf
porDouglas Siviotti
 
PDF
TDC Future 2021 - Privacy After Design
porDouglas Siviotti
 
PDF
TDC Connections 2021 Clausula de Guarda
porDouglas Siviotti
 
PDF
TDC Connections 2021 Artigo 37 da LGPD
porDouglas Siviotti
 
PDF
Como o SERPRO Atende os Direitos dos Titulares
porDouglas Siviotti
 
PDF
Tdc 2021-innovation-lgpd-dados-pessoais
porDouglas Siviotti
 
PDF
Artesoftware Explicando LGPD
porDouglas Siviotti
 
PDF
tdc-2020-poa-pedra-tesoura-papel
porDouglas Siviotti
 
PDF
Tdc 2020-poa-data-protection-full-stack
porDouglas Siviotti
 
PDF
tdc-recife-2020-complexidade-cognitiva
porDouglas Siviotti
 
PDF
tdc-recife-2020-lgpd-para-desenvolvedores
porDouglas Siviotti
 
PDF
Privacidade By Design no Ciclo de Vida do Produto
porDouglas Siviotti
 
PDF
Privacidade By Design
porDouglas Siviotti
 
PDF
LGPD Lei Geral de Proteção de Dados Pessoais
porDouglas Siviotti
 
PDF
Complexidade Cognitiva
porDouglas Siviotti
 
Dev In The Loop - Quando e Como o Desenvolvedor Atua no Ciclo de Desenvolvime...
porDouglas Siviotti
 
workshop-dev-in-the-loop-tdc-brasilia-26-11-2025.pdf
porDouglas Siviotti
 
Dev In The Loop: Quando e como o desenvolvedor (Dev) atua no ciclo de desenvo...
porDouglas Siviotti
 
tdc-2023-bh-ciclomatica-ou-cognitiva.pdf
porDouglas Siviotti
 
tdc-2022-poa-quem-tem-medo-low-code.pdf
porDouglas Siviotti
 
tdc-2022-poa-lgpd-metaverso.pdf
porDouglas Siviotti
 
TDC Future 2021 - Privacy After Design
porDouglas Siviotti
 
TDC Connections 2021 Clausula de Guarda
porDouglas Siviotti
 
TDC Connections 2021 Artigo 37 da LGPD
porDouglas Siviotti
 
Como o SERPRO Atende os Direitos dos Titulares
porDouglas Siviotti
 
Tdc 2021-innovation-lgpd-dados-pessoais
porDouglas Siviotti
 
Artesoftware Explicando LGPD
porDouglas Siviotti
 
tdc-2020-poa-pedra-tesoura-papel
porDouglas Siviotti
 
Tdc 2020-poa-data-protection-full-stack
porDouglas Siviotti
 
tdc-recife-2020-complexidade-cognitiva
porDouglas Siviotti
 
tdc-recife-2020-lgpd-para-desenvolvedores
porDouglas Siviotti
 
Privacidade By Design no Ciclo de Vida do Produto
porDouglas Siviotti
 
Privacidade By Design
porDouglas Siviotti
 
LGPD Lei Geral de Proteção de Dados Pessoais
porDouglas Siviotti
 
Complexidade Cognitiva
porDouglas Siviotti
 

Clean Code na Prática

  • 1.
    Clean Code naPrática Conceitos de Clean Code Apresentados em Exemplos de Código Douglas Siviotti Maio de 2019 V1.0
  • 2.
    Sobre esta Apresentação 1.Conteúdo: Clean Code (Código Limpo) 2. Área/Foco: Engenharia de Software, Desenvolvimento Ágil 3. Público alvo: Desenvolvedores (nível intermediário de experiência em OO) 4. Conteúdo relacionado: OO, Programação Funcional, DDD, SOLID, GRASP Organização Parte 1 – Um Pouco de Filosofia Parte 2 – Um Pouco de Teoria Parte 3 – Clean Code na Prática em Exemplos de Código Parte 4 – Laboratório de Refatoração Material de apoio desta apresentação: https://github.com/refactown/cleancode
  • 3.
    Sintomas comuns equipe entregando cadavez menos pontos a cada sprint estimativas frustradas: o esforço é sempre maior que o previsto erros frequentes em produção correção de um bug causa outros problemas não previstos incidentes resolvidos e o mesmo erro voltando a aparecer muito “To Do” espalhado pelo código e/ou código morto dificuldade de evolução ou incorporação de novas funcionalidades
  • 4.
    Código Ruim manutenção difícil +retrabalho e - produtividade Código Ruim manutenção difícil + retrabalho e - produtividade Procrastinação aversão a mudanças criação de dívida técnica Procrastinação aversão a mudanças criação de dívida técnica Falta de Testes design pobre e inflexível falta de segurança p/ o dev Falta de Testes design pobre e inflexível falta de segurança p/ o dev Pressão bugs, incidentes, pouco valor, baixa evolução: insatisfação Pressão bugs, incidentes, pouco valor, baixa evolução: insatisfação ciclo vicioso da dívida técnica
  • 5.
    Código Limpo fácil deentender e manter expressa o negócio Código Limpo fácil de entender e manter expressa o negócio Refatoração adaptação ao novo problema tratamento de dívida técnica Refatoração adaptação ao novo problema tratamento de dívida técnica Teste de Unidade guiando o design (feedback) com boa cobertura Teste de Unidade guiando o design (feedback) com boa cobertura Entregas c/ Valor evolução sustentável cliente satisfeito Entregas c/ Valor evolução sustentável cliente satisfeito ciclo da eficácia no software sob medida
  • 6.
    Clean Code fácil deentender e manter expressa o negócio Clean Code fácil de entender e manter expressa o negócio Refatoração adaptação ao novo problema tratamento de dívida técnica Teste de Unidade guiando o design (feedback) com boa cobertura Entregas c/ Valor evolução sustentável cliente satisfeito ciclo da eficácia no software sob medida
  • 7.
    Um PoucoUm Pouco deFilosofiade Filosofia Parte 1
  • 8.
    Pequenas CoisasPequenas Coisas ImportamImportam “Deusestá nos detalhes” “Menos é mais” (Ludwig Mies van der Rohe) Quem não faz bem as pequenas coisas, não faz bem coisa alguma
  • 9.
    código é detalhamentocódigoé detalhamento dos requisitos e devedos requisitos e deve expressar o negócioexpressar o negócio
  • 10.
    código deve serfeito para ser lido por outra pessoacódigo deve ser feito para ser lido por outra pessoa comunique, não codifique!
  • 11.
    código ruim geracódigoruim gera baixa produtividadebaixa produtividade que gera código piorque gera código pior seja um glóbulo branco prevenir é melhor que remediar por que
  • 12.
    CódigoCódigo Limpo?Limpo? “elegante e eficiente fazapenas uma coisa” Bjarne Stroustrup “simples e direto - legível” Grady Booch “inteligível ao seres humanos” Dave Thomas “escrito por alguém que se importava” Michael Feathers “sem duplicação, expressivo, pequenas abstrações” Ron Jeffries “a linguagem parece que foi feita para o problema” Ward Cunningham O que é
  • 13.
    A T IT U D EA T I T U D E teoria da janela quebrada regra do escoteiro quando programador profissional quem quando
  • 14.
    técnica, treino etempotécnica, treino e tempo livros de arte não fazem um artista trabalho artesanal mas profissional como
  • 15.
    Um Pouco deTeoria*Um Pouco de Teoria* *Oriunda de muita prática*Oriunda de muita prática Parte 2
  • 16.
    Título do Slide(Arial 18) 16/145 2.1 DDD: Negócio ao Código 2.2 Linguagem Onipresente 2.3 Princípio SRP 2.4 Princípio DRY 2.5 Indireção / Delegação 2.6 Lei de Demeter 2.7 Acoplamento e Coesão 2.8 Imutabilidade 2.9 OO + Funções Puras 2.10 Testes Tempestivos 2.11 Refatoração Tempestiva 2.12 Regras da Simplicidade Conceitos relacionados
  • 17.
    O requisito estáno código, mas muito código não vem do requisito O domínio de um problema organiza os conceitos sobre os quais é baseada a solução de software Foco no Negócio Parte do código deve expressar o negócio Isolamento do Domínio O código de domínio é idiossincrático e particular Infraestrutura à Parte Tecnologias vêm e vão, o negócio permanece Do Negócio ao Código Via DDD 2.1 Negócio ao Código Domain
  • 18.
    DDD e osNomes das Coisas 2.2 Linguagem Onipresente Ubiquos Language Service Entity Value Object Agregate Factory Model-driven Design Bounded Context RepositoryDomain Events Layered Architecture Core Domain Context Map Continuos Integration Linguagem Onipresente (Ubíqua) - Termos e conceitos usados pelos desenvolvedores e pelos especialistas no negócio - Presente na fala de todos e no código de domínio Contexto Delimitado - Partes bem delimitadas de um domínio - Candidatos a microsserviços Tijolos de Construção - Entidades, Objetos de Valor, Agregados - Eventos de Domínio - Serviços, Fábricas, Repositórios
  • 19.
    Princípio da ResponsabilidadeÚnica (SRP) 2.3 Princípio SRP “Cada módulo de um software deve ter um e apenas um motivo para mudar” 1 O que seria apenas “uma” responsabilidade?
  • 20.
    Menos é Mais2.4 Princípio DRY DRY = Don’t Repeat Yourself “Não Se Repita” (código, requisito, teste etc) Toda parte do conhecimento deve ter uma representação única e livre de ambiguidades em todo o sistema Problemas - Mais trabalho: alterar mais vezes - Mais risco: encontrar todos os lugares - Mais teste: testar várias vezes a mesma coisa - Mais esforço de comunicação
  • 21.
    Indireção ou Delegação2.5 Indireção / Delegação SRP Fazer apenas uma coisa em um certo lugar SRP Fazer apenas uma coisa em um certo lugar DRY Fazer apenas em um lugar uma certa coisa DRY Fazer apenas em um lugar uma certa coisa Coisa única em um único lugar “A” Coisa única em um único lugar “A” Outra coisa única em um único lugar “B” Outra coisa única em um único lugar “B” Indireção ou Delegação 1. Não pode conter 2. Não pode copiar 3. Precisa referenciar Indireção Indireção Calculo de Frete Busca de EndereçoEfetuar Pedido
  • 22.
    Lei de Demeter– Princípio do Menor Conhecimento 2.6 Lei de Demeter Um módulo não deve enxergar o interior dos objetos que ele manipula Um método “f” de uma classe “C” só deve chamar: - “C” - Um objeto criado por “f” - Um objeto passado por parâmetro para “f” (e.g. “p”) - Um objeto dentro de uma variável de instância de “C” Train Wreck (Acidente de Trem): p.getY().getZ() Classe “C” Atributo A: A Método “f” (p: X) Classe X Atributo Y : Y Classe Y Atributo Z : Z
  • 23.
    Baixo Acoplamento eAlta Coesão 2.7 Acoplamento e Coesão Alto Acoplamento Baixa Coesão (entre classes) Poucas classes e grandes Mais dependência por classe Maior conhecimento Baixo Acoplamento Alta Coesão (entre classes) Muitas classes e pequenas Menos dependência por classe Menor conhecimento Coesão de uma Classe: - Poucas variáveis de instância - Cada método manipula uma ou mais Uma classe pouco coesa sugere que uma nova classe deve “nascer”
  • 24.
    Quanto Mais ImutávelMelhor 2.8 Imutabilidade Evite Surpresas Imutabilidade é uma defesa contra efeitos colaterais Vantagens - Mais seguro e confiável - Mais legível: minimiza testes e garantias diminui o código por tabela - Paralelismo e escalabilidade private final int idade;
  • 25.
    Quanto Mais PuroMelhor 2.9 OO + Funções Puras Função Pura 1. Para um certo Input sempre retorna o mesmo Output 2. Não causa nenhum efeito colateral 3. Não depende de nenhum dado externo (autocontida) Vantagens - Mais simples e menores - Mais fácil de entender e testar Quando usar em código OO? Sempre que possível Em muitas situações não é possível: BD, integração, estados etc Possível em regras de negócio, métodos utilitários, internos etc Function Input Output IMUTABILIDADE - efeitos colaterais
  • 26.
    TDD e TestesTempestivos 2.10 Testes Tempestivos TDD – Test Driven Development (Desenvolvimento Guiado por Testes) - Escreve um teste que falha antes do código produtivo - Faz o teste passar ao construir o código produtivo - Refatora o código até o teste falhar (ou não) Testes Tempestivos (TDD inclusive) (teste que ajuda na construção, logo cedo) 1. Atividade de engenharia (código e design) 2. Feedback rápido sobre o código testado (erra cedo) 3. Gera código limpo através da “dificuldade” de testar 4. Antecipa o custo gasto em correções e debug 5. Ainda serve como teste de regressão Refatora Falha Passa Ciclos Curtos
  • 27.
    Refatoração Tempestiva 2.11Refatoração “Refatoração (refactoring) é a disciplina técnica para reestruturar um determinado código, alterando sua estrutura interna sem mudar seu comportamento externo” Martin Fowler Problema Inicial Solução Inicial Problema Refinado Refatoração Mudança Solução Final Validar Solução Refinamento Ciclo de Sprint Ajuste da solução em função de: - uma nova visão sobre o problema - preparar para uma evolução ou mudança Pequenas mudanças que fazem diferença no longo prazo
  • 28.
    Quatro Regras daSimplicidade (Martin Fowler : Kent Beck) 2.12 Simplicidade Testes Tempestivos Refatoração Tempestiva https://martinfowler.com/bliki/BeckDesignRules.html
  • 29.
    Conceitos Relacionados Conceitos DDDDDDLinguagem Onipresente Linguagem Onipresente Indireção Abstração, especialização Indireção Abstração, especialização Lei de Demeter Mínimo conhecimento Lei de Demeter Mínimo conhecimento Princípio SRP Responsabilidade Única Princípio SRP Responsabilidade Única Princípio DRY Não Se Repita Princípio DRY Não Se Repita Acoplamento e Coesão Acoplamento e Coesão Funções Puras OO ou funcional Funções Puras OO ou funcionalInfraInfra DomínioDomínio AppApp Refatoração Tempestiva Refatoração Tempestiva Teste Tempestivo Teste Tempestivo 4 Regras da Simplicidade 4 Regras da Simplicidade Imutabilidade - efeitos colaterais Imutabilidade - efeitos colaterais Clean Code Clean Code
  • 30.
  • 31.
    Título do Slide(Arial 18) 31/145 3.1 Código Limpo 3.2 Nomes Significativos 3.3 Funções* 3.4 Comentários 3.5 Formatação 3.6 Objetos e E. de Dados 3.7 Tratamento de Erro 3.8 Fronteiras (Limites) 3.9 Testes de Unidade 3.10 Classes 3.11 Sistemas Complexos 3.12 Simplicidade Prática - filosofia - bad smell - boa prática - exemplo - exercício Cognição Entendimento e leitura Integração Contratos e expectativas Design Escala e expansão
  • 32.
  • 33.
    Filosofia sobre CódigoLimpo 3.1 Código Limpo - O código não fica nem se mantém limpo sozinho - Todos na equipe devem praticar e cobrar - Manter o código limpo é uma atividade diária - Funciona como na “Teoria das janelas quebradas” - Atitude é mais relevante do que “patrocínio” - Sempre dá pra começar (regra do escoteiro) - Ler e entender consome mais tempo que escrever - Precisa de tempo, técnica e treino pra fazer bem
  • 34.
    Código Ruim 3.1Código Limpo Problemas - Nomes ruins - Função grande e complexa (SRP) - Comentários questionáveis - Formatação inexistente Dificuldades - Legibilidade: confuso - Testabilidade: alta complexidade
  • 35.
    Código Menos Ruim3.1 Código Limpo Problemas - Nomes ruins - Função grande e complexa (SRP) - Comentários questionáveis - Formatação inexistente Dificuldades - Legibilidade: confuso - Testabilidade: alta complexidade
  • 36.
    Código Melhorado 3.1Código Limpo O que aina pode ser melhorado?
  • 37.
  • 38.
  • 39.
    Filosofia sobre Nomes3.2 Nomes Significativos - Nomes são muito importante (especialmente em OO) - Use nomes que revelam seu propósito - Evite informações erradas (itemList: Map) - Faça distinções significativas (evite a1, a2 a3...) - Nomes pronunciáveis e passíveis de busca - Evite codificações (e.g. notação húngara e similares) - classes = substantivos, métodos = verbos - Selecione uma palavra por conceito (get, set, find) - Nomes do problema (Pedido, Item) e da solução (DAO) - Adicione ou evite contexto quando necessário
  • 40.
    Bad Smell 3.2Nomes Significativos Problemas - Nomes genéricos “i”, “x”, “d” etc - Nomes impronunciáveis - Número Mágico (perdido no código) - Notação Húngara - Interface prefixada - Nome com contexto redundante
  • 41.
    Boa Prática 3.2Nomes Significativos Alternativas - Nomes que revelam propósito - Nomes pronunciáveis - Constantes para número mágico (passíveis de busca) - Sem Notação Húngara - Interface = Conceito - Nomes com o mínimo necessário
  • 42.
    Problema x Solução3.2 Nomes Significativos Problema Solução
  • 43.
    Modelo de Exemplo3.2 Nomes Significativos Nomes a partir do domínio do problema (Pedido, Item etc) Nomes a partir do domínio da solução (Controller, Delegate, DAO) Classes = Substantivos, Métodos = Verbos Nomes pronunciáveis e passíveis de busca
  • 44.
  • 45.
    Filosofia sobre Funções3.3 Funções - Funções devem ser pequenas (<= 20 linhas) - Funções devem fazer apenas uma coisa - Devem ter nomes descritivos do que fazem - Somente um nível de abstração por função - Funções devem ter poucos parâmetros - Efeitos colaterais devem ser evitados ao máximo - Quanto mais funções puras, melhor - Quanto mais autocontida mais fácil de testar
  • 46.
    Clean Code (2008) Programação Funcional (1958) Pura Sem efeitos colaterais 1nível de abstração Faz apenas 1 coisa Pequena Clean Code + Programação Funcional 3.3 Funções
  • 47.
    Regra 1 3.3Funções Faz Apenas 1 Coisa - Nomes, comentários e formatação são importantes para a leitura, mas as funções são o que o programa realmente faz - É melhor ler e entender uma coisa de cada vez - É melhor testar uma coisa de cada vez 1 Nível de Abstração - Cada conceito em seu lugar apropriado Abstração é a capacidade de separar o essencial do que não é essencial. Separar conceitos dos detalhes.
  • 48.
    Exemplo de Função“Suja” 3.3 Funções Grande (30 linhas) Faz muitas coisas: 1. Decide qual classe deve ser avaliada 2. Lista os campos de uma classe e superclasses 3. Lista os “tipos inteiros” 4. Infere se é constante 5. Faz a contagem Níveis de abstração 1 2 3 4 5
  • 49.
    Exemplo de Função“Limpa” 3.3 Funções Pequena (11 linhas) Faz 1 coisa: 1. Decide qual classe deve ser avaliada 2. Lista os campos de uma classe e superclasses 3. Lista os “tipos inteiros” 4. Infere se é constante 5. Faz a contagem 1 nível de abstração 1 coisa e 1 nível de abstração Indireção
  • 50.
    Regra Decrescente 3.3Funções Indireção Nível de abstração 1 Nível de abstração 2 Leitura de cima para baixo Nomes descritivos do que fazem
  • 51.
    Switch Highlander 3.3Funções Um “Switch” deve estar em uma classe de nível mais baixo de abstração e nunca ser repetido Opção procedural Opção polimórfica
  • 52.
    Fibonacci (Funções Puras)3.3 Funções 1. Para um certo Input sempre retorna o mesmo Output 2. Não causa nenhum efeito colateral 3. Não depende de nenhum dado externo (escopo)
  • 53.
    Pedra, Papel eTesoura 3.3 Funções Cabeçalho da Função: rockPaperScissors(char,char):int Contrato da Função: - Recebe dois caracteres (R, P ou S) - Se empata retorna 0 - Se o primeiro ganha retorna -1 - Se o segundo ganha retorna 1 - Se um dos caracteres é inválido gera uma exceção “IllegalArgumentException” (melhor que código de erro) - R vence S, S vence P, P vence R
  • 54.
    Pedra, Papel eTesoura 3.3 Funções √ 1 Nível de abstração É uma função pura? √ Faz apenas 1 coisa Prefira exceções a retorno de códigos de erro!
  • 55.
    Parâmetros 3.3 Funções FunçãoMônade P1 Função Díade Função Tríade P1 P2 P3 P1 P2 A quantidade de parâmetros deve ser a menor possível. Se a quantidade de parâmetros é muito grande, pode ser usado um objeto como parâmetro. Objeto como Parâmetro O parâmetro tem suas regras e seus próprios conceitos
  • 56.
    Parâmetros Seletores ede “Saída” 3.3 Funções Parâmetro de “Saída” Saída deve ser no retorno Parâmetro Seletor É preferível dividir em duas funções Um parâmetro seletor já indica logo na assinatura que uma função faz duas coisas. O ideal é fazer duas funções separadas.
  • 57.
    Separação Comando-Consulta 3.3Funções Comando + Consulta Apenas Consulta Apenas Comando As funções devem somente fazer ou responder algo, mas não ambos. Ou altera o estado de um objeto ou retorna informação sobre ele.
  • 58.
    Tratamento de Erroé 1 Coisa Só 3.3 Funções O “try” deve ser a primeira linha da função e não deve haver nada depois fim do bloco “try/catch/finally”
  • 59.
    O Cerne deBoas Funções 3.3 Funções Evite Repetição (DRY) - Indireção, extração etc podem gerar duplicação - Funções menores e especializadas requerem reúso (SRP) Faça e Refaça com Confiança - Comece fazendo funcionar e depois refatore - Tenha cobertura de testes para ter confiança Funções são verbos do domínio - Uma hierarquia de funções conta uma estória - Níveis de abstração ajudam na leitura da estória
  • 60.
  • 61.
    Filosofia sobre Comentários3.4 Comentários “Qualquer um pode escrever código que o computador entenda. Bons programadores escrevem códigos que os humanos entendem.” Martin Fowler - Comentários são a última opção do programador - O programador deve expressar-se no código - Comunique, não codifique (outros devem ler) - Comentário pode estar compensando código ruim - Alguns comentários são bons ou necessários
  • 62.
    Explique-se no Código3.4 Comentários Alguns comentários existem para explicar código ruim. Um comentário deve explicar “o porquê” e nunca “o que” Não comente, refatore!
  • 63.
    Comentários Bons: Legaise APIs Públicas 3.4 Comentários
  • 64.
    Comentários Bons: Alguns“TODO”, Alertas e Destaques 3.4 Comentários
  • 65.
    Comentário Ruim: Murmúrioe Redundância 3.4 Comentários
  • 66.
    Comentário Ruim: CódigoMorto e/ou com Autoria 3.4 Comentários Use o controle de versão!
  • 67.
    Outros Comentários Ruins3.4 Comentários - Ruidosos, muito longos ou repetitivos - Imperativos (e.g. em todas as funções) - Marcadores de Posição //////////////// ou ************ - Ao lado de chaves de fechamento (e.g. //for) - Comentários em HTML - Informações excessivas - Conexões nada óbvias - Cabeçalhos de funções (prefira um bom nome) - Javadoc em código não público
  • 68.
  • 69.
    Filosofia sobre Formatação3.5 Formatação - Atenção ao “code convention” da linguagem - O projeto deve ter um “code style” (bom ou ruim) - Qualquer “code style” é melhor que nenhum - A formatação automática evita muitas brigas - Formatação vertical Metáfora do jornal, distância vertical, espaçamento e continuidade vertical - Formatação horizontal Indentação, espaçamento e continuidade horizontal
  • 70.
    Formatação Vertical: Metáforado Jornal 3.5 Formatação
  • 71.
    Formatação Vertical: Continuidadee Espaçamento Vertical 3.5 Formatação Linhas de código relacionadas devem permanecer unidas Pensamentos completos devem ser separados por espaços em branco
  • 72.
    Formatação Vertical: DistânciaVertical 3.5 Formatação Declaração de Variável O mais próximo possível de onde será usada Variáveis de Instância Antes dos métodos Funções Dependentes Verticalmente próximas Afinidade Conceitual Mesma convenção de nomes atuam na mesma tarefa devem ficar próximas
  • 73.
    Formatação Horizontal 3.5Formatação Evite - Espaçamentos manuais - Indentação do “seu gosto” - Mais de 120 caracteres por linha Deixe a IDE trabalhar - Espaçamentos automáticos - Indentação padrão - Quebras de linha
  • 74.
    Regra da Tela3.5 Formatação <= 20 Cabe na tela <= 500 100-120 Cabe na tela
  • 75.
    Code Convention +Regra da Equipe 3.5 Formatação Mantenha a paz no seu projeto: tenha um “code style” combinado pela equipe
  • 76.
    Objetos e EstruturasObjetose Estruturas de Dadosde Dados Parte 3.6Parte 3.6
  • 77.
    Filosofia sobre Objetose Estruturas de Dados 3.6 Objetos e E. de Dados Os objetos usam abstrações para esconder seus dados e expõem funções que operam sobre eles Estruturas de dados expõem seus dados e não possuem funções significativas (get/set = acessores) - Objetos buscam o menor conhecimento - Estruturas de dados (DTO) buscam imutabilidade
  • 78.
    Estruturas de Dadosnas Linguagens 3.6 Objetos e E. de Dados Kotlin tem uma palavra reservada para definir uma estrutura de dados: “data”. A sintaxe deixa clara a diferença entre uma estrutura de dados e demais classes/objetos
  • 79.
    Procedural x Orientadoa Objetos (OO) 3.6 Objetos e E. de Dados E se precisar calcular o perímetro? (as estruturas de dados não serão afetadas) E se precisar criar a classe triângulo?
  • 80.
    Espectros de Objetos/ Estrutura de Dados 3.6 Objetos e E. de Dados Encapsulamento Estrutura de Dados ObjetosHíbridos Imutabilidade Facilita a adição de novas funcionalidades Facilita a adição de novas classes Triângulo Perímetro
  • 81.
    Feature Envy (Invejade Funcionalidade) 3.6 Objetos e E. de Dados https://martinfowler.com/bliki/TellDontAsk.html Uma parte do código tem “inveja” da funcionalidade de outra parte No exemplo abaixo, “isValidOrder” tem inveja da funcionalidade que diz se um pedido é válido Princípio “Tell Don’t Ask” Indireção
  • 82.
    Feature Envy noModelo de Figuras (Shape) 3.6 Objetos e E. de Dados
  • 83.
    Feature Envy +Efeitos Colaterais 3.6 Objetos e E. de Dados
  • 84.
    Lei de Demeter3.6 Objetos e E. de Dados x = a.getB().getC().getD()x = a.b.c.d Train Wrecks (Acidente de Trem) a b c d NullPointer Exception (null) Estrutura de Dados Objetos - Imutabilidade - Proibição de “null” - Estados mutáveis - Possibilidade de “null” x = a?.b?.c?.d (Navegação Segura)
  • 85.
    Parte 3.7Parte 3.7 Tratamentode ErroTratamento de Erro
  • 86.
    Filosofia sobre Tratamentode Erro 3.7 Tratamento de Erros - Use exceções em vez de retornar códigos - Prefira exceções não verificadas (unchecked) - Forneça exceções com contexto e sem abafamento - Pense no design do “try-catch-finally” antes - Defina exceções pensando no chamador (e.g. Libs) - Cada “catch” faz apenas uma coisa - Não retorne nem passe “null” - Dê preferência às exceções já fornecidas (efective java)
  • 87.
    Código de ExceçãoRuim 3.7 Tratamento de Erros Problemas - Não retorna uma exceção - Abafa exceção do Gson - Retorna “null” - Imprime direto no console Consequências - Contrato baseado em “null” - Omissão do erro raiz (causa) - Força a testar nulidade: kotlin: ?. java: if (result != null) - Log inadequado e ineficiente
  • 88.
    Código de Exceçãocom Perda da Causa Raiz 3.7 Tratamento de Erros Problemas - Não retorna uma exceção - Abafa exceção do Gson - Retorna “null” - Imprime direto no console Consequências - Contrato baseado em “null” - Omissão do erro raiz (causa) - Força a testar nulidade: kotlin: ?. java: if (result != null) - Log inadequado e ineficiente
  • 89.
    Código Melhorado (Repassandoa Causa Raiz) 3.7 Tratamento de Erros O que acontece se “json” ou “clazz” forem nulos? Por que nunca se deve passar “null” como parâmetro?
  • 90.
    Código de TesteObtendo a Causa Raiz (Gson) 3.7 Tratamento de Erros
  • 91.
    Questão Sobre aCriação de Classes de Exceção 3.7 Tratamento de Erros Existe realmente a necessidade de criar a exceção “JsonException”? Não seria melhor usar as exceções prontas do Gson?
  • 92.
  • 93.
    Filosofia sobre Fronteiras3.8 Fronteiras - Código de terceiro quase sempre é “infraestrutura” - Infraestrutura deve ser isolada do negócio - Testes de aprendizado são uma boa dica
  • 94.
    Estudo de Casodo Parsing de Json 3.8 Fronteiras Necessidade Fazer parsing e serialização de Json em várias partes da aplicação Inicialmente usando o “Gson” Opcionalmente pode ser usado outra biblioteca como “Jackson” A infraestrutura deve ser isolada Domain ControllerController JsonParser Interface toJson() fromJson() JsonParser Interface toJson() fromJson() GsonParserGsonParser JacksonParserJacksonParser
  • 95.
    Estudo de Casodo Parsing de Json 3.8 Fronteiras Terceiros Infraestrutura Infraestrutura Aplicação API de Terceiros
  • 96.
    Estudo de Casodo Parsing de Json 3.8 Fronteiras GsonParserGsonParser JacksonParserJacksonParser
  • 97.
    Parser Baseado noGson 3.8 Fronteiras GsonParserGsonParser Encapsula o Gson É um JsonParser
  • 98.
    Injetando Dependência 3.8Fronteiras Criação manual Injeção de dependência Controller Parser Interface toJson() fromJson() GsonParser JacksonParser
  • 99.
    Teste de Aprendizadodo Gson 3.8 Fronteiras
  • 100.
    Parte 3.9Parte 3.9 Testesde UnidadeTestes de Unidade
  • 101.
    Filosofia sobre Testesde Unidade 3.9 Testes de Unidade - Teste de unidade dá feedback sobre o design - O feedback deve chegar o quanto antes - TDD é uma boa opção para tornar mais fácil - Testes de unidade são atividade de construção - Cobertura de testes provê confiança - Refatoração sem cobertura pode ser uma aventura - Teste também é código e deve ser limpo
  • 102.
    Cenário de Construçãocom TDD em 3 Iterações 3.9 Testes de Unidade Requisitos do Contador de Constantes 1. Criar uma função que conte todas as constantes inteiras de uma classe passada como parâmetro (atributos estáticos e “final”) 2. Parâmetro “null”, classes abstratas e enuns são ignorados e deve ser retornado “-1” como resultado da função 3. A contagem deve incluir todas as superclasses
  • 103.
    As 3 Regrasdo TDD 3.9 Testes de Unidade Refatora Falha Passa 1. Você não pode escrever nenhum código até ter escrito um teste que detecte uma possível falha. 2. Você não pode escrever mais testes de unidade do que o suficiente para detectar a falha – não compilar é não ter efeito. 3. Você não pode escrever mais código do que o suficiente para passar nos testes.
  • 104.
    TDD – Escrevera Primeira Versão do Teste e Falhar 3.9 Testes de Unidade Falha 1. Criar uma função que conte todas as constantes inteiras de uma classe (estáticos e “final”)
  • 105.
    TDD – Escrevero Código Real e Passar 3.9 Testes de Unidade Passa
  • 106.
    TDD – Refatoraro Código Real e Passar (Apenas Melhoria) 3.9 Testes de Unidade Passa Extração da lista Extração do método
  • 107.
    TDD – Refatoraro Teste para o Requisito 2 (Iteração 2) 3.9 Testes de Unidade 2. Classes abstratas e enuns são ignorados (retornar -1), inclusive “null” Refatora
  • 108.
    TDD – TesteRefatorado Vai Falhar 3.9 Testes de Unidade Falha Falha Aqui
  • 109.
    TDD – Ajustedo Código para Atender o Teste (Iteração 2) 3.9 Testes de Unidade Passa Adição do requisito 2
  • 110.
    TDD – Refatoraro Teste para o Requisito 3 (Iteração 3) 3.9 Testes de Unidade 3. A contagem deve incluir as superclasses Refatora
  • 111.
    TDD – TesteRefatorado Vai Falhar (Iteração 3) 3.9 Testes de Unidade Falha Tem 2 constantes Falha Aqui
  • 112.
    TDD – Ajustedo Código para Atender o Teste (Iteração 3) 3.9 Testes de Unidade Passa Adição do requisito 3
  • 113.
  • 114.
    Filosofia sobre Classes3.10 Classes - Classes devem ser pequenas - Devem ter somente uma responsabilidade (SRP) - Ter apenas um motivo para mudar - Devem ter coesão interna - Devem encapsular seus dados ao máximo - Devem ter baixo acoplamento a outras classes
  • 115.
    Jogando “Pedra, Papele Tesoura” 3.10 Classes Requisitos do Melhor de 3 (Pedra, Papel e Tesoura) 1. Criar uma simulação de dois jogadores jogando “pedra, papel e tesoura” por um número variável de rodadas (3, 5 etc). 2. O jogo deve parar se um jogador já for o vencedor antes da última rodada (cenário de vitória antecipada). 3. Ao final deve ser indicado o vencedor (ou empate) e listados os resultados de todas as rodadas.
  • 116.
    Código Fornecido 3.10Classes Enums Hand: Possibilidades de escolha (Pedra, Papel ou Tesoura) MatchResult: Resultados de um match (Primeiro Vence, Empate ou Segundo Vence) Result: Resultado em relação ao primeiro jogador (Perde: -1, Empata: 0 ou Vence: 1). Abstração de rockPaperScissors
  • 117.
    Implementação Procedural Simples3.10 Classes rockPaperScissors(char,char):int Problemas - Um método faz tudo - Muitos conceitos juntos: “Jogador”, “Match”, “Resultados” - “Rodadas” constantes - Nomes “hard coded” - Não pára em vitória antecipada Questões Como se livrar do código legado rockPaperScissors ? A solução é muito procedural? Como testar isso? 2 escolhas aleatórias
  • 118.
    Modelo Lógico: PossívelSolução OO 3.10 Classes Níveis de Abstração - O Jogo e os resultados - Uma Disputa entre jogadores - O resultado de uma disputa - Jogador com nome e escolha - A opção de jogada
  • 119.
    Modelo Lógico: Análisedos Conceitos do Jogo 3.10 Classes Inicialização e Contexto Conceito: 1 JogadorConceito: 1 Disputa Conceito: O Jogo em si Várias rodadas e resultado Código “Legado”: Lógica do jogo Conceito: Resultado de uma Disputa Abstração sobre -1,0,1 Opções do Jogo: R, P e S
  • 120.
  • 121.
    Classe BestOfThree 3.10Classes Responsabilidade: representa um jogo de “Pedra, Papel e Tesoura” com a definição do número de rodadas (3 por padrão) e armazena os resultados (estado) API - Executa o jogo (play) - Retorna se tem vencedor - Retorna o vencedor (se houver) - Retorna os resultados Delega para a classe Match o conhecimento sobre a disputa entre dois jogadores e seu resultado Indireção para Match Requisito número 2
  • 122.
    Classe Match 3.10Classes Representa uma disputa entre dois jogadores e seu resultado (imutável) API: Executa a disputa (play) e gera um resultado Delega para os jogadores a escolha da “mão” que será jogada. Delega para a função rockPaperScissors a lógica de quem venceu a disputa com base nestas escolhas
  • 123.
    Classe Player 3.10Classes Representa um jogador que deve fazer uma escolha de qual mão usar na disputa Delega para Hand a escolha de forma aleatória, mas encapsula esta decisão O jogador poderia ser criado com a escolha já feita anteriormente
  • 124.
    Solução OO xProcedural 3.10 Classes A solução OO tem mais código, mas cada parte é mais fácil de entender que o todo Permite testes de unidade por classe Cada abstração está em uma classe Cada classe tem uma responsabilidade A necessidade de manutenção tende a impactar somente uma parte do código
  • 125.
    Refatoração: Livrando-se doCódigo Legado 3.10 Classes Como remover rockPaperScissors? Qual classe deve conhecer esta regra de quem vence quem? Como implementar a regra de forma a gerar o menor impacto possível? Qual seria o impacto de alterar e testar na solução procedural?
  • 126.
    Refatoração: Livrando-se doCódigo Legado 3.10 Classes
  • 127.
    Responsabilidade da Classe“Hand” 3.10 Classes Código expressivo sobre a regra do jogo Função (API) que externaliza a regra
  • 128.
    Impacto: Nova Classe“Match” 3.10 Classes Função (API) que externaliza a regra Código expressivo sobre a regra do jogo Implementação alternativa (extensão) de “Match” livre do código legado O método “play” expressa o negócio de forma simples e elegante
  • 129.
    Impacto da Refatoração3.10 Classes Criação da classe “SmartMatch” Troca de “Match” por “SmartMatch” Opções: - Injeção de dependência - Segregação de contexto - Implementação funcional
  • 130.
  • 131.
    Filosofia sobre Testesde Unidade 3.11 Sistemas Complexos - Sistemas precisam de separação de preocupações - Separe a inicialização do uso de um sistema - Sistemas beneficiam-se do uso de uma DSL
  • 132.
    Separação do Preocupações(Modularização) 3.11 Sistemas Complexos - Criação de objetos e escopos superiores - Conexão com BD, I/O e efeitos colaterais Separação de Preocupações do DDD Main main() Negocio Módulo A Domain Service Módulo B Função X1 Classe X Função X2 Função X3 Factory Create Módulo C Função Y1 Classe Y Função Y2 Função Y3 Repository Save
  • 133.
    Separe a Construçãodo Uso no Sistema 3.11 Sistemas Complexos Inicialização e Contexto Conceito: 1 JogadorConceito: 1 Disputa Conceito: O Jogo em si Várias rodadas e resultado Código “Legado”: Lógica do jogo Conceito: Resultado de uma Disputa Abstração sobre -1,0,1 Opções do Jogo: R, P e S As demais classes não devem conhecer sobre contexto e inicialização Devem ser projetadas como se isso fosse ser resolvido para elas… E será! Main conhece o sistema Sistema ignora o Main Função pura ignora tudo fora do seu escopo
  • 134.
    Injeção de DependênciaVia Construtor 3.11 Sistemas Complexos O uso de CDI com @inject faz o mesmo trabalho automaticamente Injeção de dependência minimiza o acoplamento entre classes além de facilitar os testes de unidade
  • 135.
    DSL – DomainSpecific Language 3.11 Sistemas Complexos DSL: Código Expressivo Feature Envy DSL encapsula a lógica Main main() Negocio Módulo A Domain Service Módulo B Função X1 Classe X Função X2 Função X3 Factory Create Módulo C Função Y1 Classe Y Função Y2 Função Y3 Repository Save Classes e Funções são negócio destilado O domínio do problema é descrito na solução
  • 136.
  • 137.
    Filosofia sobre Simplicidade3.12 Simplicidade - Todos os testes devem passar (deve haver testes) - Nenhuma duplicação de código ou configuração - O código deve expressar o negócio e sua intenção - A solução deve usar o mínimo de elementos - Simples não é Simplório (pelo contrário) - Simplicidade é a sofisticação máxima
  • 138.
    As 4 Regrasda Simplicidade 3.12 Simplicidade Testes Tempestivos Refatoração Tempestiva https://martinfowler.com/bliki/BeckDesignRules.html
  • 139.
    Regra 1 deProjeto Simples: Efetue Todos os Testes 3.12 Simplicidade 1 2 3 Teste 1: Afere se a regra entre as opções está funcionando: Pedra vence Tesoura, Tesoura vence Papel e Papel vence Pedra Teste 2: Afere se o SmartMatch retorna o resultado certo dado que já se sabe o que os jogadores vão escolher (mock) Teste 3: Afere que, de 7 rodadas, irá parar na quarta com 4 vitórias de “Bob”
  • 140.
    Regras de 2a 4 de Projeto Simples: Refatoração 3.12 Simplicidade Conceitos - O Jogo e os resultados - Uma Disputa entre jogadores - O resultado de uma disputa - Jogador com nome e escolha - A opção de jogada DSL: Código Expressivo A: Reúso B: Refactoring Regra 1 conceito p/ classe
  • 141.
    já sei cleancode? técnicatécnica, treino e tempo, treino e tempo abordagem de atuação profissional não é sobre códigonão é sobre código é sobreé sobre fazer códigofazer código
  • 142.
  • 143.
    Laboratório de Refatoração4 Refatoração treinotreino github.com/refactown/lab
  • 144.
    REFERÊNCIAS BECK, Kent. Padrõesde Implementação. Porto Alegre, Bookman, 2013. EVANS, E. Domain-Driven Design – Atacando as complexidades no coração do software. 2a edição, Rio de Janeiro, Alta Books, 2010. FOWLER, Martin. BeckDesignRules, https://martinfowler.com/bliki/BeckDesignRules.html FOWLER, Martin. TellDontAsk, https://martinfowler.com/bliki/TellDontAsk.html HUNT, Andrew; THOMAS, David, O Programador Pragmático, Bookman, 2010 MARTIN, Robert, O Codificador Limpo, Alta Books, Rio de Janeiro 2012 MARTIN, Robert, Código Limpo, Alta Books, Rio de Janeiro 2011
  • 145.
    Programação Funcional XOrientação a Objetos 145/145 1 42 3 5 Prática para encerrar... Obrigado! Douglas Siviotti douglas.siviotti@gmail.com github.com/siviotti Teoria