![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();
}
}
}](https://image.slidesharecdn.com/cleancode-part2-130327151028-phpapp01/85/Clean-code-part-2-5-320.jpg)
![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();
}
}
}](https://image.slidesharecdn.com/cleancode-part2-130327151028-phpapp01/85/Clean-code-part-2-6-320.jpg)
Clean code part 2
- 2. 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.
- 3. Sumario 1. Tratamento de erro 2. Limites 3. Teste de unidade 4. Classes 5. Sistemas 6. Emergencia 7. Concorrencia 8. Refinamento Sucessivo
- 4. 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.
- 5. 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(); } } }
- 6. 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(); } } }
- 7. 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.
- 8. 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(); ○ }
- 9. 1-Tratamento de erro ● Nao retorne NULL ● Nao passe NULL
- 10. 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.
- 11. 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
- 12. 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
- 13. 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.
- 14. 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.
- 15. 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.
- 16. 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
- 17. 3-Teste de unidade F.I.R.S.T. ● First ● Independent ● Repeatable ● Self-Validating ● Timely
- 18. 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
- 19. 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
- 20. 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
- 21. 5-Sistemas Comecaremos pela construcao: public Service getService(){ if(service == null){ service = new MyServiceImpl(...); } return service; }
- 22. 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
- 23. 5-Sistemas Desenvolvimento gradual ● Analogia a construcao de um pequeno vilarejo que se torna uma grande cidade
- 24. 6-Emergencia Segundo Kent, um projeto e "simples" se seguir as seguintes regras: 1. Efetuar todos os testes 2. Sem duplicacao de codigo 3. Expressar o proposito do programador 4. Minimizar o numero de classes e metodos Estas regras estao em ordem de relevancia
- 25. 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
- 26. 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
- 27. 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?
- 28. 7-Concorrencia Possiveis resultados: 1. Thread A recebe 43, Thread B recebe 44 e o ultimoIdUsado e 44 2. Thread A recebe 44, Thread B recebe 43 e o ultimoIdUsado e 44 3. 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 possiveis para o tipo long sao 2.704.156 caminho possiveis
- 29. 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.