Refactoring
as a noun "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior"
as a verb "to restructure software by applying a series of refactorings without changing its observable behavior"
- Don Roberts’ Rule of Three: “the first time you do something, you just do it. Second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.
- The Process
- Make sure you have a solid test suite (safety net)
- Make it easy/cheap to run your test suite
- Do it in small steps, and run tests in between
- Before adding functionality (not while)
- Sometimes it’s easier/better to fully rewrite
- Naming
- Naming things correctly is an easy way to achieve better design
- “Intention revealing names”
- Renaming is a kind of refactoring
- Never hesitate to rename things to improve quality
- If you feel like you need to add a comment to explain what’s going on, maybe add a new method or rename a variable.
- Technical Debt
- What it is; when to accumulate it; when to pay it off
- Learn your code smells because they often point you to what needs refactoring
Live Coding Demo!
My goals for you
- Feel the difference between just hacking at your code and being methodical at your refactoring
- Feel the difference between adding functionality (don’t refactor) and refactoring (don’t add functionality)
- The feeling of confidence when you have a safety net of tests
References
- Refactoring Techiniques: The problem with this article is that it tries to explain too many patterns. You don’t need them all to begin refactoring. Start with the most common case, “extract Method” and build up your toolbox accordingly.
- Here’s a catalog of the classic Refactoring patterns.