Qualidade de Código:       boas práticas,        princípios e         padrões. @edgarddavidson http://edgarddavidson.com
Curso de Pós Graduação em      Engenharia de Software Centrada em Métodos Ágeis   http://engenhariadesoftwareagil.com
Curso de Pós Graduação em Teste e Qualidade    de Softwarehttp://testeequalidadedesoftware.com
Referências
<trollagem>
Um típico implementador    de POG convícto
1°encontro dosimplementadores de POG      convíctos
Projeto entregue pelosimplementadores de POG      convíctos
Um dia típico de trabalho de um implementador de POG convícto
Implementadores de POG convíctos   também trabalham em equipe
Um implementador de POG convícto     não tem medo do perigo
Um implementador de POG convícto    assume que boas práticas,      princípios e padrões        é tudo um VIAGEM
Por algummotivo oserros se repetem
</trollagem>
Code Smell
Baixa coesão               e       Alto acoplamento são um dos fatores fundamentais   para aumentar a dependência,dificult...
1° Code Smell
Rigidez“O sistema é difícil de mudar, porque cada vez que você muda alguma coisa, vocêtem que mudar alguma outra coisa em ...
2° Code Smell
Fragilidade“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes,                           ...
3° Code Smell
Imobilidade“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”
4° Code Smell
Complexidade              Desnecessária“Há muitas estruturas de código muito inteligentes que não são necessárias agora, m...
5° Code Smell
Repetições                     Inúteis“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”
Mostra aí como combater esse tal de Code Smell
Qualidade de Código    boas práticas,     princípios e      padrões.
Início          Teste         unitário                                           Princípios de                            ...
Desenvolvimento Dirigido pelos Testes
Programação em Par
Refatoração
Substitua Herança por DelegaçãoExemplo: pilha subclasse de vetor.Class MyStack extends Vector {    public void push (Objec...
Refatorando...Crio campo para superclasse.Class MyStack extends Vector {   private Vector _vector = this;   public void pu...
Refatorando...Removo herança.Class MyStack extends Vector {   private Vector _vector = this; new Vector ();   public void ...
Acoplamento e Coesão  DiminuirAcoplamento          Aumentar           Coesão
Programação Orientada a Objetos                          Abstração                       Encapsulamento                   ...
Princípios de Projeto                 •Restrição ao Acesso           •Prefira a composição à herança            •Programaç...
S   ingle Responsibility Principle (SRP)O   pen/Closed Principle (OCP)L   iskov substitution principle (LSP)I   nterface S...
Princípios de Projeto OO – Single Responsibility Principle (SRP)    "Nunca deve haver mais de um motivo para uma classe se...
Violação do princípio:  Considere a Classe TAD
Adequação ao princípio:
Princípios de Projeto OO – Open/Closed Principle (OCP)“As entidades devem estar abertas para extensão, mas fechadas       ...
Violação do princípio:Considere o método para calcular o preço total de peças:   public double totalPrice(Part[] parts){  ...
Violação do princípio:O que ocorrerá se a empresa decidir cobrar um preço adicional por                          certas pe...
Adequação ao princípio:Considere novamente o método totalPrice original   public double totalPrice(Part[] parts){     doub...
Adequação ao princípio:public class Part{   private double basePrice;   public void setPrice(double price){              b...
Princípios de Projeto OO – Liskov substitution principle (LSP)“Funções que usam objetos de uma superclasse devem ser capaz...
Princípios de Projeto OO – Interface Segregation Principle (ISP)        “Interfaces mais específicas melhor que interface ...
Princípios de Projeto OO – Dependency Inversion Principle (DIP)   “Módulos de alto nível não devem depender de módulos de ...
Padrões de Projeto
Padrões Arquiteturais   De acordo com oscondutores arquiteturais
Atender ao negócio    Usuário FelizNecessidade atendida    $$$$$$$$$
@edgarddavidsonhttp://edgarddavidson.com
qualidade de código: boas práticas, princípios e padrões
qualidade de código: boas práticas, princípios e padrões
Próximos SlideShares
Carregando em…5
×

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

5.827 visualizações

Publicada em

Publicada em: Tecnologia, Saúde e medicina

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

  1. 1. Qualidade de Código: boas práticas, princípios e padrões. @edgarddavidson http://edgarddavidson.com
  2. 2. Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis http://engenhariadesoftwareagil.com
  3. 3. Curso de Pós Graduação em Teste e Qualidade de Softwarehttp://testeequalidadedesoftware.com
  4. 4. Referências
  5. 5. <trollagem>
  6. 6. Um típico implementador de POG convícto
  7. 7. 1°encontro dosimplementadores de POG convíctos
  8. 8. Projeto entregue pelosimplementadores de POG convíctos
  9. 9. Um dia típico de trabalho de um implementador de POG convícto
  10. 10. Implementadores de POG convíctos também trabalham em equipe
  11. 11. Um implementador de POG convícto não tem medo do perigo
  12. 12. Um implementador de POG convícto assume que boas práticas, princípios e padrões é tudo um VIAGEM
  13. 13. Por algummotivo oserros se repetem
  14. 14. </trollagem>
  15. 15. Code Smell
  16. 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. 17. 1° Code Smell
  18. 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. 19. 2° Code Smell
  20. 20. Fragilidade“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes, completamente alheios.”
  21. 21. 3° Code Smell
  22. 22. Imobilidade“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”
  23. 23. 4° Code Smell
  24. 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. 25. 5° Code Smell
  26. 26. Repetições Inúteis“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”
  27. 27. Mostra aí como combater esse tal de Code Smell
  28. 28. Qualidade de Código boas práticas, princípios e padrões.
  29. 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. 30. Desenvolvimento Dirigido pelos Testes
  31. 31. Programação em Par
  32. 32. Refatoração
  33. 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. 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. 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. 36. Acoplamento e Coesão DiminuirAcoplamento Aumentar Coesão
  37. 37. Programação Orientada a Objetos Abstração Encapsulamento Reuso Herança Polimorfismo
  38. 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. 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. 40. Princípios de Projeto OO – Single Responsibility Principle (SRP) "Nunca deve haver mais de um motivo para uma classe ser alterada"
  41. 41. Violação do princípio: Considere a Classe TAD
  42. 42. Adequação ao princípio:
  43. 43. Princípios de Projeto OO – Open/Closed Principle (OCP)“As entidades devem estar abertas para extensão, mas fechadas para modificação”
  44. 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. 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. 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. 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. 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. 49. Princípios de Projeto OO – Interface Segregation Principle (ISP) “Interfaces mais específicas melhor que interface de propósito diversos.”
  50. 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. 51. Padrões de Projeto
  52. 52. Padrões Arquiteturais De acordo com oscondutores arquiteturais
  53. 53. Atender ao negócio Usuário FelizNecessidade atendida $$$$$$$$$
  54. 54. @edgarddavidsonhttp://edgarddavidson.com

×