Source: Refactoring to Patterns by Joshua KerievskyBy continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.
Refactoring is usually motivated by noticing a code smell. For example the method at hand may be very long, or it may be a near duplicate of another nearby method. Once recognized, such problems can be addressed by refactoring the source code, or transforming it into a new form that behaves the same as before but that no longer “smells.” For a long routine, extract one or more smaller subroutines. Or for duplicate routines, remove the duplication and utilize one shared function in their place. Failure to perform refactoring can result in accumulating technical debt.
There are two general categories of benefits to the activity of refactoring.
-
Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of its author is easy to grasp. This might be achieved by reducing large monolithic routines into a set of individually concise, well-named, single-purpose methods. It might be achieved by moving a method to a more appropriate class, or by removing misleading comments.
- Extensibility. It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed.
Before refactoring a section of code, a solid set of automatic unit tests is needed. The tests should demonstrate in a few seconds that the behaviour of the module is correct. The process is then an iterative cycle of making a small program transformation, testing it to ensure correctness, and making another small transformation. If at any point a test fails, you undo your last small change and try again in a different way. Through many small steps the program moves from where it was to where you want it to be.
Source: http://en.wikipedia.org/wiki/Code_refactoringYou should only refactor code that you have a reason to be modifying. Perhaps you are about to add a new feature and you would like to make an existing feature more abstract so that the new feature is easier to add. Perhaps you are about to fix a bug in a particular area of code. You will first need to spend some time understanding that code. Because you already have to spend time understanding and maintaining the code, use this as an opportunity to make it easier for the next person to understand and maintain. In doing so, not only will you make the task easier for the next person, but you will prove to yourself that you really do understand the code. You will reduce the overall technical debt and you will ensure your current task is done well.
Corollary – Tea and Sympathy rule
Source: http://en.wikipedia.org/wiki/Savage_Love#.22Campsite_rule.22“When you speak of this in future years – and you will! – be kind.”
Refactoring is part of teamwork. When you are refactoring, resist the urge to be frustrated with the original author of the code for creating the mess that you are cleaning up. The original code was the result of business pressures and limits of available knowledge that you may not be privy to. Look for the value that the code created in the first place and help to make it less costly. Refactoring is not a burden; it is simply part of the task that you’re now working on.
If your code gets refactored, don’t be offended. If you think the refactorer has made a mistake, discuss it with them. Be thankful that someone else has found the time that you did not have to make your code a little bit better. Code is never perfect, even when you think it is. No one expects you to have written perfect code. Try to learn from the refactoring to see a new way of approaching your future code. Refactored code may be refactored again later, so even this refactoring doesn’t have to be perfect.
