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)

 

  1. no production code unless it is to make a failing unit test pass
  2. write no more of a unit test than is sufficient to fail
  3. 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!

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 :-)

@gregor_riegler

coding should be fun

By Gregor Riegler

Loading comments...

More from Gregor Riegler