• Like
qualidade de código: boas práticas, princípios e padrões
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

qualidade de código: boas práticas, princípios e padrões

  • 5,091 views
Published

 

Published in Technology , Health & Medicine
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,091
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
63
Comments
3
Likes
2

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. Qualidade de Código: boas práticas, princípios e padrões. @edgarddavidson http://edgarddavidson.com
  • 2. Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis http://engenhariadesoftwareagil.com
  • 3. Curso de Pós Graduação em Teste e Qualidade de Softwarehttp://testeequalidadedesoftware.com
  • 4. Referências
  • 5. <trollagem>
  • 6. Um típico implementador de POG convícto
  • 7. 1°encontro dosimplementadores de POG convíctos
  • 8. Projeto entregue pelosimplementadores de POG convíctos
  • 9. Um dia típico de trabalho de um implementador de POG convícto
  • 10. Implementadores de POG convíctos também trabalham em equipe
  • 11. Um implementador de POG convícto não tem medo do perigo
  • 12. Um implementador de POG convícto assume que boas práticas, princípios e padrões é tudo um VIAGEM
  • 13. Por algummotivo oserros se repetem
  • 14. </trollagem>
  • 15. Code Smell
  • 16. Baixa coesão e Alto acoplamento são um dos fatores fundamentais para aumentar a dependência,dificultar a manutenção, expansão e alteração.
  • 17. 1° Code Smell
  • 18. Rigidez“O sistema é difícil de mudar, porque cada vez que você muda alguma coisa, vocêtem que mudar alguma outra coisa em uma sucessão interminável de mudanças.”
  • 19. 2° Code Smell
  • 20. Fragilidade“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes, completamente alheios.”
  • 21. 3° Code Smell
  • 22. Imobilidade“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”
  • 23. 4° Code Smell
  • 24. Complexidade Desnecessária“Há muitas estruturas de código muito inteligentes que não são necessárias agora, mas poderia ser muito útil um dia.”
  • 25. 5° Code Smell
  • 26. Repetições Inúteis“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”
  • 27. Mostra aí como combater esse tal de Code Smell
  • 28. Qualidade de Código boas práticas, princípios e padrões.
  • 29. Início Teste unitário Princípios de Projeto OOCódigo Refatoração POO Padrões de Projeto OO Integração Contínua
  • 30. Desenvolvimento Dirigido pelos Testes
  • 31. Programação em Par
  • 32. Refatoração
  • 33. Substitua Herança por DelegaçãoExemplo: pilha subclasse de vetor.Class MyStack extends Vector { public void push (Object element) { insertElementAt (element, 0);} public Object pop () { Object result = firstElement (); removeElementAt (0); return result;}
  • 34. Refatorando...Crio campo para superclasse.Class MyStack extends Vector { private Vector _vector = this; public void push (Object element) { _vector.insertElementAt (element, 0);} public Object pop () { Object result = _vector.firstElement (); _vector.removeElementAt (0); return result;}
  • 35. Refatorando...Removo herança.Class MyStack extends Vector { private Vector _vector = this; new Vector (); public void push (Object element) { _vector.insertElementAt (element, 0); } public Object pop () { Object result = _vector.firstElement (); _vector.removeElementAt (0); return result; }
  • 36. Acoplamento e Coesão DiminuirAcoplamento Aumentar Coesão
  • 37. Programação Orientada a Objetos Abstração Encapsulamento Reuso Herança Polimorfismo
  • 38. Princípios de Projeto •Restrição ao Acesso •Prefira a composição à herança •Programação para a interface •Separe o que permanece igual do que varia
  • 39. S ingle Responsibility Principle (SRP)O pen/Closed Principle (OCP)L iskov substitution principle (LSP)I nterface Segregation Principle (ISP)D ependency Inversion Principle (DIP)
  • 40. Princípios de Projeto OO – Single Responsibility Principle (SRP) "Nunca deve haver mais de um motivo para uma classe ser alterada"
  • 41. Violação do princípio: Considere a Classe TAD
  • 42. Adequação ao princípio:
  • 43. Princípios de Projeto OO – Open/Closed Principle (OCP)“As entidades devem estar abertas para extensão, mas fechadas para modificação”
  • 44. Violação do princípio:Considere o método para calcular o preço total de peças: public double totalPrice(Part[] parts){ double total = 0.0; for(int i=0; i < parts.length; i++){ total += parts[i].getPrice(); } return total; }O método processa diferentes tipos de peças da hierarquia de Part, sem demandar modificações, portanto conformado- se com o OCP.
  • 45. Violação do princípio:O que ocorrerá se a empresa decidir cobrar um preço adicional por certas peças? public double totalPrice(Part[] parts){ double total = 0.0; for(int i = 0; i < parts.length; i++){ if(parts[i] instanceof Motherbord) total +=(1.45 * part[i].getPrice()); else if (parts[i] instanceof Memory) total += (1.30 * part[i].getPrice()); else total += part[i].getPrice(); } return total; }
  • 46. Adequação ao princípio:Considere novamente o método totalPrice original public double totalPrice(Part[] parts){ double total = 0.0; for(int i = 0; i < parts.length; i++){ total += part[i].getPrice(); } return total; }Note que agora o método não precisa ser alterado para processar diferentes tipos de peças.Mas as subclasses especiais de Parts precisam
  • 47. Adequação ao princípio:public class Part{ private double basePrice; public void setPrice(double price){ basePrice = price; } public double getPrice(){return basePrice;}}public class motherBoard extends Part{ public double getPrice(){return 1.45*super.getPrice();}public class Memory extends Part{ public double getPrice(){ return 1.30 * super.getPrice(); }}
  • 48. Princípios de Projeto OO – Liskov substitution principle (LSP)“Funções que usam objetos de uma superclasse devem ser capazes de usar objetos das subclasses.”
  • 49. Princípios de Projeto OO – Interface Segregation Principle (ISP) “Interfaces mais específicas melhor que interface de propósito diversos.”
  • 50. Princípios de Projeto OO – Dependency Inversion Principle (DIP) “Módulos de alto nível não devem depender de módulos de nível mais baixo. Todos devem depender de abstrações.”
  • 51. Padrões de Projeto
  • 52. Padrões Arquiteturais De acordo com oscondutores arquiteturais
  • 53. Atender ao negócio Usuário FelizNecessidade atendida $$$$$$$$$
  • 54. @edgarddavidsonhttp://edgarddavidson.com