PTR - Pause, Think, Refactor

programming   practices   methodology  

Regularly on LinkedIn, StackoverFlow and other similar sites I see people posing questions about applications architectures. Should I used MVP, MVVM, VIPER, LVC, etc? The same questions over and over about how to segregate the source code into classes, modules, or files in a way that is organised, easy to follow and plain makes sense. Which is best, which should I use, why should I use it?

Of course the pundits of any given architecture will tell you endlessly why their particular approach is the best and how all others are inferior. But I think they are all missing the point.

The art of writing good software is not about this API or that architecture, the patterns you’ve used, or if you’ve subscribed to whatever the latest fad development paradigm is. Whats more important is to realise that these are just tools you can add to your arsenal for developing code. Ideas, practices and experience to draw upon, selecting and choosing what’s appropriate.

Which ones you select for a job should match the context and requirements of the work at hand. Not the opinions of other people. Especially given the internet is a great medium for people who love to sound authoritative, but who couldn’t write an app to save themselves.

What’s actually is important is not which of the many architectures, practices and patterns you choose, but the self discipline you bring to the act of using them and writing your app’s code.

Which brings me to the title of this piece - Pause - Think - Refactor. These three things are the most important disciplines I know.

Pause

Too many times I’ve meet developers who never do this. They are constantly writing code. As soon as they get an idea of what is needed, they jump straight into their IDEs and start frantically typing away, cutting and pasting, hacking away without really taking the time to be clear about what they are trying to achieve.

They jump from section of code to section of code, switching files, scrolling up and down so fast you can barely keep up. They cut here, paste there, and if they are not sure about something, just throw some code in, saying something like “I’ll come back and fix that up later” as they madly jump off to another file to do the same.

They never stop, never pause, never think. The resulting code is usually over complicated, hard to follow, full of bugs and difficult to use. These guys often seem to be highly productive, yet the quality and usefulness of what they do is in fact very low.

This is why pausing is so important. Get into the habit of stopping periodically. Taking a breath and standing back from your code gives you the opportunity to assess both it, and where you are at with the project as a whole.

Think

The guys I mention above never pause and therefore they never think. Never ask themselves the questions that can save them and the project time and money.

Thinking about what you are doing is not just able working out how you are going to do something and which architecture or design pattern to apply. Thinking is about assessing where you are at, whether your previous decisions have been good ones, and whether you should continue with what you are doing.

Here’s some of the sort of questions I like to ask myself when I pause:

  • Does what I’ve just done feel complicated?
  • Does it feel like it’s working the way it should?
  • Have I used the APIs correctly?
  • Is it well written?
  • Will it work with the code I’m about to write?

It usually only takes a few seconds to ask yourself these questions. Sometimes you’re happy with the answers and can move onto the next thing you want to do. Sometimes your not.

If you’re not happy, you need to ask yourself one more question - What is it I don’t like about what I’ve done, and how can I fix it?

Refactor

This is the final part of the discipline. Having decided that something is not to your liking, it’s time to go back into the code and fix it.

You could tag it for later with a ‘TODO:’ comment or some such thing, and I’ll admit that sometimes I do that too. But mostly I don’t. There are many and varied reasons why, but it really just comes down to the fact that no matter what people say - all bugs, redesigns, refactors and hacked up solutions always grow with time.

On other words, the longer you leave them undone, the more time, effort and cost they are going to take to do them. It’s quite logical really. If you have a project with 2,000 lines of code which needs it’s service classes refactored. It’s logical that if you leave it until the project is 10,000 lines, that the refactor will involve considerably more work.

We’ve all seen projects where it’s obviously cheaper to kill the code base and start again than try to fix the issues. This is usually the result of not being aggressive about fixing things. Or just a bunch of lazy, non-thinking developers. ‘We’ll fix that later’ is something that is often said, and almost never done.

So PTR is my preferred discipline. Sure it’s not an architecture, or a pattern or anything even written about (until now perhaps). But it’s certainly the most effective tool in my arsenal.


Comments powered by Disqus