Maintainability

is often underrated because there are no quick wins

Maintainability

is when you open a project after six months and can make a commit under five minutes

Maintainability

- Locate what needs to be changed

- Changes to the smallest part

- Confidence that changes won't break the system

Size Matters

• No code is best code
• Small code is better
• Prevent big ball of mud (God Object)

Size Matters

• Limit number of properties / collaborators
• Limit Method size to 3-5 statements
• extract private method for complex statements 
• Limit class to 3-5 methods 
• Smaller classes, smaller methods, smaller modules

Packaging matters as well

• Limit package to reflect business functionality
• `com.foo.controllers` `com.foo.model`  is bad
• `com.foo.users` good

Packaging matters as well

• Create smaller modules
• With clear public API
• use module exports (java 9+)

Write Tests

Preferably First...

When code is fresh

Write Tests

Test that don't run continuously are useless

Write Tests

To mock or not ...

is subjective

Write Tests

but a bad test now is better than good test later

Good Tests

Fail

Kill three layers

Kill 'em all

• DAO
• DTO
• *Service classes
• *Controller
• *Entity

Kill 'em all

• Util
• Helper
• Manager

There is Domain

There are adapters

persistence is special adapter


We depend on them to function well
Wrap calls with Logs, Metering and Circuit Breakers

There are delivery mechanisms

this is what our clients use to call us

A/B test here,
Canary here,
Rate limiting here,
Auth here

There are Libraries

Isolate IO

Via Interfaces

Everything that depends on IO is bound to fail

• cannot be trusted
• cannot be tested
• cannot be fast

What is IO

• FileSystem
• Database
• Network
• System...

Time is IO

• system.currentTimeMillis() is Evil

Summary

Test Domain Logic in Isolation

Isolate Domain from frameworks and IO

Smaller units are more maintainable

Resources

The way of testivus

SOLID principles

Hexagonal Architecture

Follow 12 Factor App