I recently read this book on refactoring, and suddenly I had an idea. Code is not a brick but an art. How to write artistic code? That is to study design patterns and refactoring. You can learn many technologies such as common features of java and the principle of spring aop of framework technology, but I think these are actually tricks. Only design patterns and refactoring are the real content, which can really make your code feel artistic. So to be a programming artist one must be proficient in design patterns and refactoring.
Refactoring principles:
1. What is refactoring?
Does not change software functionality, provides readability and reduces modification costs
2. Why is refactoring needed, and what value can refactoring bring?
a) Refactoring improves software design. Refactoring is like sorting out code. The harder it is to see the design intent represented by the code, the harder it is to protect the design, and the faster the design disappears. Frequent refactoring can keep the code as it should be.
b) Refactoring makes the software easier to understand, easy for others and yourself to read, and easy to understand the design of the original code
c) Refactoring helps find bugs
d) Refactoring improves programming speed, and good design can achieve rapid development. Without good design you may be making rapid progress for a while, but poor design will quickly slow you down.
3. When to refactor
a) Refactor when adding functions. Refactoring can make you better understand your own and other people's code, and it will be easier to add code. If the design of the code is not convenient, let me add my features Then refactoring is required.
b) Refactor while fixing bugs, if you get a bug report, that's a signal that refactoring is needed, because obviously the code isn't clear enough to make you see the bug at a glance.
c) Refactoring when reviewing code, refactoring other people's code can get the most intuitive understanding.
4. How to tell the project manager that
the schedule-driven manager needs us to complete it as soon as possible. As for how to complete it, that is my own business. I think the fastest way is to refactor, so I will refactor.
6. Refactoring and Design
Still pre-engineering, but not necessarily finding the right solution. Refactoring makes future modifications less expensive.
7. Do not pay the necessary attention to performance during refactoring and performance
development. Until the performance optimization stage, usually only a small piece of code needs to be changed to greatly improve performance, because 90% of the performance problems are in 10% of the code logic place.
bad code smell
1. Duplicated Code
2. Long Method
3. Large Class
4. Long Parameter List
5. Divergent change, one class with multiple dimensions (Divergent Change)
6. Shotgun modification, one change design multiple classes (Shotgun Surgery)
7. Attachment plot, more interest in other categories than own category (Feature Envy)
Solution: move the current method to another class
8. Data Clumps, fields of multiple classes appear at the same time, and functions have the same input parameters (Data Clumps) (such as thirdpartOrderId and source)
Solution: Create a new object for these fields
9. Primitive Obsession
10.Switch Statement
11. Parallel inheritance, adding subclasses to one class must add subclasses to another class (Parallel Inheritance Hierarchies)
12. Redundant class, currently inactive class (Lazy Class)
13. Talking about the future, excessive pre-design (Speculative Generality)
Excessive abstraction, many abstract classes and hook methods, can be abstracted in the future when code redundancy is found.
14. Temporary variables of objects, only for special cases (Temporary Field)
Some variables in the instance only exist for special cases, which will make people confused. It is recommended to redefine a new object to save these temporary variables.
15. Over-coupled message chains, high coupling between client code and lookup objects (Message Chains)
16. The middleman, most of the methods of the class are delegated to the middleman (Middle Man)
17. Intimacy, two classes pay too much attention to each other's private part (Inapproriate Intimacy)
18. Alternative Classes With Different Interface
19. Imperfect class library, adding new behavior to the class library (Incomplete Library Class)
20. Naive Data Class
21. Refused Bequest, inheritance of useless properties and methods (Refused Bequest)
22. Too many comments, too many comments often need to refactor the code (Comments)
a) Too many comments often indicate bad code
b) if you don't know what to do, this is a good time to use annotations
c) In addition, annotations can be used to mark areas you are not sure about
Automated unit testing
a) Use automated testing tools such as junit
b) Whenever a bug report is received, add a new unit test for yourself
c) Test the code that is most likely to fail, without covering everything