Code refactoring is not about improving application performance, making code secure, making major changes in the architecture. It is about improving the design of existing code without changing its external behavior. It is about focusing on creating design/code that is easy to understand and easy to change. Code smells should be addressed. Anything that makes designing/coding harder to understand or work with is a smell
Clean code is a standard. And to achieve this, we use design principles like SLAP, SOLID, DRY, KISS , etc.
“In our current understanding of software development, we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking”
– William Opdyke, don Roberts
The goal of refactoring is to make code/design easier to understand, easier to work with. We should be able to Read, Update, Test, Extend & Troubleshoot with ease.
Large class: More than 60 lines of code and too many instance variables
Long method: Endless delegation sequences and lots of parameters and temporary variables
Duplicate code: Same expression in two methods of the same class
Divergent change: one class is commonly changed in different ways for different reasons.
Comments: Leads to bad code
Long parameter list: Hard to understand, more test data to pass and more scenarios to test
Also, a while loop that takes a long time might impact the performance.
Reuse functions where ever possible
The development team have their own context in their mind and don’t translate it in code. The context goes away with him/her. When someone else works on the same code, he/she gets lost since the context behind the code is not clear. This puts the entire team in trouble.
That’s why BDD works. The 3 amigos – Tester, PO and the Developers collaborate and make sure they align with the understanding of requirements and what the program should be doing.
As the code gets clearer, we could see flaws in the design which we could not have done before.
If I come back to the code after a few months, will I be able to get the context of what I wrote and be able to understand the code in the same way as I do today?
Align on these 3 things
The rhythm of refactoring: Refactoring is key every day whenever you change code!
DEVOTE yourself to the code!
D – Delete big sections of comments in code. Use version control comments for this.
E – Extract & simplify high level methods
V – Vouch to use single level of abstraction always
O – Opt for TDD,BDD practices
T – Tests to be Automated
E – Express intent while naming
Example : Normal code
A readable code should tell a story
Story point estimation should include refactoring for every story.
Pairing helps to understand each other’s context and improves the design of the code. When 4 eyes inspect, this improves clarity, efficiency and developer motivation levels.
“In many ways, refactoring is like exercise and eating a proper diet. Many of us know that we
ought to exercise more and eat a more balanced diet. Some of us live in cultures that highly
encourage these habits. Some of us can get by for a while without practicing these good habits,
even without visible effects. We can always make excuses, but we are only fooling ourselves if we continue to ignore good behavior.”
Improving the Design of Existing Code – William Opdyke, don Roberts