Technique for restructuring

I thought of making it as a separate topic on my blog site ,it’s due to my work almost around it most of the time.

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring. *Martin clearly stated as above

Refactoring lowers the cost of enhancements

When a software system is successful, there is always a need to keep enhancing it, to fix problems and add new features. After all, it’s called software for a reason! But the nature of a code-base makes a big difference on how easy it is to make these changes. Often enhancements are applied on top of each other in a manner that makes it increasingly harder to make changes. Over time new work slows to a crawl. To combat this change, it’s important to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of day-to-day programming

Refactoring isn’t a special task that would show up in a project plan. Done well, it’s a regular part of programming activity. When I need to add a new feature to a code base, I look at the existing code and consider whether it’s structured in such a way to make the new change straightforward. If it isn’t, then I refactor the existing code to make this new addition easy. By refactoring first in this way, I usually find it’s faster than if I hadn’t carried out the refactoring first.

Once I’ve done that change, I then add the new feature. Once I’ve added a feature and got it working, I often notice that the resulting code, while it works, isn’t as clear as it could be. I then refactor it into a better shape so that when I (or someone else) return to this code in a few weeks time, I won’t have to spend time puzzling out how this code works.

When modifying a program, I’m often looking elsewhere in the code, because much of what I need to do may already be encoded in the program. This code may be functions I can easily call, or hidden inside larger functions. If I struggle to understand this code, I refactor it so I won’t have to struggle again next time I look at it. If there’s some functionality buried in there that I need, I refactor so I can easily use it.

Automated tools are helpful, but not essential

When I thought of Refactoring, back in 2000, there were few automated tools that supported Refactoring. Now many languages have IDEs which automate many common refactoring. These are a really valuable part of my toolkit allowing me to carry out refactoring faster. But such tools aren’t essential – I often work in programming languages without tool support, in which case I rely on taking small steps, and using frequent testing to detect mistakes.

As a Programmer basically i like the Book Refactoring . Read more from this book .

I will add more in my upcoming posts..Keep Reading