Page 250 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes 12.1.6 Benefits of Refactoring
Refactoring can be used for quite a few purposes. First of all, refactoring helps the code to
retain its shape. Without refactoring the design of the program will decay. As people change
code (usually without fully understanding the design objectives behind the implementation) it
gradually begins to lose its structure. Once the structure gets cluttered, the code becomes harder
to understand and so the chances of cluttering the design further increase.
Refactoring makes your code more readable. This is essential for conveying the intention of the
code to others. It also makes the code easier to read for you. That is equally important since it
is unrealistic to assume that you can remember your intentions for more than few weeks.
We can also use refactoring to grasp the intention of unfamiliar code. When looking at a fragment
of code you try to understand what it does. When you find out how the code works, you refractor
it to better reflect your understanding of its purpose. After that you can test if the system still
behaves as it should. If everything goes well, you have understood and processed a part of the
system correctly. If not, you need to get a better understanding of the code fragment at hand.
The main advantage of refactoring is that it helps you develop software more quickly. It is rather
easy to believe that refactoring improves quality and readability of code, but how does it speed
up development? You would think that all modifications and iterative nature of refactoring, not
to mention the big effort put into testing, would make your development slow.
The secret is that adding new functions and finding bugs is very efficient when you work on
a system with a solid design you understand well. Without refactoring your system will begin
to decay from the very beginning. That is why it does not take long for the benefits of keeping
your implementation in line with the design to overweight the overhead of refactoring and
associated testing. If you ignore refactoring you end up very soon in a situation where you have
trouble inserting new functions because of unwanted and unexpected side effects. Similarly,
modifications will become harder because you begin to have instances of duplicated code.
12.1.7 Problems with Refactoring

Although very beneficial in many cases, refactoring is not always easy or even useful. For
example, systems based on database access (or persistency in general) are known to be hard to
change. Most business applications are very closely coupled to the database schema that supports
them making it hard to modify either the database or the system built on it. Even if you have
a sufficient layering separating the objects from the database, you are still required to migrate
your data when the database schema changes. Data migration is also a very familiar nuisance
for anyone who has ever tried to modify a Java application using serialization.
Changing an interface in an object-oriented system is always a major change when compared
to changing implementation. Unfortunately most refactoring change interfaces. This problem
is easy to deal with if you have access to the code that uses the changed interfaces you just
modify those parts too.
The problem is much more severing with published interfaces (i.e. interfaces that are used by
people outside your organization or by code that you cannot change). If you must refractor a
published interface, you should keep both the old and the new version (at least for some time)
and the old version should be tagged deprecated. These complications imply that you should
not publish your interfaces prematurely.
Sometimes you should not refractor a system to begin with. The most common reason for this
is that the system needs to be written again from scratch. This is usually due to the fact that the
system simply does not work and is so full of bugs that it cannot easily be fixed.

244 LOVELY PROFESSIONAL UNIVERSITY