Title: "Refactoring to Improve the Design of Existing Code"
Author: [US] Martin Fowler
Translator: Xiong Jie
Publisher: People's Posts and Telecommunications Press
1. Refactoring, the first case
Talk is cheap, show me the code. It has such a taste, let’s go to the code case first~
If you find yourself needing to add a feature to a program, and the code structure prevents you from doing so easily, refactor the program to make adding the feature easier, and then add the feature.
The case mainly deconstructs the statement function, Stract Method. Modern compiler IDEs support it.
"Any idiot can write code that a computer can understand. A good programmer is only one who writes code that a human can easily understand."
In most cases, the function should be placed in the object that belongs to the data it uses, Move Method.
Remove the temporary variable that does not change after receiving the result, Replace Temp with Query.
The switch branch may be processed in the corresponding class.
2. Refactoring principles
Refactoring (noun): An adjustment to the internal structure of software that aims to improve its comprehensibility and reduce its modification cost without changing its observable behavior.
Refactoring (verb): Use a series of refactoring techniques to adjust the structure of software without changing its observable behavior.
"Two hats": adding new features, and refactoring. When adding new functionality, you should not modify existing code, just add new functionality. By testing (and getting the tests to work), you can measure your progress. When refactoring, you can no longer add functionality, just improve the program structure. You should not add any tests at this point (unless you find something you missed earlier), and only modify tests when absolutely necessary (to handle interface changes).
- Refactoring Improves Software Design - Eliminates Duplicated Code
- Refactoring makes software easier to understand - Saying exactly what I want makes it easier for a second programmer to understand
- Refactoring helps find bugs - build stronger software
- Refactoring speeds up programming
The rule of three times (no more than three things, three refactorings):
the first time you do something, you can let it go; the second time you feel disgusted, but you can still do it; the third time you do similar things, you need to refactor.
- Refactor when adding functionality
- Refactor when fixing bugs
- Refactoring while reviewing code - pair programming
The two-sided value of the program:
1. What it can do for you today;
2. What it can do for you tomorrow.
Do not use speculative design, it is easy to completely collapse. Refactoring can make the program consistent behavior from beginning to end, and has the opportunity to add more valuable quality. If the use scenario of an intermediate layer is single, then the desire to expect polymorphism will be defeated, and it needs to be removed.
Refactoring can lead to a simpler design without loss of flexibility, which also reduces the difficulty of the design process and reduces the design pressure.
3. Bad code smell
You have to develop your own judgment and learn to judge how many instance variables in a class are too large, and how many lines of code in a function are too long.
- Duplicated Code
- Long Method - The key is not the length of the function, but the semantic distance between what the function does and how it does it
- Large class (Large Class)
- Long Parameter List (Long Parameter List)
- Divergent Change - A class often changes in different directions for different reasons
- Shotgun Surgery - Every time a certain change is encountered, many small changes must be made in many different classes
- Feature Envy - A function is more interested in a class than its own class
- Data Clumps - same fields in two classes, same parameters in many function signatures
- Primitive Obsession - replacing primitive data with objects
- Switch (Switch Statements) - use less switch (or case) statements
- Parallel Inheritance Hierarchies - Whenever you subclass one class, you must subclass another class
- Lazy Class - class should fit its size and have some role
- Speculative Generality - Oh, I think we'll need to do this someday
- Temporary Field - An instance variable is set only for a specific situation
- Overcoupled Message Chains
- Middle Man - Excessive use of delegation, not dealing with the real responsible object
- Too many comments (Comments)
- …