I am pretty sure that most of the times, us developers have heard the following line from some senior personal “Why don’t you code it clean the first time”. Well in fact I have heard this many times as a developer and have told this to my juniors many times as well.
But when you dig deep, you begin to ask your self, Is there anything called coding clean these days. With the business demands, systems evolving, pressure to fix or develop faster etc… we as developers are tide down to quickly hash code and release! in fact all these new Agile methodologies and time boxed sprints are not making it any more easier.
So how do we make sure that we keep our code maintainable, clean and effective… We use a simple term called “Code Refactor”.
So what really is refactoring…
“Code refactoring is a “disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”,[1] undertaken in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.” – Wikipedia
With this in mind following are some key points that convinced me why code refactoring is a must in software development
- I cannot be Agile if my code is not clean. Because I can not respond to change fast if my code sucks.
- No one can write good code in one sitting, there should be several iterations. Each iteration cleans the code.
- Code is there to be read and understood. We read code more then we write.When pushed with tight deadlines it is not possible to write clean code. So it’s better to write crappy code that works, then refactor to make it a great code.
- Managable and clean code has to have four characteristics and refactoring paves a way for that. The characteristics are
- Simple
- Clear
- Bravity (Keep your code small)
- Human readable then machine readable.
- Software change over time. Hence designs and architectures change. The code also needs to support these changes. Hence the code will always get changed.
- Your team depends on your code now and years in the future as well. So make it easy for the team by cleaning your code overtime.
- The easiest code to QA or manage is code that is not there. Cleaning code, reduced unwanted code. This leads to less QA and less maintenance.
- Finally, The code we write reflects us, leaving a cleaned code reflects our quality and who we are.
I hope the above shows why code needs to be cleaned continuously. The following are some tips when doing code refactoring that I normally try to follow.
- Refactor your code as soon as you write your code. Don’t wait till end of a sprint, six months down the line to refactor.
- Before doing any refactoring, first find a way to test what you refactor. Either find automated tests or build your own test for the area that you are refactoring. This could be unit, integration or functional tests. Never get into refactoring if you cannot test.
- Don’t try to refactor the code by making it clever, but by making it simple
- Refactor the code to be cohesive. This means that your code blocks should be doing independent work. Remove all dependencies as much as possible.
- Make your methods to one level of abstraction. This means code your methods to have one functionality, and drill down to inner methods for sub functionality.
- A method should always be fully visible within your screen. This means without scrolling up / down you should be able to read the full method. If a method cannot be read in one glance, then refactor the method again.
- When refactoring, always try to reduce code and not add code. Code that is not there create lesser bugs. For example remove duplicates, remove redundant code, take out unnecessary comments or logging etc…
- Checkin your code very frequently.
- Get help from a peer, to review your refactor.