==========Pragmatism============
I don’t know when the domestic technical people began to popularize Dahua technology. Many books of “Dahua XXX” appeared in the world. The earliest and more classic of these books should be called “Dahua Design Patterns”. I have to say that I use this This way of speaking about technical issues makes it easier for many people to understand. This way should convey an idea: practical!
It can be seen from the two chapters in the trial reading of "Dahua Refactoring" that this book should also be based on such an idea. As said in the book, there are many books about refactoring, and the technical leaders of various companies are "passionate" when they read it. Exuberant and passionate", but when it comes to practice, "I am at a loss, and after a lot of struggle, I will give up." Therefore, any book should be read from a practical point of view. We will use it if it is useful. If it is not Discard it when you use it, and use it when it is useful.
Recently, our team is promoting agile development. We are a small team, with a total of about 10 people, and we are divided into three groups. Some members still have multiple roles, so many good agile development practices, theories and methods are in our hands. It is not practical in our team. We insist on "continuous improvement" and pragmatism. We will try what works for us. If we have tried it and the effect is not good, we must resolutely discard it and seek a better method.
For refactoring, we haven't done this work on a large scale yet, but the plan is on the agenda, and with these problems in the near future, I think the same should be said about this book or any book: Practical doctrine .
As the martial arts master Jin Yong said, "no trick wins, there are tricks", so many reconstruction methods are not for you to copy, but after a deep understanding of them, they will eventually become your own reconstruction methods. In actual work, we don't care too much about what refactoring method we use, and which method is used for which refactoring, as long as it is a suitable design. However, before there are no tricks to win, we must have tricks, that is, we must learn and understand each trick. Only in practical work can you remember these tricks and use them.
==========Overdesign============
The examples in Chapter 2 are very good. At the beginning, I looked at what kind of refactoring method was used in this book. When I followed the author's refactoring ideas, I found a simple The example actually uses the interface. It has to be said that the interface makes the program expandable, but the readability and maintainability of the program are greatly reduced.
Many times when reading the code and seeing that the parameters are all interfaces, the documentation also mentions which interfaces are used, but which implementation of the interfaces should be used, which makes programmers feel embarrassed. At the end of the reading, I found that the author used a negative teaching material. It turned out that I wanted to explain what over-design is .
As far as the examples in this chapter are concerned, a simple business should not require such a complicated design. If it is really necessary, then various implementations of the interface must be described and written in the description of the interface. I think this can be done in the company's internal WIKI:
When creating a port, in addition to explaining the interface, it is also necessary to explain which implementations of this interface currently exist, and under what circumstances each implementation is used. In this way, both new programmers and old programmers can understand the usage of this interface at a glance.
=========Small steps, big steps==========
To take small steps or take large steps is the question.
The big step is often to start all over again, and few people have this courage and this ability. I have seen an old programmer in his 50s who often has the courage to start over. He can be said to be the first batch of college students after the resumption of the college entrance examination in the Republic, and he is a mathematics major. His skills are not comparable to ordinary people. Refactoring, in-depth understanding of business and requirements, and design ideas will gradually mature and become more scientific. It is not difficult for him to start over.
For most programmers and many programmers who have taken over from other programmers, the risk of letting them refactor can be imagined. Whether it’s overturning and starting over, or running in small steps, it is necessary to do very small details. , Without a sufficient understanding of the needs, small steps or big steps are risky. In contrast, small steps may be easier to control. So small steps or big steps, depending on the situation, the refactoring of big steps needs to be fully prepared.
If there is no confidence, it is better to be agile, set a big goal, break it down into several small goals, and make them into small iterations. After each small iteration is completed, analyze whether the goal needs to be revised. (I once heard a saying from a management expert that if you plan well, you are not a master, but if you plan well, you are a master)
I think I can learn from the practice of a previous leader. Before refactoring, we must first clarify the goal, whether to improve code standardization, improve performance, or improve scalability.
For example, if you want to improve the standardization of the code, this goal may involve all the code. The leader summarizes the normative issues in a total of several points, such as:
1. Database naming convention
2. Page naming convention
3. Variable naming convention
4. Business processing specifications
.....
Each specification cites several counter-examples and several positive examples.
In this way, there is a final goal, a stage goal, and the goal is clear and organized, no matter who is doing it, it is very clear. The first stage begins to divide the stage, and the first stage begins to adjust the database naming convention. Complete the later comprehensive test before proceeding to the next stage of the task.
And my team is taking this approach. The current operations have not encountered large and small operations such as improving scalability and refactoring into a plug-in structure. They are all focused on improving performance. Refactoring such as scalability is because the current program has not yet met the performance requirements. At this time, doing such a reconstruction will not say whether there is any loss in performance. After the performance optimization achieves the goal, it is necessary to refactor the scalability. do not know.
So we set the ultimate goal: 7 transactions per second per thread. (Our product involves multi-threading)
With the ultimate goal, we must first understand the current situation. After testing, we know that the situation at that time was an average of 4 transactions per second.
We decompose the achievement of this goal into:
1. A single thread processes 10 transactions per second.
2, to achieve multi-threaded processing business.
3. The average processing time of each transaction in a multi-threaded environment is within 100 milliseconds.
4. In the case of multi-threading, it can achieve the best match with the number of CPUs.
5. Under the network communication environment, it can process 7 transactions per second.
We are now at step 5. But it wasn't like that in the beginning.
1. A single thread processes 10 transactions per second.
2, to achieve multi-threaded processing business.
3. Each thread processes 7 transactions per second.
The reason why the target decomposition is now more than before is because we found a lot of problems that need to be solved every step of the way. With the deepening of the test, the understanding of multi-threading is also deeper. After each goal is achieved, we will discuss the next one. What is the problem to be solved, thereby adjusting the goal.
Although we don't have normative documentation, and even the code is not normative, we are moving in a better direction step by step.
===================
The purpose of refactoring is very simple, it is to make the product better and stronger, but no one can say how to make it better and stronger.
As long as it can be proved to be better than before, it must be used. Whether it is technical specifications, codes, requirements, processes, or management performance appraisal, incentive methods, documents, and systems, one rule must be followed: the only constant in the world. It's change!
And agile development is the best way to deal with change: continuous improvement. The same is true of refactoring. Unchanging is waiting to die. Change may die faster, but it may not necessarily die. To borrow an old saying: A journey of a thousand miles begins with one step. No matter how it is restructured, it will come out one step at a time. If you want to walk steadily, every step must be solid.