Clean Software Design

This the content that I shared at DevNot Summit 2017 conference. It mentions my ideas about clean software design.

Transcript

1. CLEAN DESIGN SOFTWARE LEMi ORHAN ERGiN agile software craftsman @ iyzico
11. code design process team management organization tests customer ux & ui culture office architecture infrastructure ux & ui meetings security
12. things smell… and if something smells bad, it means it is not clean
13. LEMi ORHAN ERGiN agile software craftsman @ iyzico /lemiorhan lemiorhanergin.com @lemiorhan agile practice lead at iyzico developing software since 2001 worked at Sony, eBay/GittiGidiyor, ACM consultant, architect, mentor, developer founder of Software Craftsmanship Turkey ex community leader of Agile Turkey meetup.scturkey.org agileturkey.org dev.iyzipay.com
14. 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?
15. 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
16. 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
17. Programming Source Code SOFTWARE DESIGN Automated Testing (Unit, Functional, etc.)
18. The very first value of so"ware is Robert C. Martin Author of Clean Code and Clean Coder Owner of cleancoders.com training site …
19. 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
20. 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
21. Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.)
22. Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.) Testing and Refactoring 
 are first class citizens of so"ware design Tests should pass Refactoring should be continuous
23. Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.)
24. Programming Source Code SOFTWARE DESIGN Refactoring clean? Automated Testing (Unit, Functional, etc.)
25. COUPLING When readfile() is changed, do you change writeFile() too? It shows how many places we need to change
26. 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
27. COHESION Do you search a lot where to change? It shows how easy to find the places we need to change
28. 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
29. Programming Source Code SOFTWARE DESIGN Refactoring Low Coupling High Cohesion Automated Testing (Unit, Functional, etc.)
30. Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion Refactor namings (how) mailer.useGmailSmtpSendEmail (what) mailer.sendEmail (why) mailer.sendActivationEmail Reveal what you are doing or why you are doing, not how you are doing
31. Refactor namings Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion manager handler helper utils facade service validator converter repository wrapper interceptor controller parser gateway generator dto, vo, entity Know what these really means
32. Split methods, Create new abstractions, Re-organize code Programming Source Code SOFTWARE DESIGN Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion Be aware of leaky abstractions. Do not expose details and limitations of its underlying implementation to its users that should ideally be hidden away.
34. Programming Source Code Refactoring Low Coupling High Cohesion Automated Testing (Unit, Functional, etc.) and Code Review Pair Programming
35. When code is reviewed, the design will be cleaner. Programming Source Code Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion and Code Review Pair Programming Pair prog makes you code cheaper due to spending less time in decision taking, bug fixing and debugging.
36. Find and remove duplications Programming Source Code Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion and Code Review Pair Programming It’s not about code duplication, it’s about knowledge duplication. Don’t repeat yourself. Every piece of knowledge should have one and only one representation.
37. Programming Source Code Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion and Code Review Pair Programming Keep it SMALL classes, interfaces, responsibilities, methods, modules, components… use design pa!erns wisely
38. Programming Source Code Refactoring Automated Testing (Unit, Functional, etc.) Low Coupling High Cohesion and Code Review Pair Programming these STOP Singletons? Sharing state Static & new keywords Framework slave coding Premature optimization Primitive obssession Huge upfront design Controling flows with exceptions or use them wisely
39. Programming Source Code Refactoring Low Coupling High Cohesion Automated Testing (Unit, Functional, etc.) and Code Review Pair Programming
40. LEMi ORHAN ERGiN agile software craftsman @ iyzico /lemiorhan lemiorhanergin.com @lemiorhan