clean code part 2

29
Clean Code Francisco Clauvane

Upload: clauvane1708

Post on 02-Jul-2015

167 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Clean code   part 2

Clean CodeFrancisco Clauvane

Page 2: Clean code   part 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.

Page 3: Clean code   part 2

Sumario

1. Tratamento de erro2. Limites3. Teste de unidade4. Classes5. Sistemas6. Emergencia7. Concorrencia8. Refinamento Sucessivo

Page 4: Clean code   part 2

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.

Page 5: Clean code   part 2

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();

}}

}

Page 6: Clean code   part 2

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();

}}

}

Page 7: Clean code   part 2

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.

Page 8: Clean code   part 2

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();○ }

Page 9: Clean code   part 2

1-Tratamento de erro

● Nao retorne NULL● Nao passe NULL

Page 10: Clean code   part 2

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.

Page 11: Clean code   part 2

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

Page 12: Clean code   part 2

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

Page 13: Clean code   part 2

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.

Page 14: Clean code   part 2

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.

Page 15: Clean code   part 2

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.

Page 16: Clean code   part 2

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

Page 17: Clean code   part 2

3-Teste de unidade

F.I.R.S.T.● First● Independent● Repeatable● Self-Validating● Timely

Page 18: Clean code   part 2

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

Page 19: Clean code   part 2

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

Page 20: Clean code   part 2

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

Page 21: Clean code   part 2

5-Sistemas

Comecaremos pela construcao:

public Service getService(){if(service == null){

service = new MyServiceImpl(...);}return service;

}

Page 22: Clean code   part 2

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

Page 23: Clean code   part 2

5-Sistemas

Desenvolvimento gradual● Analogia a construcao de um pequeno

vilarejo que se torna uma grande cidade

Page 24: Clean code   part 2

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

Page 25: Clean code   part 2

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

Page 26: Clean code   part 2

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

Page 27: Clean code   part 2

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?

Page 28: Clean code   part 2

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

Page 29: Clean code   part 2

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.