Why coding one thing at a time makes sense


Posted on April 13, 2017 - 22:24



Breaking app code up into functional chunks makes sense because it results in clean code. It's not easy, though.

Coding one piece of functionality in one unit of code makes sense. It's best practice in agile development, in fact. It's not always an easy rule to follow, though.

We all use frameworks these days don't we? Writing native code is like cycling without wearing a helmet. Liberating, but also hazardous.

The controller and model classes form the heart of our apps. So the do one thing and do it well concept for each class is a high but valuable aim.

Clean coders insist on it.

There are a few other guidelines too. Such as:

Splitting methods with conditional statements into separate actions is a good idea.

And:

Breaking up methods that grow longer than 20 lines also seems plausible.

When you read stuff like that in isolation, it sounds like a severe case of stating the bleeding obvious.

Here's another one:

A class should look after one core piece of core functionality. Methods in that class should handle one aspect.

It's great advice. But implementation is a bit harder than it first suggests.

While we are talking about rules, here are a couple that make sense:

  1. The do one thing rule helps to solve that problem.
  2. The single responsibility principle works well as a concept.

Coding concepts are great. But once again, seen in isolation, they can read like a great idea but putting them into practice is not so easy.

I like the modern framework way of identifying a resource. A single resource might be posts for your blog. So posts have controllers, models and views. While comments are a separate resource associated to posts.

Coding problems are often not neat an tidy. Time doesn't work in our favour. So we code to the best approximation of requirements.

Sometimes it ain't pretty. Refactoring the code is important. But there is never time.

I work in an agency. We get client requests coming in all the time. Even while we are still building and testing core functionality.

Factoring those into the build while sill working on other features is a recipe of failure. It doesn't always lead to failure of course. And that's part of the problem - if it did, we would change our working practices.

It seems to me that those high aims are worth fighting for. Tough as that may be. Clean code is maintainable code and that is a valuable end goal.

Search

Stuff I go on about

Random Haiku

I ran miles and miles,
I ran until the chafing
Made my arse fall off.