We often hear software developers use the word refactor when talking about changing existing code. The word is used so loosely that doing just about any change is considered, incorrectly, a refactoring. Yes, to refactor means to change but not just any change; rather, refactoring entails a specific kind change to achieve a specific purpose.
"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written." -Martin Fowler
Or operationally, "refactoring is the process of turning dirty code into clean code while keeping unit tests passing." - Idj
(or what exactly does "improves internal structure" mean?)
We refactor to:
Easy, train and use your sense of code smell. The more you use it, the better it gets. Here are two common code smells:
Find more here.
Good. Start with two of the most common refactoring techniques:
Check out more here. Do exercises like this.
But most importantly, read the bible. Practice what you've read. Spread the word.
..so what is refactoring exactly?
Or operationally, "refactoring is the process of turning dirty code into clean code while keeping unit tests passing." - Idj
But why refactor?
We refactor to:
- to keep code readable, modifiable and easy to reason about
- to pay technical debt
- to reduce accidental complexity
- to go fast (by making change easy)
That's all well and good but how do we know when to refactor?
Find more here.
Okay, seems legit. We want to learn. What do we do?
Check out more here. Do exercises like this.
But most importantly, read the bible. Practice what you've read. Spread the word.
No comments:
Post a Comment