Your SlideShare is downloading. ×
0
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Código Limpo Dual
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Código Limpo Dual

69

Published on

Apresentação sobre Código Limpo para os desenvolvedores Progress e .NET na empresa Dual.

Apresentação sobre Código Limpo para os desenvolvedores Progress e .NET na empresa Dual.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
69
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CÓDIGO LIMPO Melhorando a qualidade do código
  • 2. Nomes significativos  Use nomes relevantes, que mostrem sua intenção  int d; //quantidade de dias  int dias;  int diasAno;  int diasAteFinalDeAno;  Não use o prefixos/sufixos só porque já existe a variável com o mesmo nome  Produto x ProdutoInfo x ProdutoData  lista, lista1, lista2, aLista, outraLista, listaFinal  listaFinal do quê?
  • 3. Nomes significativos  Redundância  A palavra variável nunca deve aparecer no nome de uma variável. Assim como a palavra tabela nunca deve aparecer no nome da tabela.  Como é que NomeString é melhor que apenas Nome?  Use nomes pronunciáveis  Facilita a leitura do código  int qtdeDiaDpsFinAno;  int quantidadeDiasDepoisFinalDoAno;
  • 4. Nomes significativos  Métodos/funções  Devem ser verbos ou frases verbais, ações.  Salvar()  PodeSalvar()  FoiSalvo()  CalcularICMS()  EstaValido()  GerarFeriados()  ObterProdutoAtivo()
  • 5. Small!  “A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles devem ser menores ainda.”  Robert C. Martin (Uncle Bob)  “Functions should do one thing. They should do it well. They should do it only.”  O maior problema é saber o que é essa “uma coisa”.  Exemplo: quantas coisas a função a seguir (Processamento de Pedidos) está fazendo?
  • 6. Small!  É fácil mal interpretar e dizer que está fazendo 3 coisas:  1. Verificando se o pedido é válido  2. Processando pedido valido  3. Processando pedido inválido
  • 7. Small!  A função tem 3 passos, mas esses passos estão no mesmo nível de abstração:  Para Processar o Pedido, nós verificamos se ele é válido; se sim, o processamos como pedido válido, senão, o processamos como pedido inválido.  O nível de abstração seria “Processar o Pedido”.  O método não deve fazer nada além disso.  Por exemplo, o método não poderia Salvar o Pedido processado no banco, pois fugiria do Processar o Pedido.
  • 8. Comentários  “Não comente código ruim – reescreva-o.”  Brian W. Kernighan  O melhor comentário é o próprio código.  O que é melhor?  Ou...
  • 9. SOLID Responsa bilidade Única Aberto Fechado Substituição Liskov Segregação Interface Inversão Dependência
  • 10. Princípio de Responsabilidade Única
  • 11. Princípio de Responsabilidade Única  Uma classe ou método deve ter uma única responsabilidade.  Uma classe ou método deve ter uma e apenas UMA razão para mudar.  Exemplo:  ValidarTotalItensPedido(Pedido pedido)  1. Valida se a soma dos Itens bate com o total do Pedido.  Se não bate, lê o parâmetro 103 do sistema para ver qual atitude tomar.  Toma a decisão que o parâmetro 103 propõe.  O parâmetro diz para buscar a entidade principal...  2. Retorna se está válido ou não.
  • 12. Princípio de Responsabilidade Única  Então como fazer nesse caso?  ProcessarPedido(Pedido pedido)  estaValido = ValidarTotalItensPedido(pedido)  SE estaValido = FALSE  ProcessarPedidoInvalido()  ValidarTotalItensPedido(Pedido pedido)  Retorna se a soma dos Itens bate com o total do Pedido.  ProcessarPedidoInvalido()  LerParametro(103)  BuscaEntidadePrincipal()
  • 13. Princípio de Responsabilidade Única  Qual a vantagem disso?  Ler o código e de imediato saber o que ele está fazendo e como ele está fazendo.  Ler como você estivesse lendo instruções ou até mesmo um livro.  Para Processar o Pedido, verifica-se o Total dos Itens desse Pedido. Se o total não bater, o pedido é inválido.  Para Processar um Pedido Inválido, lê-se o parâmetro 103, para descobrir qual providência tomar.  De acordo com o parâmetro 103, busca-se a entidade principal.  Com a entidade principal...
  • 14. Princípio Aberto Fechado
  • 15. Princípio Aberto Fechado  Separação de Pedidos CRM  Antes – SeparaPedidosNegociacao(...):  SE ehParaSeparaPedidos  SeparaPorLinhaComercial()  SENAO  PedidoUnico()
  • 16. Princípio Aberto Fechado  Quebrando o princípio:  Depois – SeparaPedidosNegociacao(...):  SE estrategia = POR_LINHA_COMERCIAL  SeparaPorLinhaComercial()  SENAO SE estrategia = POR_REPRESENTANTE  SeparaPorRepresentante()  SENAO  PedidoUnico()
  • 17. Princípio Aberto Fechado  Usando abstrações e Strategy Pattern:  Depois – SeparaPedidosNegociacao(...):  estrategias = CarregarEstrategiasDeSeparacaoDePedidos()  PARA CADA estrategia EM estrategias  SE estrategia.UsarEssaEstrategia()  estrategia.SepararPedido()
  • 18. Inversão de Dependência
  • 19. Inversão de Dependência  Módulos de alto nível não devem depender de módulos de baixo nível.  Alto nível: regras e entidade de negócios.  Baixo nível: acesso a dados: banco, arquivos ou WebService.  Módulos de alto nível devem utilizar um mecanismo para obter os dados de baixo nível, mas não depender dos detalhes desse mecanismo.
  • 20. Inversão de Dependência ParametroDataAcc ess SeparacaoPedidos
  • 21. Inversão de Dependência IParametroDataAcc ess ParametroDataAcce ss SeparacaoPedidos
  • 22. Referências  Software Practices, Pluralsight  Principles of Object Oriented Design  Design Patterns  Clean Code A Handbook of Agile Software Craftsmanship, Robert C. Martin  DDD Quickly, Abel Avram & Floyd Marinescu  Resumo de DDD por Eric Evans  Agile Principles, Patterns, and Practices in C#, Robert C. Martin

×