Refactoring is improving the internal structure of software without changing its observable behavior. The purpose of refactoring is to make the software easier to understand and modify.
1. Why refactor?
- Refactoring can reduce technical debt
Refactoring makes the code clearer and easier to understand, making it easier for other programmers to maintain and add new features. Refactoring prevents us from spending too much time and effort trying to understand the system and find duplicate code.
- Refactoring improves software design
Without refactoring, the program design will rot. Refactoring is a lot like cleaning up code, and refactoring often helps code maintain its shape.
- Refactoring makes software easier to understand
When you start refactoring, the code may work, but the structure may not be ideal. But with a little time spent refactoring, you can make your code better express its purpose.
- Refactoring helps find bugs
Having a clear understanding of code structure through constant refactoring helps us find bugs quickly, which in turn helps us write better code more efficiently.
2. When to refactor?
Teams don’t have to spend large chunks of their time doing refactoring alone, or refactoring for refactoring’s sake; refactoring should happen all the time.
- Three rules
When we do something for the first time, we just do it, even if the code needs improvement.
The second time I do this, the code still needs to be improved, but it can still be done.
The third time you do something like this, start refactoring.
- Refactor when adding functionality
Refactoring helps us understand the code better when adding new features to the software. Also, when we find that the code design doesn’t allow us to add new functionality, we can compensate for it with refactoring. Refactoring enables new features to be added more smoothly and quickly.
- Refactor when fixing errors
The main purpose of refactoring during debugging is to make the code more readable and to help us find bugs. For example, when the system pops up an error report, this is a sign that we need to refactor, because the code is clearly not clear enough to find the Bug quickly.
- Refactor during code review
Refactoring helps us review other people’s code. Before refactoring, we can read and understand the code and make some suggestions. When there are new points, consider refactoring to implement them, which not only helps us make more appropriate suggestions, but also leads to more concrete results from code reviews.
3. Two hats
Kent Beck came up with the “two hats” metaphor. When using refactoring technology to develop software, first put on the hat to realize the function, with the aid of testing, quickly realize its function; Put on the refactoring hat and improve code quality by removing redundant code under the protection of testing.
Refactoring is not a silver bullet, and there is no silver bullet process or practice that will make a project work perfectly. You are welcome to learn more about extreme programming practices in previous extreme Programming videos.
More agile video address: www.zentao.net/page/colleg… /? from=upjuejin