Most valuable software design principles
- 1. MOST VALUABLE SOFTWARE DESIGN PRINCIPLES REVISITED
- 2. YAGNI “You aren’t gonna need it” Advantages: - Don’t end up investing time and money in stuff you don’t need. - Don’t increase the total cost of owning your code base. - Save loads of time by not writing code. - Boost your productivity.
- 3. THINKING YAGNI “I have implemented the AddCommentToPhoto method. I guess I also need to create an AddCommentToAlbum function. Although we don’t need it right now, I bet we’ll need it in future if we decide to allow users to comment their photo albums.” “I’ve finished the CanonizeName method on the Album class. I think I’m better off extracting this method in a utility class because, in future, other classes might need it too.”
- 4. THINKING YAGNI Laying the foundation for a functionality that we don’t need right now and might need in future almost never pays off, it’s often a waste of time. Ask yourself: is the method/class/feature I’m going to implement really required right now? Or do you just assume it will be at some point in the future?
- 5. THINKING AHEAD • Analysis paralysis • Framework on top of a framework • Let’s put it in the config just in case
- 6. YAGNI ON BUSINESS LEVEL • Focus on what the current user needs right now, don’t try to anticipate what they might want in the future. • DEV: If you see a feature which is not needed right now, state it! • We don’t know what the real requirements are. If implemented now it’s most likely to change in the future. • Adding functionalty always adds maintainability costs. If you add the feature later when it’s needed it speeds up the development process.
- 7. YAGNI SELF-TEST What if create a function that calculates the sum of 2 and 3. How would you implement it?
- 10. YAGNI CONCLUSION • Gain massive efficiency • Not applicable when developing 3rd party libraries • Must-have practice in software development
- 11. KISS “Keep It Simple Stupid”
- 12. KISS “Keep It Simple Stupid” Advantages - Make code more readable and understandable. - Make code better maintainable.
- 13. KISS CHARACTERISTICS Correctness, Performance, Readability How would you arrange them by their importance?
- 14. KISS CHARACTERISTICS Correctness > Readability > Performance Is it better to have an unreadable application that does things correctly than an application with bugs and simple code? Yes, it’s better to have a flawless system. But what if you need to add or change something?
- 15. KISS CHARACTERISTICS Readability > Correctness > Performance If you are going to enhance your system, you are better off having one that is readable in the first case. Yes, bugs may occur at one point. But you will be able to fix it quicker with readable and simple code.
- 16. KISS CHARACTERISTICS “There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” – C. A. R. Hoare.
- 17. SIMPLICITY VS EASINESS • Easy solution does not take much effort to implement. At the same time, a simple solution is usually far more difficult to achieve. • It’s easy to create a complicated system that is hard to understand. • It’s easier to introduce technical dept than it is to remove it.
- 18. ACCIDENTAL VS ESSENTIAL COMPLEXITY Not all systems can be made easy to understand. Essential The problem that needs to be solved. Accidental The way developers try to solve the essential problem.
- 19. KISS IMPLICATIONS • If you need to choose between two solutions, choose the simpelest one. • Constantly work on simplifying your code base. • The simpler your solution is, the better you are as a developer “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery.
- 20. KISS CONCLUSION • Removing unnecessary complexity improves productivity.
- 21. DRY “Don’t Repeat Yourself” - Elimination of repeatable code - NOT about code duplication
- 22. DRY
- 23. DRY
- 24. DRY This version now complies with the DRY principle. Or does it not? Was there really a single piece of knowledge spread across these entities? Can it be that two classes have identical parts yet still don’t break DRY? Yes. The DRY principle restricts the presence of domain knowledge, it doesn’t put any bounds on the actual code which is required to express that knowledge.
- 25. DRY AND UTILITY METHODS If DRY forces us to keep domain knowledge in a single place, what about code that doesn’t contain any? No, DRY principle is about knowledge that is essential to your domain. Utility methods don’t contain such knowledge.
- 26. DRY AND BOUNDED CONTEXTS
- 27. DRY CONCLUSION • The DRY principle is about domain knowledge. • Don’t confuse DRY with just getting rid of code repetition. • There are cases where duplication is perfectly fine.
- 28. FAIL FAST PRINCIPLE “Stopping the current operation as soon as any unexpected error occurs” Advantages - Shortens the feedback loop by quickly revealing all problems. - Confidence software works as intended. - Protects the persistence state.
- 29. FAIL FAST EXAMPLES • Working with config files. • Nulls without strict distinction between types that allow nulls and types that don’t.
- 30. FAIL FAST CONCLUSION • Confidence that your app is working correctly. • Quickly be able to fix any problem.
- 31. COHESION AND COUPLING: THE DIFFERENCE “Achieve low coupling and high cohesion” Cohesion Represents the degree to which part of a code base forms a logically single atomic unit. Coupling Represents the degree to which a single unit is independent from others.
- 32. HIGH COHESION, LOW COUPLING GUIDELINE • High cohesion: Keeping parts of a code base that are related to each other in a single place • Low coupling: Separating unrelated parts of the code base as much as possible. • Relates to: Seperation of Concerns
- 33. TYPES OF CODE
- 34. 1. IDEAL • The ideal situation
- 35. 2. GOD OBJECT • Result of high cohesion and high coupling • Basically is a single piece of code
- 36. 3. POORLY SELECTED BOUNDRARIES • Has boundraries, only selected improperly
- 37. 4. DESTRUCTIVE COUPLING • Occurs when trying to decouple so much that the code loses it’s focus.
- 40. COHESION AND COUPLING ON DIFFERENT LEVELS
- 41. COHESION AND SINGLE RESPONSIBILITY PRINCIPLE “Every class should have a single responsibility” Similar to highly cohesive code. Difference: High cohesion implies code has similar responsibilities, it does not necessarily mean the code should have only one.
- 42. COHESION AND COUPLING CONCLUSION • Cohesion represents the degree to which a part of a code base forms a logically single, atomic unit. • Coupling represents the degree to which a single unit is independent from others. • It’s impossible to achieve full decoupling without damaging cohesion, and vise versa. • Try to adhere to the “high cohesion and low coupling” guideline on all levels of your code base. • Don’t fall into the trap of destructive decoupling.
- 43. QUESTIONS?