coding should be fun
Gregor Riegler
@gregor_riegler
expensive software is not fun
cost of software = ∑(cost of changes)
cost of a change
- communication
- essential complexity
- accidental complication
nobody gets the code right
on the first try
1. get it to work
2. make it right
3. make it fast (if you really have to)
for each change
the code is right, when it is
- working
- read with ease
- easily changeable
- as simple as possible
tradeoffs
you'll spend vastly more time
reading code than writing it.
this makes you a team player.
slow is the new fast
hurrying is not gonna get you anywhere.
getting it right will pay off.
when slow pays off
refactoring
A small change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
what refactoring is not
- changing behaviour (e.g. fix a bug)
- rewrite
- non-working code for more than 3 minutes
- not being able to prove everything still works
- remove clutter
refactoring
clutter
comment describes the what
clutter
comment describes the what
clutter
comment describes the what
clutter
clutter
clutter
commented out code
clutter
commented out code
clutter
unused code
clutter
unreachable code
- remove clutter
- make it expressive
refactoring
expressive?
lots of parameters
- remove clutter
- make it expressive
- make it simple
refactoring
accidental nesting
accidental nesting
accidental nesting
accidental nesting
- remove clutter
- make it expressive
- make it simple
- eliminate duplication
refactoring
duplication
careful! 35 changes for different reasons
when to refactor?
-
continuously.
-
prior to change (make the change easy).
-
after change (clean the kitchen).
- refactoring is not an item on the backlog!!
what to refactor?
what not to refactor?
code that is unrelated to your current work
tips for refactoring
- safety through fast unit tests
unit tests
-> enable refactoring
-> enables better design
-> enables easy changes
-> enable happy coders
tdd (test driven development)
- no production code unless it is to make a failing unit test pass
- write no more of a unit test than is sufficient to fail
- write just enough production code that is sufficient to pass the failing unit tests
tips for refactoring
- safety through fast unit tests
-
tiny steps in correct order
- revert when stuck
- don't mix structure- and behaviour-change
- trunkbased development
- tooling
tooling!
tooling !!
tips for refactoring
- safety through fast unit tests
-
tiny steps in correct order
- revert when stuck
- don't mix structure- and behaviour-change
- trunkbased development
- tooling
- pure functions & immutable objects
- deepest branch first
- practice, practice, practice
practice: katas!
-
GildedRose:
https://github.com/emilybache/GildedRose-Refactoring-Kata -
Tennis Refactoring Kata:
https://github.com/emilybache/Tennis-Refactoring-Kata - Trip Service Kata:
https://github.com/sandromancuso/trip-service-kata
But what if i am not allowed to refactor or write tests?
working on a green field is exciting.
but don't underestimate the lessons
a poor legacy code base can teach you.
Books
thank you for listening
and have fun coding :-)