Technical Debt and Refactoring
Technical Debt
A metaphor for programming decisions and actions that create liabilities which costs us later in time and extra work.
Where does debt come from?
Sources of Debt
- Quick and Dirty Solutions
- Not knowing the solution
- Not testing your code
- Experiments that become features
Quick and Dirty Solutions
- "We don't have time to do it right.
- "Let's see if people even use this first."
- "This works, I just went with it"
Not Knowing the Solution
- Don't always know the right solution
- How do we model the problem?
Not testing your code
- Manually verifying code doesn't scale
- Tests show usage and functionality
- Hard to make changes if it isn't tested
Experiments that become features
- Similar to some of the other ones
- Some times we need to validate hypothesis
Classifying Debt
Reckless
Creating crippling interest payments or lots of work to fix for future you or other developers.
Prudent
A conscious decision to move fast to get a release out or hit a deadline or maybe the code won't be touched again.
Inadvertant
Releasing code that you don't even know is debt, not knowing best practices or the right solution.
Deliberate
Knowing that you might want to change or clean up or redesign it later but ship anyway.
Technical Debt Quadrant
Dealing with debt
Not my problem
Good Debt
Manageable debt that we can deal with. Payments are manageable and isn't ballooning.
Bad Debt
Begins to effect developer productivity. Hard to keep up or make changes. Increased time and effort for simple changes.
Maybe it is our problem
- Eventually debt slows you down
- Rewrite but this takes a while
- Let's just add on to our code?
Refactoring
The let's pay down some debt.
Refactoring can help us
- Simplify existing code
- Tweak behavior to match new requirements
- Apply new things we've learned
Refactoring in Progress
Once we start to refactor we might not always make things better immediately. We might make things worse
Basic Refactoring Techniques
Reduce Class Sizes
Isolating and modifying classes to own less code.
Reduce Class Sizes
- Look at instance variables
- Look at methods
- Try to find responsibilities
- Break out responsibilities into new classes
Extract Method
Break up large methods into smaller ones.
Extract Method
-
Find a large method
-
Write a test that covers the method
-
Move a chunk to a new method
-
Call new method from large method
Questions?
Sources
- Martin Fowler Technical Debt and Technical Debt Quadrant
- Books:
- Working Effectively with Legacy Code
- Clean Code
Technical Debt and Refactoring
By Aaron Gunderson
Technical Debt and Refactoring
A talk for RCOS on 10/25/18 about technical debt and refactoring.
- 653