Post on 12-Apr-2017
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.
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?
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.
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.”
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?
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.
Check, then do, then announce
public void DoFoo()
{
// Check preconditions
// Do a foo
// Announce that a foo was done}
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.”)(