Lost Password?
Register now!
Page « 1 (2) 3 4 5 »
Articles : Refactoring
on 2007/9/17 23:34:47 (2748 reads)

Management are often unwilling to allow changes that will not give any immediate visible benefit, "If it ain't broke, don't fix it". As well, management may worry about the problem of introducing bugs to a system which has previously been thoroughly tested. This could happen, for example, when manually renaming a method where similarly named methods can be changed as well or methods overridden in a subclass are left with the original name. However, if refactoring operations do not pose a threat of introducing such bugs, management will be less reluctant towards letting refactoring proceed.

What exactly is refactoring?

Refactoring simply means "improving the design of existing code without changing its observable behaviour". Originally conceived in the Smalltalk community, it has now become a mainstream development technique. While refactoring tools make it possible to apply refactorings very easily, its important that the developer understand what the refactoring does and why it will help in this situation eg allow reuse of a repetitive block of code.

Each refactoring is a simple process which makes one logical change to the structure of the code. When changing a lot of the code at one time it is possible that bugs were introduced. But when and where these bug were created is no longer reproducible. If, however, a change is implemented in small steps with tests running after each step, the bug likely surfaces in the test run immediately after introducing it into the system. Then the step could be examined or, after undoing the step, it could be split in even smaller steps which can be applied afterwards.

This is the benefit of comprehensive unit tests in a system, something advocated by Extreme Programming techniques. These tests, give the developers and management confidence that the refactoring has not broken the system, the code behaves the same way as it behaved before.

A refactoring operation proceeds roughly in the following phases:
* Detect a problem: Is there a problem? What is the problem?
* Characterise the problem: Why is it necessary to change something? What are the benefits? Are there any risks?
* Design a solution: What should be the "goal state" of the code? Which code transformation(s) will move the code towards the desired state?
* Modify the code: Steps that will carry out the code transformation(s) that leave the code functioning the same way as it did before.

Page « 1 (2) 3 4 5 »
Printer Friendly Page Send this Story to a Friend Create a PDF from the article