Download to read offline
Most valuable software design principles
- 1. MOST VALUABLE SOFTWARE DESIGNPRINCIPLES REVISITED
- 2. YAGNI “You aren’t gonnaneed 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 haveimplemented 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 thefoundation 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 • Analysisparalysis • Framework on top of a framework • Let’s put it in the config just in case
- 6. YAGNI ON BUSINESSLEVEL • 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 ifcreate a function that calculates the sum of 2 and 3. How would you implement it?
- 8.
- 9.
- 10. YAGNI CONCLUSION • Gainmassive efficiency • Not applicable when developing 3rd party libraries • Must-have practice in software development
- 11. KISS “Keep It SimpleStupid”
- 12. KISS “Keep It SimpleStupid” 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 aretwo 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 ESSENTIALCOMPLEXITY 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 • Ifyou 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 • Removingunnecessary complexity improves productivity.
- 21. DRY “Don’t Repeat Yourself” -Elimination of repeatable code - NOT about code duplication
- 22.
- 23.
- 24. DRY This version nowcomplies 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 UTILITYMETHODS 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 BOUNDEDCONTEXTS
- 27. DRY CONCLUSION • TheDRY 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 “Stoppingthe 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, LOWCOUPLING 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.
- 34. 1. IDEAL • Theideal situation
- 35. 2. GOD OBJECT •Result of high cohesion and high coupling • Basically is a single piece of code
- 36. 3. POORLY SELECTEDBOUNDRARIES • Has boundraries, only selected improperly
- 37. 4. DESTRUCTIVE COUPLING •Occurs when trying to decouple so much that the code loses it’s focus.
- 38.
- 39.
- 40. COHESION AND COUPLINGON DIFFERENT LEVELS
- 41. COHESION AND SINGLERESPONSIBILITY 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 COUPLINGCONCLUSION • 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.