Techniques that increased my productivity

Gregor Riegler

@gregor_riegler

Cost of software = ∑(Cost of all changes)

Cost of a change

  • Communication.
  • Essential complexity.
  • Accidental complication.

Refactoring

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

  • Remove clutter.

Refactoring

Clutter

  • Remove clutter.
  • Make code more expressive.
  • Make it simpler (KISS).
  • Remove cleverness (KISS).
  • Remove Duplication (DRY).

Refactoring

What refactoring is not

  • Rewrite.
  • Fixing bugs.
  • Changing behaviour.
  • Having non-working code for more than 3 minutes
  • Not being able to prove everything still works

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?

How?

  • Safety through fast unit tests.
  • Tiny steps in correct order.
    • Revert if stuck.

The Mikado Method

The Mikado Method

How?

  • Safety through fast unit tests.
  • Tiny steps in correct order.
    • Revert when stuck.
  • Don't mix structure- and behaviour-change.

You can only wear one hat at a time

How?

  • 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 !!

How?

  • 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.

Katas!

TDD (Test Driven Development)

 

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the failing unit tests.

But what if i am not allowed to?

Books

premature optimization is the root of all evil

-Donald Knuth

Defer decisions

Premature decisions are accidental complication.

  • Premature optimization (YAGNI).
  • Premature generalization (KISS).
  • Premature microservice-architecture (KISS).
  • Premature database migration.
  • Premature tech stack.

How?

Choose an architecture that allows you to defer decisions.

Happy World

Low level details

Dependencies

Happy World

Low Level Details

class OrderService

class OrderDao

class OrderService

interface OrderRepository

class InMemoryOrderRepository

DIP (Depdency Inversion Principle)

Avoidable change

What is avoidable change?

  • Corrective change (eg. bugfixing).
    • through miscommunication or human failure.
    • customer collaboration.
    • TDD leads to 40-80% less bugs.
  • Unused features.
    • Evolutionary design instead of BDUF.
    • Prioritize -> unimportant stuff last.
    • YAGNI.

Thank you for listening!

@gregor_riegler

Made with Slides.com