This is the sixth step towards gaining the Programming Enlightenment series. If you didn’t learn the fifth step, read it.
“Cities grow, cities evolve, cities have parts that simply die while other parts flourish; each city has to be renewed in order to meet the needs of its populace… Software-intensive systems are like that.” ~ Grady Booch
One thing true about code I’ve felt so far is there is no EXCELLENT code. The dynamic nature of software makes even the excellent of code subject to change, be it requirement changes or evolving of programming language.
Most of the time spent by developers is reading the code. When you start reading the code and feel discrepancies to what you have learnt so far, than you’d want to write something better, that’s Code Refactoring for you.
What is Code Refactoring?
Code Refactoring is the process of restructuring existing code — without changing its external behavior.
Why do Code Refactoring?
Need for Code Refactoring is because of the following reasons:
- Improve Code Readability.
- Reducing Complexity.
- Improve Code Coverage.
- Remove hidden bugs.
- Improving Scalability.
- Easier Code Maintenance.
How to do Code Refactoring?
There are various approaches to perform code refactoring. I’ve mentioned are few a must practices when Code Refactoring. I’d suggest everyone to pick up Clean Code Collection, Working effectively with Legacy Code and Refactoring : Improving the design of existing code. These are the best books by the best professional in the field.
Below are the things to consider before you refactor.
- Measure the strength of code-base by looking at the Test/Code coverage. This will help you understand the strengths and weakness and will give a safety island to work upon the refactoring.
- Refactoring should always be done in tandem with Test-Driven-Development.
- Avoid the temptation to rewrite everything. Even though code is ugly, it might be a tested, reviewed and hardened one. Throwing away and adding new might bring more wastage of time, effort to fix it.
- Make incremental changes. As the saying goes for making the git commits small, so does the refactoring changes. This will helps us to find bugs if any with ease.
- Ensure existing tests passes. After each iteration of the refactor, we should make sure that existing test passes and if the coverage isn’t sufficient we should write more test.
- Personal preferences shouldn’t get in the way. The way one styles or structures the code shouldn’t be the reason for doing refactoring.
- New technology is insufficient reason to refactor. Unless an analysis shows that new technology will result in significant improvements in functionality, maintainability or productivity, it is best to leave it as it is.
- Remember that humans make mistakes. Refactoring will not always guarantee to give new life to the code but an equivalent amount of chance to introduce errors.
- Follow boy-scout rule. Always leave the code cleaner than you have found, if not don’t make it messy.
TL;DR Give enough reasons to start refactoring. Refactoring is safe to do, when we have code coverage safety island.
Go to Fifth step.
Go to the Seventh path.
References:
- 97 things Every Programmer Should Know ~ Git Book
- 97 Things Every Programmer Should Know ~ Paperback
- How many lines of code programmer writes in a day ~ Quora
- Working effectively with Legacy Code ~ Michael Feathers
- Refactoring : Improving the design of existing code~ Martin Fowler, Kent Beck , John Brant, William Opdyke , Don Roberts , Erich Gamma
- Workflows of Refactoring ~ Martin Fowler
- Clean Code Series ~ Medium blog
