"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!
No comments:
Post a Comment