clean code part 2
TRANSCRIPT
Clean CodeFrancisco Clauvane
Sobre
Esta apresentacao teve como base o livro Clean Code, minha experiencia profissional e as dicas dadas por profissionais mais experientes. Onde o objetivo da mesma e mostrar na teoria e na pratica o que e um codigo limpo.
Sumario
1. Tratamento de erro2. Limites3. Teste de unidade4. Classes5. Sistemas6. Emergencia7. Concorrencia8. Refinamento Sucessivo
1-Tratamento de erro
● Tratamento de erro em codigo limpo?● Esse recurso e importante, mas se
obscurecer a logica, esta errado.● O tio bob nos traz algumas tecnicas e
consideracoes para que voce crie um codigo limpo e robusto e que trate os erro com estilo e elegancia.
1-Tratamento de erro
Use excecoes ao inves de retornar codigo.
public class AppVenda{public static void main (String args []){
Produto produto = produtoServise.load(produto.getCodigo());seters... if(produto.getStatus().equals(StatusProduto.
PRAZO_DE_VALIDADE_EXPIRADO)){System.out.println("Erro ao salvar o pedido: Prazo de validade expirado");
}else {produto.save();
}}
}
1-Tratamento de erro
Use excecoes ao inves de retornar codigo.
public class AppVenda{public static void main (String args []){
Produto produto = produtoServise.load(produto.getCodigo());seters... if(produto.getStatus().equals(StatusProduto.
PRAZO_DE_VALIDADE_EXPIRADO)){throw new Exception("Prazo de validade expirado");
}else {produto.save();
}}
}
1-Tratamento de erro
● Crie primeiro sua estrutura try-catch-finally para depois construir o codigo.○ TDD
● Use excecoes nao verificadas○ Excecoes verificadas sao 'CARAS'○ Use excecoes verficadas apenas em situacoes
criticas, por exemplo: Biblioteca○ De maneira geral, o custo da dependencia e maior
que o das vantagens.● Forneca excecoes com contexto
○ Nao use Exception no seu catch.○ Use mensagens informativas.
1-Tratamento de erro
● Defina as classes de excecoes segundo as necessidades do chamador.○ Transformar varios catch em um tipo comum.
● Defina o fluxo normal○ try{○ MealExpenses expenses = dao.load(employee.getId);○ m_total += expenses.getTotal();○ }○ catch {○ m_total += getMealPerDiem();○ }
1-Tratamento de erro
● Nao retorne NULL● Nao passe NULL
2-Limites
● Raramente controlamos todos os softwares em nossos sistemas.○ Compramos pacotes de outros fabricantes○ codigos livres○ outras equipes
● O uso do codigo de terceiros○ Ha uma tensao natural entre os fornecedores e o
seu usuario.○ java.util.Map
● Nao use os limites○ Evite retorna-los ou aceita-los como parametros em
APIs publicas.
2-Limites
Explorando e aprendendo sobre limites● Codigo de terceiros nos ajudam a obter mais
funcionalidades em menos tempo.● Por onde comecar com codigo de terceiros?● Problemas ao integrar com codigo de terceiros:
○ tempo para ler a documentacao○ escrever codigo para testar se a funcionalidade
executa como esperavamos○ deuparacao para descobrir se os bugs sao do nosso
codigo ou do codigo do terceiro
2-Limites
Explorando e aprendendo sobre limites● Problemas ao integrar com codigo de terceiros:
○ Entender codigo de terceito e dificil.○ Integra-lo ao seu e mais ainda.○ Fazer os dois anteriores ao mesmo tempo e muito
mais ainda○ Solucao: Testes!○ Testes de aprendizagem
■ Gratuito■ Robutez quanto a novas distribuicoes
2-Limites
Uso de codigo que nao existe ainda● Novo tipo de limite: Separa o conhecido do
desconhecido.
Limites Limpos● E melhor depender de algo que voce
controle do que pegar algo que controle voce.
3-Teste de unidade
Evolucao da nossa profissao● Testes
TDD● As tres leis que a regem
○ Nao se deve escrever o codigo de producao ate que o primeiro teste de falha tenha sido criado
○ Nao se deve escrever mais de um teste do que o necessario para falhar, e nao compilar e falhar.
○ Nao se deve escrever mais teste de produco do que o necessario para aplicar ao teste de falha atual.
3-Teste de unidade
Testes limpos● "Os codigos de testes sao tao importantes
quanto o codigo de producao. Ele nao e componente secundario. Ele requer raciocinio, planejamento e cuidado. E preciso mante-lo tao limpo quanto o codigo de producao."
● O que torna um teste limpo?○ Tres regras:
■ Legibilidade,legibilidade e legibilidade.
3-Teste de unidade
Padrao duplo● Um teste nao precisa ser mais eficiente que
um codigo de producao.○ Ambiente de teste e ambiente de producao sao dois
ambiente que possuem requisitos diferentes.
Uma afirmacao por teste
Um unico conceito por teste
3-Teste de unidade
F.I.R.S.T.● First● Independent● Repeatable● Self-Validating● Timely
4-Classes
Organizacao das classes● Toda classe deve comecar com uma lista de
variaveis○ public,public static e constantes devem vir primeiro○ private static, privates devem vir depois
● Encapsulamento○ Protected, somente quando for o ultimo recurso.
● Classes deve ser pequenas○ Diferentemente das funcoes as classes nao sao
medidas atraves da quantidade de linhas, mas sim atraves da sua quantidade de responsabilidades.■ Responsabilidade != metodos
4-Classes
● O nome da classe e muito importante○ Se o nome for generico entao provavelmente sua
classe tera muitas responsabilidades○ Principio da responsabilidade unica
■ Devemos escrever um texto descritivo da classe sem utilizar as palavras: 'se','e','ou','mas'. O uso destas palavras sao um indicio de excesso de responsabilidade
■ Melhor um sistema com muitas classes pequenas do que um sistema com poucas classes grandes
■ Coesao
5-Sistemas
"Complexidade mata. Ela suga a vida dos desenvolvedores, dificulta o planejamento, a construcao e o teste dos produtos."
● Nivel de abstracao mais alto○ O nivel de sistema
Separe a construcao e uso do sistema● Cosntrucao != utilizacao
5-Sistemas
Comecaremos pela construcao:
public Service getService(){if(service == null){
service = new MyServiceImpl(...);}return service;
}
5-Sistemas
● Possui uma dependencia da classe MyServiceImpl
● Possui uma violacao ao principio da resposabilidade unica
● Possivel dificuldade para Testar○ Mock para a classe MyServiceImpl
● Nao temos garantia alguma que a classe MyServiceImpl sera sempre correta.
● Injecao de dependencia
5-Sistemas
Desenvolvimento gradual● Analogia a construcao de um pequeno
vilarejo que se torna uma grande cidade
6-Emergencia
Segundo Kent, um projeto e "simples" se seguir as seguintes regras:
1. Efetuar todos os testes2. Sem duplicacao de codigo3. Expressar o proposito do programador4. Minimizar o numero de classes e metodos
Estas regras estao em ordem de relevancia
7-Concorrencia
● Muito dificil escrever programas concorrentes limpos
● Estrategia de desacoplamento○ Separa o que e executado de quando e executado
● Mitos e conceitos equivocados○ A concorrencia sempre melhora o desempenho○ O projeto nao muda ao criar programas concorrentes○ Entender as questoes de concorrencia nao e
importante quando se trabalhacom um conteiner○ A concorrencia gera um certo aumento, tanto no
desempenho como na criacao de codigo adicional○ Uma concorrencia e complexa, mesmo para
problemas simples
7-Concorrencia
● Mitos e conceitos equivocados○ Os bugs de concorrencia geralmente nao se repetem,
portanto sao frequentemente ignorados como casos unicos em vez dos defeitos que realmente sao
○ A concorrencia geralmente requer uma mudanca essencial na estrategia do projeto.
Desafios● A seguir um trecho de codigo para
exemplificar os possiveis problemas em concorrencia
7-Concorrencia
public class X{private int ultimoIdUsado = 42;
public int getProximoIdUsado(){return ++ultimoIdUsado;
}}
O que Aconteceria se duas threads usassem o este metodo ao mesmo tempo?
7-Concorrencia
Possiveis resultados:1. Thread A recebe 43, Thread B recebe 44 e o ultimoIdUsado e 442. Thread A recebe 44, Thread B recebe 43 e o ultimoIdUsado e 443. Thread A recebe 43, Thread B recebe 43 e o ultimoIdUsado e 43
O incrivel terceiro resultado ocorre quando as threads se cruzam. Isto ocorre po r que elas possuem inumeros caminhos a percorrer onde alguns destes caminhos podem retornar resultados incorretos.
para o tipo int sao 12.870 caminho possiveispara o tipo long sao 2.704.156 caminho possiveis
8-Refinamento sucessivo
Como ja foi visto e quaseimpossivel encontrar a melhor solucao na primeira tentativa. O mais natural e que durante o dia-a-dia voce melhore sempre que possivel ou necessario o seu codigo aplicando as boas praticas de desenvolvimento, desta forma voce em algum periodo de tempo ira encontrar um codigo bem "simples" e que atenda todas as necessidades.