Transferir como PDF, PPTX
Carregado porKete Martins Rufino
Qualidade de código
O documento aborda a importância da qualidade de código, destacando problemas como baixa produtividade e aumento de bugs, e apresenta princípios de design como SOLID. Discute técnicas de refatoração e boas práticas de programação, enfatizando a unidade e coesão das classes. Também menciona a importância de testes unitários e do Clean Code para garantir a qualidade e manutenibilidade do software.
![Refatorando tudo! [Agile brazil 2017]](https://cdn.slidesharecdn.com/ss_thumbnails/agilebrazil2017refatorandotudo-170914160211-thumbnail.jpg?width=640&height=640&fit=bounds)
Qualidade de código
- 1. Qualidade de Código Alémdo Clean Code Kete Martins Rufino - CEJS Test Case - 2017
- 3. Porque é importante? -Difícil de manter - Desmotivação - Baixa produtividade - Entregas lentas - Mais Bugs - Menos confiança
- 4.
- 5. "Nunca julgue alguémcom prazo apertado" Milfont, C
- 6. "O CÓDIGO ÉO PROJETO"
- 8.
- 9. O.O - CLASSES - OBJETOS -HERANÇA - COMPOSIÇÃO - MÉTODOS - TIPOS DE DADOS - ENCAPSULAMENTO - POLIMORFISMO ABSTRAÇÃO REUSO EVITAR DUPLICAÇÃO
- 10.
- 11.
- 12.
- 13.
- 14. S : Singleresponsibility principle (Princípio da Responsabilidade Única) O : Open/closed principle (Princípio do Aberto/Fechado) L : Liskov substitution principle (Princípio da Substituição de Liskov) I : Interface segregation principle (Princípio da Segregação das Interfaces) D : Dependency inversion principle (Princípio da Inversão de Dependência)
- 15. COESÃO Uma classe deveter uma ÚNICA Responsabilidade Muitas interfaces específicas são melhores do que uma interface geral S : Single responsibility principle (Princípio da Responsabilidade Única) I : Interface segregation principle (Princípio da Segregação das Interfaces)
- 16. Classes devem sersubstituíveis por suas classes base. L : Liskov substitution principle (Princípio da Substituição de Liskov) Uma classe deve estar aberta para extensão e fechada para modificação O : Open/closed principle (Princípio do Aberto/Fechado) O.O
- 17. Dependa de umaabstração e não de uma implementação. D : Dependency inversion principle (Princípio da Inversão de Dependência) ACOPLAMENTO
- 18. GANG OF FOUR(GoF)
- 19. 1994 CATÁLOGO SOLUÇÕES 23 PADRÕES 2CLASSIFICAÇÕES: - PROPÓSITO - ESCOPO
- 21. Problema ● Bebidas ○ Cachaça ○Rum ○ Vodka ○ Tequila ● Adicionais ○ Limão ○ Refrigerante ○ Suco ○ Leite condensado ○ Gelo ○ Açúcar Cliente vende coquetéis. O preço varia de acordo com os ingredientes .
- 22. Problema ● Bebidas ○ Cachaça ○Rum ○ Vodka ○ Tequila ● Adicionais ○ Limão ○ Refrigerante ○ Sal ○ Leite condensado ○ Gelo ○ Açúcar Cliente vende coquetéis. O preço varia de acordo com os ingredientes .
- 23. ● Podem surgir combinaçõesnovas a qualquer momento ● Podem surgir adicionais novos a qualquer momento Problema ● O preço é calculado pelas combinações ● Princípio do Aberto/Fechado
- 24.
- 25.
- 26.
- 27. Arrumar a casa,sem perder funcionalidades
- 28. Como? 1. Identificar umBAD SMELL (mal cheiro) 2. Aplicar uma técnica de refatoração 3. Testar
- 29. Bad Smells 1. Códigoduplicado 2. Método longo 3. Classes grandes 4. Lista de parâmetros longa 5. Inveja de dados 6. Comandos Switch 7. Classe ociosa 8. ...
- 30. 1999 MARTIN FOWLER CATÁLOGO DETÉCNICAS MELHORAR O QUE JÁ EXISTE
- 31. Técnicas/Ferramentas 1. Extrair método 2.Subir método na hierarquia 3. Decompor condicional 4. Extrair Classe 5. Substituir parâmetro por método 6. Mover método 7. Internalizar classe 8. ….
- 32.
- 33. Testes unitários ● Maisconfiança ● Documentam ● Garantem qualidade ● Exigem baixo acoplamento ● TDD: não deixe pra fazer o teste depois
- 34. E o CleanCode?
- 35. 2008 ROBERT C. MARTIN SIMPLICIDADE Facilidadede Leitura Elegância
- 36. Capítulo 1 -Conscientização
- 37. Capítulo 2 a6 - Detalhes Nomes Significativos Funções Comentários Formatação Objetos e Estruturas de dados
- 38. Capítulos 7. Tratamento deErros - Exceções no lugar de códigos - Não use exceções genéricas - Não retorne null - Não passe null 8. Limites - Trabalhando com código de terceiros - O que testar/esperar - Evitar acoplar o código com o de 3ºs
- 39. 10 - 12.Princípio da Responsabilidade Única - Classes pequenas - Coesão - Padrões de projeto - Java Capítulos 9. Testes unitários - TDD - Testes limpos - Um assert por teste
- 40. Capítulos 13. Concorrência - Princípioda Responsabilidade Única - Testes 14 - 16. Estudos de caso - Exemplos bons e ruins 17. Odores e Heuristicas - Maus cheiros - Técnicas - Testes
- 41. Ou seja…. Elejunta tudo com exemplos práticos
- 42. Orientação a Objetos Padrões de Projeto Técnicasde Refatoração Principios de Design Alta Coesão Baixo Acoplamento Nomear coisas Testes Responsabilidade única
- 43.
- 45. Referências ● Clean Code:Clean Code: A Handbook of Agile Software Craftsmanship ● https://www.infoq.com/br/articles/clean-code-book-review ● https://brizeno.wordpress.com/category/padroes-de-projeto/decorator/