Code Refactoring – once you meet it…
The world changes continously, just so software code should pass through changes too. Basically lifecycle is following:
- Prototype or simple model
- Design as skeleton
- Design refactoring
- Some stuff is implemented
- Refactoring should be done over new stuff
- Code and design are ready
- But code and design fit badly (inefficient memory management, resource leaks, security flows, unstable run, weak code support, improper interfaces and technologies, code smells…)
- Run new refactoring. Dangerous and nightmare as hard!
* This imagination from standpoint of refactoring only. Change requests, new features and bugs and emergency wishes can appear between any of listed steps! Some projects recursively call Step #1 along any Step #X. Better case if you enjoy a few iterations 4-5-4, 6-7-6 or 7-3-7
The tool for refactoring is refactoring 
The standard simple approach is to collect all code issues in defect tracker, assign to a proper player, come up with refactoring method, define expected results and benefits, estimate cost of fix and plan it. Once a refactoring item is ready – it should be tested inside and outside (Integration), unit tests (if exists) should give green (or rework them to meet with code changes). The last step is integration to production, QA testing and verification that “Refactoring is took place and results in expected out”
Usually refactoring is a step after code review or informal design/code inspection. The motivation to run refactoring should be as inside as outside, i.e. inside – when lead developer or architect initiate code review process and outside – when QA or customers or management have complains on product quality caused by bad design or coding.
Why refactoring is painful? Simply, more works done behind – more risks and potential affecting points on each refactoring item. And higher cost of refactoring. The same as for defects discovering and fixing – rate is continiously rising to production. Do you remeber this curve?
Consequently, frequent code review – less painful refactoring and less cost totally on refactoring. The general motivation of refactoring should be improve quality attributes of software, don’t be driven by this task as something fancy or trendy.
Now, it’s time for technical matter – some refactoring methods most used in industry. The good list of refactorings is listed here (http://www.refactoring.com/catalog/). The list is clearly complicated and easy to understand for those who are familiar with refactoring and coding practices, almost all links show up briefly meaning and how to apply with code excerpts and or UML diagrams. Most of the items can be fit and applied to automated testing either your code in scripting languages or real object oriented languages.
Basically we can break down refactoring approached to 2 groups: running top-down and running down-top. The first presumes review and improvements from highest levels (architecture and design) lowering to lines of code. The second method – is vice versa. Refactoring is not only finding and fixing issues in code pieces, it’s also about designing proper patterns up to level of general architecture. Some time ago I made a post on patterns applied for automated testing 20 Essential design patterns for automated testing, however we can use it to revise the current design.