Clean Software Design: The Practices to Make The Design Simple

These are the slides that I delivered during PHPKonf18 at Istanbul.

Transcript

1. LEMi ORHAN ERGiN co-founder @ craftbase CLEAN DESIGN SOFTWARE THE PRACTICES TO MAKE THE DESIGN SIMPLE
2. code design process team management organization tests customer ux & ui culture office architecture infrastructure ux & ui meetings security
3. things smell… and if something smells bad, it means it is not clean
4. Let’s talk about what is so!ware design and how we can build it clean
5. Jack W. Reeves The C++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf What is So"ware Design? https://medium.com/t%C3%BCrkiye/yaz%C4%B1l%C4%B1m-tasar%C4%B1m%C4%B1-nedir-cd8aad12c8ae Türkçe Çevirisi: Muhammed Hilmi Koca
6. Source code is the real so"ware design Designing so!ware is an exercise in managing complexity Jack W. Reeves What is Software Design? The C++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
7. The so"ware design is not complete until it has been coded and tested Testing is part of the process of refining the design Jack W. Reeves What is Software Design? The C++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
8. Programming Source Code SOFTWARE DESIGN ???
9. Programming Source Code Automated Testing (Unit, Functional, etc.) SOFTWARE DESIGN v0.1
11. The very first value of so"ware is Robert C. Martin Author of Clean Code and Clean Coder Owner of cleancoders.com training site …
12. to tolerate and facilitate on-going changes Robert C. Martin Author of Clean Code and Clean Coder Owner of cleancoders.com training site The very first value of so"ware is
13. Each city has to be renewed in order to meet the needs of its populace. So!ware-intensive systems are like that. Grady Booch Developed UML Wrote foreword to “Design Patterns” and “Technical Debt” books Istanbul, Turkey Credit: European Space Imaging
14. Testing and Refactoring 
 are first class citizens of so"ware design Tests should pass Refactoring should be continuous
15. Programming Source Code Automated Testing (Unit, Functional, etc.) SOFTWARE DESIGN v0.1
16. Refactoring Programming Source Code Automated Testing (Unit, Functional, etc.) SOFTWARE DESIGN v0.2
17. SOFTWARE DESIGN v0.2 Refactoring Programming Source Code Automated Testing (Unit, Functional, etc.) clean?
18. COUPLING When readFile() is changed, do you change writeFile() too? It shows how many places we need to change
19. public class CakeCooker { private Powder cakePowder; private Event event = new CookingEvent(); public void cook(Cake cake) { prepareIngredients(); int numberOfLayers = cake.getNumberOfLayers(); cakePowder = new BrownCakePowder(); float weight = cakePowder.getWeightUsed(); Egg egg = new Egg(); egg.crack(); cake.getChef().getCompany().registerEvent(event); } private void prepareIngredients() { // prepare ingredients here ... } } Don't talk to strangers Law of Demeter do not reach into an object to gain access to a third object’s methods 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 example of high coupling
20. No Dependencies Loosely Coupled Some Dependencies Tightly Coupled Many Dependencies
21. Two elements are loosely coupled if they are not shown in the same diff Kent Beck The creator of extreme programming One of the signatories of the Agile Manifesto Pioneered software design patterns and TDD
22. COHESION Do you search a lot where to change? It shows how easy to find the places we need to change
23. public class EmailMessage { private String sendTo; private String subject; private String message; private String username; public EmailMessage(String to, String sbj, String m) { this.sendTo = to; this.subject = sbj; this.message = m; } public void sendMessage() { // send message using sendTo, subject, message } public void authenticate(String username, String pass) { this.username = username; // code to login } } A cohesive module performs a single task within a so!ware procedure, requiring li#le interaction with the procedures being performed in other parts of the program 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 example of low cohesion
24. How many files at any one time is still open for edit shows the level of cohesion Nat Pryce Co-Author of Growing Object-Oriented Software Guided by Tests Early adopter of XP
25. Refactoring Programming Source Code Automated Testing (Unit, Functional, etc.) SOFTWARE DESIGN v0.2
26. Refactoring Low Coupling High Cohesion SOFTWARE DESIGN v0.3 Programming Source Code Automated Testing (Unit, Functional, etc.)
27. If people program solo, they are more likely to make mistakes, more likely to over design, and more likely drop the other practices, particularly under pressure. Kent Beck The creator of extreme programming One of the signatories of the Agile Manifesto Pioneered software design patterns and TDD — from book “XP Explained” by Kent Beck
28. Higher quality in code Faster in deployment* Faster defect removal Higher morale Be"er collaboration Shared knowledge Quicker to market Automatic code review Useful for training people Lower defect rates https://www.flickr.com/photos/fraserspeirs/3394902061 Joe O'Brien and Jim Weirich while doing ruby code review Benefits of Programming in Pairs
29. Refactoring Low Coupling High Cohesion SOFTWARE DESIGN v0.3 Programming Source Code Automated Testing (Unit, Functional, etc.)
30. Pair Programming and Code Review Refactoring Low Coupling High Cohesion SOFTWARE DESIGN v0.4 Programming Source Code Automated Testing (Unit, Functional, etc.)
31. The Principles of Clean So!ware Design
32. 1 tests pass Tests should always pass. If you can’t prove that your system works and does what it is required to do then it doesn’t really ma!er if your design is clean, simple or complex.
34. 2 code expresses intent Reveal what you are doing, not why you are doing or how you are doing (how) (what-generic) (what-specific) mailer.use_gmail_smtp_send_email() mailer.send_email() mailer.send_activation_email() Give great names. because you have to live with them forever
35. 2 code expresses intent manager handler helper utils facade repository wrapper interceptor controller parser service validator converter gateway generator Avoid using honeypot names a!racting behaviors and functionalities Give great names. because you have to live with them forever
36. 3 keep it small Less code is cleaner and maintainable. Keep your methods and classes small. I mean really small. The application shouldn’t have pieces that you don’t need. Delete the unused.
37. 4 do not repeat yourself Find and remove duplications. It’s not only about code duplication, it’s also about knowledge duplication. Every piece of knowledge should have one and only one representation.
38. 5 tame abstractions Align the level of abstractions. Do not expose details and limitations of its underlying implementation to its users that should ideally be hidden away.
39. 5 tame abstractions All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a li!le, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ Law of Leaky Abstractions
40. Singletons Meaning on Nulls Sharing state Static & new keywords Framework slave coding Composition over Aggregation Premature optimization Primitive obsession Huge upfront design Checked exceptions Stop, or use them wisely
41. tests pass code expresses intent keep it small do not repeat yourself tame abstractions 1 2 3 4 5
43. /lemiorhan lemiorhanergin.com @lemiorhan LEMi ORHAN ERGiN