Writing maintainable code is not something that is easy to do. Not only is a pretty subjective, a lot of the techniques like Clean Code, SOLID and such can be misinterpreted resulting in unconstructive dogma. I've made it my career's goal to find a good balance between all those different patterns, principles, practices and guidelines. In this talk, I like to share you my own ideas on what it takes to write maintainable code. I'll talk about architecture, class design, automated testing and any consequences on your development process. If you care about your code, be there with me.

1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver

7. Isolated
Can I do this without affecting anything else?
Testable
Is it doing what it is supposed to do?
Traceable
Why did we do this?
Readable
What does it try do and how?
Discoverable
Where is this done?

9. Application

10. Application
Presentation Layer
Domain Layer
Data Layer

11. Application
Component ComponentComponent Component Component
Component Component Component Component
Component Component Component Component

12. Application
Functional Slice Functional Slice Functional Slice Functional Slice
Composition
Architectural boundaries
protected by PR expert
review
Each component
owns/exposes its
reference data
Does not
depend on
anything
except for
curated
shared APIs
Owns
schema and
storage
(may use
shared
database
abstraction)
DRY within
component,
not outside
May use an
internal
container
Event
Sourcing &
CQRS are
component-
specific
concerns
Does not
touch other
components
’ data
directly
Shared Services
Connects the
components and
serves as anti-
corruption layer
Only services you
really think should
not be duplicated
Designed according to
Dependency Inversion Principle
Covers
front-end
and back-
end
Component
is the scope
of unit &
integration
tests
Align folder
structure
with
boundaries
Defines the
contracts
for the host
as well as
any services
it exposes

14. No generic
interfaces
Hide the
“internals”
Composition
over
inheritance
Avoid
inheritance
Small and
focused
interfaces
Or delegates
Avoid bi-
directional
relationships
Design Patterns
“name” a common
solution
Internal/private
by default
First-class
collections
and
primitives

17. Long method
Not
immediately
clear what it
does
Magic
character
Deeply
nested “ifs”
Single entry,
single exit
Static mutable state
Magic key
Multiple dots
Magic keys
Single entry,
single exit
No idea what to do
if this fails
Encapsulates
concerns

19. Too much
coupling?
Clear
algorithm
(Still) static mutable
state
Name
captures the
purpose
Same level of
abstraction
Methods
ordered by
execution
(a.k.a. reads
like a book)

20. Magic string?
Should never
happen, but is a
valid path
Because
type is
obvious

21. Captures what it
tries to
accomplish
Captures what it
does

22. Pretty clear, right?
Not so clear on
Github Pull
Requests
Jetbrains Rider /
Resharper to the
rescue

23. Superfluous
documentation
Nice, but a bit too
much for a private
method?
The name is clear
enough, isn’t it?

24. using (var scope = new AssertionScope())
var depth = GetDepthOfObjectGraph();
var displayValue = GetDisplayValueOf(context);
var valueString = GetDisplayValueOf(context);
var dataType = row.GetColumnType(columnIndex);
var searchColumnsSql = BuildSearchColumnsSql(Columns);
var results = RunSearchQuery(searchColumnsSql);
var indexInSpan = 0;
var longIndexInSpan = 1;
Use explicit type if
type is relevant
What kind of
results?
Did the author
consider the
maximum size?
Use explicit type if
type is relevant
var

25. Too many fields?

26. Too many fields?

27. First-class collection

28. Well-named and
discoverable
UTC? Local?
Random?
Where is this
coming from?

31. Unstructured Manual
Testing
User Interface Tests
HTTP Tests
Integration Tests
Unit Tests
Any structured
tests should be
automated
Generic code is
tested separately
“Unit” =
(architectural)
boundary
Do not accept
unstable UI tests
Only for UI
scenarios we
can’t cover with
integration tests.
Only for non-UI
scenarios we
can’t cover with
integration tests.

32. Application
Functional Slice Functional Slice Functional Slice Functional Slice
Composition
Shared Services

33. Hide what’s not
important
Show what is
important
Only if you can’t
make them clear
otherwise
Use in-line literals
Crystal-clear
cause…
…and effect
Names that explain
the expected
functional behavior
But be careful with
base-classes
!DRY

35. git checkout master
git cob my-branch
git save
git amend
git amend
git undo
git commit –m “Some functional change”
git commit –m “Refactor something”
git commit –m “Deprecate something”
git commit –-fixup “Some functional change”
git rebase –i master

37. // SMELL a smell code description
// REFACTOR an idea for refactoring
// NOTE a comment explaining a part of the code

44. Quality
Definition of
Done
Work Breakdown
Design Log
Small PRs
Focused
Commits
Continuous
Refactoring
Review Speed
Review by non-
team member
Productivity
Natural Cause of
Refactoring
Review
Thoroughness
Traceability
Clean Source Control
History
Knowledge
Sharing
Tech Meetings
Red Hot
Developer
Readable Code
Good Unit
Tests

45. Dennis Doomen
@ddoomen
Dennis Doomen | @ddoomen | The Continuous Improver