Date post: | 11-Aug-2015 |
Category: |
Technology |
Upload: | anders-laub-christoffersen |
View: | 610 times |
Download: | 1 times |
Changing requirements, support and hotfixes
generates technical debt
The impact of technical debt increase over time
The costs of adding new features increase over
time
Software rots
COST OF MAINTENANCE
5C
ost
Time
Changing requirements, support and hotfixes
generates technical debt
The impact of technical debt increase over time
The costs of adding new features increase over
time
Software rots
COSTS OF MAINTENANCE
6C
ost
Time
“Depend in the direction of stability” – Uncle Bob
A stable piece of code is one where its interface does
not change over time.
Code in a customer domain is expected to change
over time hence is less stable.
Instable code is not bad but a reality.
New requirements always occur in a domain
implementation
Design and layout are always instable
Instable code should always be easy to change or
even replace
STABLE DEPENDENCY PRINCIPLE
10
INSTABLE
FLEXIBLE
STABLE
“The dependencies between components must not
form cycles” – Uncle Bob
Enforced by Visual Studio between projects but still
possible
Not working with strict layering
Sitecore templates
Using the same field in several components
Misusing IoC containers
Textual dependencies
The devil lies in soft cyclic dependencies
ACYCLIC DEPENDENCIES PRINCIPLE
11
Component A
Component B
Component C
“The classes in a component is reused together. If you
reuse one of the classes in a component, you reuse
them all” – Uncle bob
EXAMPLE:
You need class A from component X in component
Y.
Class A relies on class B and C in the same
component
When class B or C changes so does class A
meaning that even though you only need class A
you are dependent on B and C as well
THE COMMON REUSE PRINCIPLE
12
THE COMMON CLOSURE PRINCIPLE (CCP)
“The classes in a component should be closed
together against the same kinds of changes. A
change that affects a component affects all the
classes in that component and no other components.”
– Uncle Bob
SINGLE RESPONSIBILITY PRINCIPLE (SRP)
“A class should have only one reason to change.”
– Uncle Bob
A class should only have one responsibility
THE COMMON CLOSURE PRINCIPLE
13
CCP is SRP on Component level
All classes within the same concept
that are likely to change for the same
reason should be in the same
component
WANT TO LEARN MORE? CONTACT…
Anders Laub ChristoffersenSitecore MVP, Junior Partner
http://laubplusco.net
@anderslaub
Pentia A/SZeppelinerhallen
Islands Brygge 55
2300 København S
25