�ݺ�ߣ

MOST VALUABLE SOFTWARE
DESIGN PRINCIPLES
REVISITED

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.

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.”

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?

THINKING AHEAD
• Analysis paralysis
• Framework on top of a framework
• Let’s put it in the config just in case

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.

YAGNI SELF-TEST
What if create a function that calculates the sum of 2 and 3. How would you
implement it?

YAGNI CONCLUSION
• Gain massive efficiency
• Not applicable when developing 3rd party libraries
• Must-have practice in software development

KISS
“Keep It Simple ��ٳܱ辱��”

KISS
“Keep It Simple ��ٳܱ辱��”
Advantages
- Make code more readable and understandable.
- Make code better maintainable.

KISS CHARACTERISTICS
Correctness, Performance, Readability
How would you arrange them by their importance?

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?

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.

“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.

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.

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.

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.

KISS CONCLUSION
• Removing unnecessary complexity improves productivity.

DRY
“Don’t Repeat Yourself”
- Elimination of repeatable code
- NOT about code duplication

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.

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.

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.

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.

FAIL FAST EXAMPLES
• Working with config files.
• Nulls without strict distinction between types that allow nulls and types that
don’t.

FAIL FAST CONCLUSION
• Confidence that your app is working correctly.
• Quickly be able to fix any problem.

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.

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

1. IDEAL
• The ideal situation

2. GOD OBJECT
• Result of high cohesion and high coupling
• Basically is a single piece of code

3. POORLY SELECTED BOUNDRARIES
• Has boundraries, only selected improperly

4. DESTRUCTIVE COUPLING
• Occurs when trying to decouple so much
that the code loses it’s focus.

COHESION AND COUPLING ON DIFFERENT LEVELS

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.

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.

�ݺ�ߣ

Most valuable software design principles

Recommended

More Related Content

What's hot (7)

Similar to Most valuable software design principles (20)

Recently uploaded (20)

Most valuable software design principles