The document discusses how to write maintainable software. It notes that software is difficult to maintain when (1) the intended audience of the code is not considered when writing it and (2) code is not refactored on a regular basis. It provides tips for improving maintainability such as focusing on the domain core, using explicit names and abstractions, avoiding unnecessary complexity, and refactoring code daily.

1. SoftwareSoftware
MantenibleMantenible
Carlos Blé
@carlosble

2. About meAbout me
Developer, Speaker, Author, Trainer, Entrepreneur
Founder of Lean Mind
Software Craftsmanhip Community Member
Brought SoCraTes to the Canary Islands
Co-founder of Agile Canarias & Agile Spain
@carlosble

3. @carlosble

4. Why is it hard to maintain?Why is it hard to maintain?
1 - Don’t consider your audience
when writing new code
2- Don’t refactor every day
@carlosble

5. Consider your audienceConsider your audience
Don’t aim for reusability
●
Accidental Complexity
●
Painful generalizations
●
Premature optimizations
Standards are not
enough
●
Frameworks, Three tiers, MVC,
MVP...
●
File per class, small code units, PR,
metrics
●
Linters, Compilers, Coding
standards
●
Quality Attributes
@carlosble
Explicit domain core
✔
Names and abstractions
✔
Avoid primitives
✔
Domain Driven Design
✔
Design Principles
✔
Tests as documentation
✔
Framework agnostic
✔
Database structure agnostic
Paradigms don’t solve
the problem either
●
Imperative, Declarative
●
Multi-paradigm

6. Domain at the coreDomain at the core
- yes! also in the front-end- yes! also in the front-end
@carlosble
input
Data
Store
output
Infrastructure:
- Controller
- Component
- Action
- ViewModel
- Dispatcher
DOMAIN CORE
Infrastructure:
- Repository
- Mapper
- Client
- DTO
- Mailer
3rd
party
system
output
Service
Entity
Value Object
Entity
Delivery
mechanism
Domain core doesn’t know the outer layers
(clean architecture: mind dependencies’ direction)

7. Example: Interaction-Driven DesignExample: Interaction-Driven Design
@carlosble
Image from Sandro Mancuso, author of IDD
https://dzone.com/articles/introducing-interaction-driven-design

8. You’re wrong anyway, refactor please!You’re wrong anyway, refactor please!
It’s about ROI
●
Avoid analysis paralysis
●
Small thoughtful changes keep the
project on the green field
●
We re-discover the business as we
work on it
●
Code is the single source of truth
Balance
●
Aim for decent quality, not
perfection
●
Technical debt under control
●
Proud of a well-done job
●
Control your optimism
@carlosble
Every day
●
Warm up reading yesterday’s
code, like a kata
●
Automatic changes with an IDE
●
Pair review, Pair programming
Pick your battles
●
The low hanging fruit
●
Refactor to understand the code
●
Discard your changes when
needed
●
Delete all the lines you safely could
●
If it works don’t touch it

9. Thank you!Thank you!
@carlosble