Back to Basics

Simple, elegant, beautiful code.

Back to Basics

This is not the dinosaur talk.

Back to Basics

Sorry.

What are we trying to achieve? 1. Agility.

2. Sustainability.3. Happiness.

Agility is not about doing sprints

“But we do stand-ups! That makes us agile!”

“We need to get these stories into iterations so that our project manager can sign off on the project plan.”

“We do the Agile method here.”

“SCRUM.” Because backronyms are a thing.

Agility is not about doing sprints

Agility is the ability to respond rapidly to threat or opportunity.

Sustainability

… because the professionals go home on time*.

* Mostly.

Happiness

Self-evident, much?

What does this all have to do

with code?Show us some code

already...

//TODO Implement happiness

What does this all have to do with code?

★ Good development practices allow for both agility and sustainability. These, in turn, permit happiness.

★ Projects should not slow down when they get larger.★ New team members should be able to get up to speed

quickly.★ Teams should be able to scale effectively.★ People should enjoy what they do.

What is beautiful code?I’ll know it when I see

it...

1. Simple.2. Elegant.3. Expressive.4. Never, ever finished.

This is not beautiful.

Tell me: what is the reason for this class’s existence?

Now tell me: who hasn’t written code like this before?

Some quick no-brainers

There’s an app for that.

//TODO: Spot the sponsors

Use an IoC container

There’s a video about that.

Use a message bus

Introduce message brokerage early. It will save you pain.

There’s a video about that, too.

Log all the things

Logs are your friend.

Centralised logs are a better friend.

Centralised, correlated logs are your bestest friend ever.

There’s an app for that.

Monitor all the things

New Relic. Raygun. App Insights. Montastic. Pingdom. Seq dashboards. Consul. Plain old email.

Pick one. Pick them all. Then pay attention :)

Continuous delivery is a thing

When you find a bug in production, you need to be able to:

1. git checkout <that exact revision>2. git checkout -b hotfix-all-gone-wrong3. // fix the bug4. git add -A .5. git commit -m “Fixed the bug”6. git push

and then promote that build all the way to production.

Automation is your friend

* Builds should run on:

- every push to every branch- every single day.

* Automate your deployments.

- This includes your databases!- And your configuration transforms.

* Polish the F5 experience.

Some quick anti-patterns

Don’t automate the awful

Fixing something does not mean just automating it.

“Hey, all! I just wrote a JavaScript snippet to re-run all the failed pipelines.”

“We had too many manual deployment processes so I wrote batch files for all of them.”

“I put the test runners inside a loop.We run them up to ten times each before giving up.”

If your DBA makes your schema changes...

… you're doing it wrong.

Stored procs are so 1990s...

Flares belong in the 1970s.

Mullets? 1980s.

Stored procs are from the 90s.

Don’t ask about stonewashed jeans or flannel.

Let the exceptions throw

If you can handle it and continue, do so. Otherwise, you’re broken. Accept this. Move on.

Don’t string.Format(...) your exceptions. It makes them harder to group in the logs. Use the Exception.Data property bag instead. And log this.

Booleans are not your friend

if (!human.CanAcquirePet(pet)) throw new DomainException(“This human may not acquire a pet.”);

var reasons = human.CannotAcquirePet(pet);

if (reasons.Any()) throw new DomainException(“This human may not acquire a pet”).WithReasons(reasons);

Get inside the head of whoever

comes nextSmart me codes for stupid

me.

//It’s dark in here.

//TODO: Find a way out

//TODO: Make the voices stop!!!

//TODO: Show them some code already...

Beautiful code is a mindset

* What am I thinking when I write this?

* What will I be thinking when I read this?

Let’s look at some code

If trip over it you do, fix it you should.

* Don't set traps for yourself.

* Code should be easy to reason about.

* Don’t make me mentally parse irrelevant things.

* Explain what the code achieves, not how it does it.

* Ideally, don't even make me read it.

Your domain model should model your domain

Use your ubiquitous language wisely. It's very powerful.

Check, then do, then announce

public void DoFoo()

{

// Check preconditions

// Do a foo

// Announce that a foo was done}

Optimise your tests

1. Test by convention.2. Unit test.3. Integration test.4. UI automation.

Adding new features?

Just add code.

Aspect injection is your friend

Weave all the things!

Commenting a decision your code makes?

Consider logging it instead. Future you will thank past you.

if (minions.None()) return; // no minions. Can't take over the world.

if (minions.None())

{

}Log.Information(“No minions. Can't take over the world.”)(

Some final thoughts

What are we optimising for?

1. Agility.2. Sustainability.3. Happiness.

Thank you.