Clean code - Dicas para escrever um código mais coeso

Transcript

2. Clean code: Dicas para escrever um código mais coeso Thiago Bomfim
3. Sumário •Design principles •Dos and Don'ts •Coesão e acoplamento
4. Design Principles Design principles 01
5. Design Principles 1. SRP 2. OCP 3. LSP 4. ISP 5. DIP 6. DRY 7. KISS 8. YAGNI
6. • Tolerante a mudança • Compreensível • Simples de ser testado • Fácil de ser mantido • Orgulho Design Principles Design Principles
7. Um prédio com boa arquitetura, mas com tijolos mal feitos não resultará numa boa construção. Por outro lado, mesmo com bons tijolos e arquitetura, caso a interligação entre os tijolos não seja de qualidade, a construção também não será satisfatória. Por isso que os princípios são de grande valia. Design Principles Design Principles
8. Design Principles Design Principles
9. Design Principles Design Principles
10. Design Principles Design Principles
11. Design Principles
12. SRP The Single Responsibility Principle 02
13. Reúna as coisas que mudam pelas mesmas razões. Separe as coisas que mudam por diferentes razões. SRP - Single Responsibility SRP
14. Cada módulo de software tem um, e apenas um, motivo para mudar. SRP - Single Responsibility SRP
15. SRP
16. OCP The Open-Closed Principle 03
17. Para sistemas de software serem fáceis de mudar, eles devem ser projetados para permitir o comportamento desses sistemas sejam alterados a adicionar novo código, em vez de alterar código. OCP - Open-Closed OCP
18. Um Módulo deve estar aberto para extensão, mas fechado para modificação. OCP - Open-Closed OCP
19. OCP
20. LSP The Liskov Substitution Principle 04
21. A famosa definição de subtipos de Barbara Liskov, de 1988. Em suma, este princípio diz que para construir sistemas de software a partir de partes intercambiáveis, essas partes devem aderir a um contrato que permite que essas partes sejam substituídas uma por outra. LSP - Liskov Substitution LSP
22. Um programa que usa uma interface não deve ser confundido por uma implementação dessa interface. LSP - Liskov Substitution LSP
23. LSP
24. LSP
25. ISP The Interface Segregation Principle 05
26. Este princípio aconselha os designers de software a evitar depender de coisas que eles não usam. ISP - Segregation Principle ISP
27. Mantenha os contratos pequenos para que os usuários não acabem dependendo de coisas que não precisam. ISP - Segregation Principle ISP
28. ISP
29. DIP The Dependency Inversion Principle 06
30. O código que implementa a política de alto nível não deve depender do código que implementa detalhes de baixo nível. Em vez disso, os detalhes devem depender das políticas. DIP - Dependency Principle DIP
31. Módulos de alto nível não devem depender de detalhes de baixo nível. DIP - Dependency Principle DIP
32. DIP
33. DIP
34. SOLID 07 SOLID
35. O Acrónimo SOLID foi cunhado nos anos 2004, identificado por Michael Feathers a possibilidade da criação desse Acrónimo com base nos princípios de diversos profissionais compilados pelo Robert C. Martin e apresentado por volta dos anos 2000s. SOLID SOLID
36. SOLID
37. SOLID
38. SOLID
39. DRY 08 DRY
40. Todo conhecimento deve ter uma representação única não ambígua e autorizada dentro de um sistema. DRY - Don’t Repeat Yourself DRY
41. O objetivo do DRY é reutilizar o código já escrito anteriormente. DRY - Don’t Repeat Yourself DRY
42. DRY
43. KISS 09 KISS
44. A simplicidade deve ser um objetivo chave no design, e a complexidade desnecessária deve ser evitada KISS - Keep It Simple, Stupid KISS
45. O princípio do KISS afirma que as coisas funcionam melhor se forem mantidos simples em vez de complicados. KISS - Keep It Simple, Stupid KISS
46. KISS
47. KISS
48. YAGNI 10 YAGNI
49. Sempre implemente as coisas quando você realmente precisa delas, nunca quando você apenas prevê que precisa delas YAGNI - You Ain’t Gonna Need It YAGNI
50. Tem como objetivo apagar todo o código desnecessário e se concentra nas funcionalidades atuais. YAGNI - You Ain’t Gonna Need It YAGNI
51. YAGNI
52. YAGNI
53. Dos and Don'ts Dos and Don'ts 11
54. ❌ "date.sum(1);" Escreva nomes significativos Dos and Don'ts ✅ "date.sumDay(1);"
55. ❌ Escreva métodos pequenos Dos and Don'ts
56. ✅ Escreva métodos pequenos Dos and Don'ts
57. Mantenha seu código com apenas uma responsabilidade Dos and Don'ts ❌
58. Mantenha seu código com apenas uma responsabilidade Dos and Don'ts ✅
59. Não inclui linhas de comentário em seu código para explicar o código Dos and Don'ts ❌
60. Não inclui linhas de comentário em seu código para explicar o código Dos and Don'ts ✅
61. Não inclui linhas de comentário em seu código para explicar o código Dos and Don'ts ✅
62. Não crie valores mágicos Dos and Don'ts ❌
63. Não crie valores mágicos Dos and Don'ts ✅
64. Evite múltiplos argumentos Dos and Don'ts ❌
65. Evite múltiplos argumentos Dos and Don'ts ✅
66. Evite complexidade Dos and Don'ts ✅ ❌
67. Coesão e acoplamento Coesão e acoplamento 12
68. Baixa coesão significa que o sistema não possui uma estrutura clara, na qual classes e módulos possuem múltiplas responsabilidades e estão fortemente acoplados, dificultando a compreensão e manutenção do código. Coesão Coesão e acoplamento botão
69. Coesão Coesão e acoplamento botão
70. Alto acoplamento significa que as partes de um programa estão muito misturadas e dependem muito umas das outras, o que pode causar confusão e dificuldade para fazer alterações. Acoplamento Coesão e acoplamento botão
71. Acoplamento Coesão e acoplamento botão
72. Alta coesão e um baixo Acoplamento Coesão e acoplamento botão Alta coesão: Classes com responsabilidades únicas Baixo acoplamento: Minimizar o número de dependências entre as classes.
73. Alta coesão e um baixo Acoplamento Coesão e acoplamento botão • Requer um design cuidadoso • Separação de responsabilidades • Abstração adequada para evitar dependências excessivas
74. Alta coesão e um baixo Acoplamento Coesão e acoplamento botão
75. Recapitulando Recapitulando 13
76. Recapitulando •Design principles •Design patterns •Dos and Don'ts •Coesão e acoplamento
77. Recapitulando • SRP - The Single Responsibility Principle • DRY - Don’t Repeat Yourself • DIP - The Dependency Inversion Principle • KISS - Keep It Simple, Stupid • Legibilidade
78. Referências Referências 14
79. Clean Code A Handbook of Agile Software Craftsmanship - Robert Cecil Martin. Recapitulando
80. The Clean Coder A code of Conduct for Professional Programmers - Robert Cecil Martin Recapitulando
81. The Pragmatic Programmer - Andy Hunt, Dave Thomas Recapitulando
82. Test-Driven Java Development - Viktor Farcic, Alex Garcia Recapitulando
83. Extreme Programming Explained - Kent Beck, Cynthia Andres Recapitulando
84. https://www.linkedin.com/in/thiagobfim/ https://github.com/ThiagoBfim Referências