Code Refactoring in Agile: Best Practices
What is code refactoring?
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 effect of Technical debt:
- Causes delays and mistakes
- Requires significant additional effort to dev and support
- Lot of pressure lead to lot of mistakes in dev…leads to a vicious cycle.
- Misunderstanding causes mistakes and delays
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.
Bad code smells:
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
4 Reasons why developers are reluctant to refactor the code:
- Not able to understand the code and context
- It is not my ownership for this sprint. It is an additional overhead activity
- It might break the existing code and make me accountable for bugs
- Why should I alone care for it?
Best practices to adopt code refactoring:
- Create small functions, classes and methods which are easier to understand. The affected radius of change will be small when there is a change.
- Long methods / Parameter classes / big classes should be avoided
- Break the problem smaller so it takes a few mins. to resolve issues in code by understanding the code logic , code context and run tests frequently to get feedback with peer review and also use TDD/ BDD practices.
- Deep nesting due to poor coding to be avoided.
- Restructure a program to make it easier to add a new feature
- Use tools that can identify structural weaknesses in a program
Also, a while loop that takes a long time might impact the performance.
Reuse functions where ever possible
Clarity leads to understanding:
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.
Ask this question:
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-E-V-O-T-E:
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
Refactored code:
A readable code should tell a story
Agile helps with refactoring:
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.
Key Takeaways:
- Keeping the system clean is the only way we will pay down the debt
- With clean code, we will be able to refactor as we come to understand the problem.
- Makes code and design easy to understand and work with
- Increases confidence, eliminates fear, puts us in a pat of virtuous cycle
- A wise investment
- Refactor now while changes are still easy to make. As time goes by, code becomes hard and brittle. The long you delay, the harder it is to change code/design. Penalties get compounded over time
- Improves the design
- Helps to find bugs
“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
