Andela - Clean Code

Transcript

1. Clean Code & Clean Architecture Jeremy Appel
2. Who am I?
3. Who am I? • 20+ years of software engineering experience with B.S. in Computer Science and MBA from Ohio State University
4. Who am I? • 20+ years of software engineering experience with B.S. in Computer Science and MBA from Ohio State University • Worked in the Telecommunications, E- Commerce, and Financial industries
5. Who am I? • 20+ years of software engineering experience with B.S. in Computer Science and MBA from Ohio State University • Worked in the Telecommunications, E- Commerce, and Financial industries • Experience with distributed systems, cloud native, and mobile technologies
6. What is Clean Code & Architecture?
7. What is Clean Code & Architecture
8. What is Clean Code & Architecture • In all seriousness, I like to think about Clean code being concerned with the micro e.g. readability, naming conventions, comments
9. What is Clean Code & Architecture • In all seriousness, I like to think about Clean code being concerned with the micro e.g. readability, naming conventions, comments • While Clean Architecture is concerned with the macro, the relative composition of components and classes within a software system
10. What is Clean Code & Architecture • In all seriousness, I like to think about Clean code being concerned with the micro e.g. readability, naming conventions, comments • While Clean Architecture is concerned with the macro, the relative composition of components and classes within a software system • If only there was someone we could look to for an answer…
11. Good old “Uncle Bob” • Robert C. Martin, author of Clean Code and Clean Architecture • Founder of the Agile Manifesto • Advocate for Test-Driven Development • What does he think?
12. What does Uncle Bob say? • Well he does the same thing as me. He asks others.. • “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent, but is full of crisp abstractions and straightforward lines of control” - Grady Booch
13. What does Uncle Bob say? Cont’d • “You know you are working on clean code when each routine pretty much turns out to be what you expected. You can call it beautiful code when the code also make it look like the language was made for the problem.” - Ward Cunningham
14. What do I say?
15. What do I say? • I agree with both of these statements because they emphasize intent, clarity, and simplicity.
16. What do I say? • I agree with both of these statements because they emphasize intent, clarity, and simplicity. • We don’t program by ourselves: we are part of a team and others will work on your code as much as you do
17. What do I say? • I agree with both of these statements because they emphasize intent, clarity, and simplicity. • We don’t program by ourselves: we are part of a team and others will work on your code as much as you do • “Uncle Bob” mentions the “Boy Scout Rule” - leave things better than you found them
18. Let’s Dive into the Details • Let’s look “through the lens of the microscope” to analyze discrete practices for producing and maintaining clean code
19. Meaningful Names
20. Meaningful Names • Conveys intent
21. Meaningful Names • Conveys intent • Can be easily searched from within an IDE
22. Meaningful Names • Conveys intent • Can be easily searched from within an IDE • Can be easily pronounced
23. Meaningful Names • Conveys intent • Can be easily searched from within an IDE • Can be easily pronounced • Domain and Context aware
24. Functions/Methods
25. Functions/Methods • Small
26. Functions/Methods • Small • Single Responsibility
27. Functions/Methods • Small • Single Responsibility • No side effects
28. Functions/Methods • Small • Single Responsibility • No side effects • DRY Principle
29. Comments
30. Comments • Intent, clarity, and simplicity rule the day here too
31. Comments • Intent, clarity, and simplicity rule the day here too • Comments don’t absolve bad code
32. Comments • Intent, clarity, and simplicity rule the day here too • Comments don’t absolve bad code • Comments explaining non-intuitive code for performance reasons are a reasonable example
33. Code Style/Formatting
34. Code Style/Formatting • Very subjective, but pick a code style and stick with it
35. Code Style/Formatting • Very subjective, but pick a code style and stick with it • Reading inconsistently indented and formatted code is a mental drain
36. Code Style/Formatting • Very subjective, but pick a code style and stick with it • Reading inconsistently indented and formatted code is a mental drain • Invest the time in setting up a code style template for your IDE of choice and then distribute to the team via source control and use tools like Checkstyle to enforce it
37. Classes
38. Classes • Small
39. Classes • Small • Do only one thing and only one reason to change i.e. Single Responsibility Principle
40. Classes • Small • Do only one thing and only one reason to change i.e. Single Responsibility Principle • A useful heuristic that I use is to describe what a class does in a sentence. If I use And/Or, then the class does too much
41. Classes cont’d
42. Classes cont’d • Low Coupling and High Cohesion are critical qualities for classes when it comes to organizing a system as a whole
43. Classes cont’d • Low Coupling and High Cohesion are critical qualities for classes when it comes to organizing a system as a whole • Depend on things that change the least i.e. abstractions
44. Testing
45. Testing • So far we haven’t distinguished between new and legacy code
46. Testing • So far we haven’t distinguished between new and legacy code • How do we transform bad code into clean code? Think “Boy Scout Rule”
47. Testing • So far we haven’t distinguished between new and legacy code • How do we transform bad code into clean code? Think “Boy Scout Rule” • The only surefire way to transform bad code is to have tests that verify the behavior and invariants
48. Testing • So far we haven’t distinguished between new and legacy code • How do we transform bad code into clean code? Think “Boy Scout Rule” • The only surefire way to transform bad code is to have tests that verify the behavior and invariants • By having tests in place, we can employ stepwise refinement to improve the code
49. Clean Architecture
50. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion
51. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion • Fundamentally an architecture must support:
52. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion • Fundamentally an architecture must support: • The use cases and operation of the system
53. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion • Fundamentally an architecture must support: • The use cases and operation of the system • The maintenance of the system
54. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion • Fundamentally an architecture must support: • The use cases and operation of the system • The maintenance of the system • The development of the system
55. Clean Architecture • Now that we have focused on the micro and what practices we should follow to ensure that the low-level constructs are well- made, let’s step back and take a look at the bigger picture to ensure that they are assembled in a consistent, reinforcing fashion • Fundamentally an architecture must support: • The use cases and operation of the system • The maintenance of the system • The development of the system • The deployment of the system
56. Another quote • “Architecture represents the significant design decisions that shape a system, where significant is measured by the costs of change.” - Grady Booch
57. The Best of Both Worlds
58. The Best of Both Worlds • What I like about Grady’s quote is how he alludes to the goal of minimizing the cost of change
59. The Best of Both Worlds • What I like about Grady’s quote is how he alludes to the goal of minimizing the cost of change • Our job isn’t only to build software that meets the stated requirements, but to build it in such a way that it minimizes the effort and resources to maintain/change it in the future i.e. Behavior vs. Structure
60. The Best of Both Worlds • What I like about Grady’s quote is how he alludes to the goal of minimizing the cost of change • Our job isn’t only to build software that meets the stated requirements, but to build it in such a way that it minimizes the effort and resources to maintain/change it in the future i.e. Behavior vs. Structure • How do we achieve this?
61. Best Practices and Patterns
62. Best Practices and Patterns • There is a plethora of resources out there to help you become better software architects, too many to possibly mention here, and so we will touch on those that I feel have provided the most value to me
63. SOLID
64. SOLID • An acronym for five separate OO design principles that are widely established and practiced
65. SOLID • An acronym for five separate OO design principles that are widely established and practiced • “…SOLID principles tell us how to arrange the bricks into walls and rooms…” - Uncle Bob
66. SOLID • An acronym for five separate OO design principles that are widely established and practiced • “…SOLID principles tell us how to arrange the bricks into walls and rooms…” - Uncle Bob • Reminds us that all good software is layered and relies on composition, something we will revisit shortly.
67. SOLID cont’d
68. SOLID cont’d • Single responsibility principle - change for only one reason
69. SOLID cont’d • Single responsibility principle - change for only one reason • Open/Closed principle - classes open for extension, closed for modification
70. SOLID cont’d • Single responsibility principle - change for only one reason • Open/Closed principle - classes open for extension, closed for modification • Liskov Substitution principle - subtypes should be substitutable without altering correctness
71. SOLID cont’d • Single responsibility principle - change for only one reason • Open/Closed principle - classes open for extension, closed for modification • Liskov Substitution principle - subtypes should be substitutable without altering correctness • Interface Segregation Principle - prefer small abstractions over larger ones
72. SOLID cont’d • Single responsibility principle - change for only one reason • Open/Closed principle - classes open for extension, closed for modification • Liskov Substitution principle - subtypes should be substitutable without altering correctness • Interface Segregation Principle - prefer small abstractions over larger ones • Dependency Inversion Principle - depend only on abstractions
73. Components
74. Components • Next higher level of composition
75. Components • Next higher level of composition • A unit of deployment like jar, dll, or an assembly in .NET
76. Components • Next higher level of composition • A unit of deployment like jar, dll, or an assembly in .NET • “..component principles tell us how to arrange rooms into buildings..” - Uncle Bob
77. Components cont’d
78. Components cont’d • Common Closure Principle - combine those classes that change for the same reason and at the same interval
79. Components cont’d • Common Closure Principle - combine those classes that change for the same reason and at the same interval • Common Reuse Principle - don’t depend on things that you don’t use
80. Components cont’d • Common Closure Principle - combine those classes that change for the same reason and at the same interval • Common Reuse Principle - don’t depend on things that you don’t use • Component Dependency Principles
81. Components cont’d • Common Closure Principle - combine those classes that change for the same reason and at the same interval • Common Reuse Principle - don’t depend on things that you don’t use • Component Dependency Principles • Avoid dependency cycles at all costs
82. Components cont’d • Common Closure Principle - combine those classes that change for the same reason and at the same interval • Common Reuse Principle - don’t depend on things that you don’t use • Component Dependency Principles • Avoid dependency cycles at all costs • Depend on abstractions
83. Architectural Decisions
84. Architectural Decisions • Assess and provide means by which to decouple from the various dimensions that are involved: development, deployment, and operation
85. Architectural Decisions • Assess and provide means by which to decouple from the various dimensions that are involved: development, deployment, and operation • Like most software development/architecture, it is more art than science
86. Architectural Decisions • Assess and provide means by which to decouple from the various dimensions that are involved: development, deployment, and operation • Like most software development/architecture, it is more art than science • It boils down to how to balance/delay the decision making process as much as possible for those items which aren’t essential
87. Architectural Decisions • Assess and provide means by which to decouple from the various dimensions that are involved: development, deployment, and operation • Like most software development/architecture, it is more art than science • It boils down to how to balance/delay the decision making process as much as possible for those items which aren’t essential • At the end of the day, a proposed architecture should reveal the use cases of the system it supports
88. Conclusion
89. Conclusion • Like most things, the concepts and practices we have discussed take time to learn
90. Conclusion • Like most things, the concepts and practices we have discussed take time to learn • At first you will probably struggle how to balance the options that you have against your requirements.
91. Conclusion • Like most things, the concepts and practices we have discussed take time to learn • At first you will probably struggle how to balance the options that you have against your requirements. • Over time you will gain a feel for what decisions are the most important vs. those that can be deferred.
92. Conclusion • Like most things, the concepts and practices we have discussed take time to learn • At first you will probably struggle how to balance the options that you have against your requirements. • Over time you will gain a feel for what decisions are the most important vs. those that can be deferred. • Most importantly remember that it is incumbent on a software architect to be vocal with respect to the Structure of a system vs. the Behavior.