Showing posts with label refactoring. Show all posts
Showing posts with label refactoring. Show all posts

09 September 2013

Making code cleaner can result in a angry phone call


You have just released a update of your product. It includes more or less nothing, just a minor bug fix and cleaner code. Tomorrow it will reached 10 million smartphone users. The next day your phone is calling, one hour before it normally wakes you up. Its your boss!

I recently read a blog post by Erik Dietrich about legacy code (http://www.daedtech.com/intro-to-unit-testing-5-invading-legacy-code-in-the-name-of-testability) and how refactoring can help you to make it testable. The articel (and it’s serie) is very vell written, and as he writes in a comment he aims for novices. With this post I want to change focus from correctnes to performance.

Refactoring

In several books and blogs you can read about clean code, reduce cymclomatic complexity, duplicate code and how refactoring can help you. And that works!

If its legacy code there will most of the time be a comment saying something that it shall be done with caution and you have to write unit tests before. Thats also great!

But what you don’t read (or very rare) is that you should profile the code before and after to spot any performance differences. Why? Consider this:

What do you think happens if you refactor a code snippet, that is used in one of your most CPU intense part?

It will take longer time!

A quick person will say that he will inline that code, either by function of through compiler flag.

Well...that sound good, but are you allowed to change a compiler flag?

And if it’s already there, do you know how large functions that will be inlined? Maybe a software architecture has decided he wants to have control of what is allowed to inline for several causes. It could be: controling final binary size, debugging issues or something else.

Jumping around takes time

What happens when you have refactored a code snippet, is making a jump to another place and do something there. This jump takes time. If you need to bring some parameters to this function, you have to store them in a register. And also the return adress. This takes time. If you need variables in the refactored function, you need to allocate memory for those. This takes time. And you have to jump back when you are finnished. And this takes time.

This itself isn’t a problem, but if it’s done milions of time in a part that is already highly loaded, it can be a problem.

A angry phone call

Even if you as a developer thinks the code looks cleaner and is easier to understand, you also need to understand the harware and your customer. Here is some senarios:

  • There might be requirements about how long time a task can take.
  • There might be limitation on how much of the cpu can be used before a wathdog generates an alarm, or in worst case reboots your system.
  • There might be a customer starting asking questions why his system use more CPU load after your software update.


Learning to ride a bike is easy, the hard part is to ride in traffic jam

02 May 2013

How much shall I refactor?


"disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior"
-       Martin Fowler

Usually refactoring is initialized by code smell, a piece of code that does what I shall do, but doesn’t look “good”. But it can be initialized by several other reasons and some of them are:

Readability – a code part is really complex and the context it’s in would be easier to understand if it’s replaced with a function. For example, calculating the mean value of an array:

Testability – by replace some part of the code with a function, writing test gets so much easier to do. The code you want to test is depending on a previous part and you need to control the output from it.

Reusability – by extracting and generalize some part of the code, it can be re-used in several other parts.

So whats the point with this post? What I listed above is nothing new. It has been said and written of thousands of people.

A few days ago I watched a video from Öredev with Oren Eini, Hard Coding - A Design Approach. The most interesting he points out is that after Gang Of Four released  Design Patterns, we have refactored and abstract code into so many layers that the code gets more complex and difficult to understand. Without good documentation and/or someone describing to you what the code actually does, time-to-understand-was-this-code-does has increased.

I don’t say that Design Patterns are bad. I like them. I use them. I do believe that they should be used with caution.

Back to the first question, how much shall I refactor? 

As long as the code gets easier to read, test and modify, you should always consider refactoring, but check that your performance don't gets worse.


KISS – Keep It Simple, Stupid!