My five mantras to write better Software

Raúl Ávila

Mantra

• “a sound, word, or phrase that is repeated by someone who is praying or meditating

• “a word or phrase that is repeated often or that expresses someone’s basic beliefs”

(Merrian-Webster)

Two questions

We have to pay maximum attention to our code

Improving the way we write code

1. Pair programming

2. Code reviews

3. Reading books

• Embrace main ideas as mantras

• Apply them consistently

• On a daily basis

1

Broken window theory

• “When a community tolerates minor examples of disorder (…) such as broken windows (…) people are more likely to commit more serious crimes”

Source: http://bit.ly/2ebQEgR

1. “Don’t leave broken windows”

As soon as you see a broken window…fix it!

But we have to deliver!

Two levels

1. Stop the world!

2. Next iteration

Examples

Inconsistent naming conventions

TODO comments

Unclear code formatting style

Commented out code

• Dead code

• Unused imports

• Ignored tests

• Unused dependencies

• Several dependencies to do the same thing

• No README file

• Unclear Git strategy

• Manual steps in deployments

• Unstable CI

Delivery practices

2

2. “Extract till you drop”

Short term memory

Between 5 and 9 items

Extract variables

Extract functions

Benefits• Extracting increases readability

• Indentation is reduced drastically

• Makes responsibilities arise

• Avoids big balls of mud

• Facilitates benchmarking

Not extracting

Extract classes

• When a function is hard to split (i.e. it has many parameters)…maybe it should be a class

• Or maybe two classes!

• More on this later

Extract packages

3

3. “Do one thing, do it well, and do it only”

(Single Responsibility Principle)

What is (or what defines) a responsibility?

It depends…

Functions

1. Its name describes accurately what it does

2. Such name does not have conjunctions (And / Or)

3. It does not have side effects

Classes

• Definition of class: “family of functions with a clear and well defined objective”

• This objective is the responsibility of the class

• Responsibility as a bunch of solutions to an actor

Actors / Roles

• Final user

• External systems

• Accountants / Stakeholders

• Software Architects

Classes and actors

A class must satisfy the needs of one actor, and that actor only

If we do more than one thing

• Lines of code will grow without control

• Share code between different responsibilities

• Heterogeneous collaborators

• Classes are difficult to test

• Our code will be very hard to change

How to do one thing

1. Testing (TDD)

2. Extracting

4

4. “Abstractions in code, details in data”

0 2 20 39

Id Name Address

Parsing a message

Benefits• More robust design, as there are more immutable

parts

• We can code without knowing all the details (defer details)

• Facilitates testing, as we can test the abstraction, not specifics

• Details that are likely to change are not spread out in the code, so it’s faster to find them

Get details out of your code!• Data structures (OK, still code :))

• Properties files / YAML

• Environment variables

• Datastores

• Configuration server

One exception

Tests

5

Failing test

Make it passRefactor

TDD

Failing test

Make it better

Make it work

Make it pretty

5. “Make it work, make it better, make it pretty”

My five mantras

1. Don’t leave broken windows

2. Extract till you drop

3. Do one thing, do it well, and do it only

4. Abstractions in code, details in data

5. Make it work, make it better, make it pretty

Questions?

Other mantras?

@_Raul_Avila

raul@raulavila.com