Rebuilding serialization in big words 10: Small design, not big layout

Labels: Software Design agility

Drivers must have a deep understanding that driving a car is a process of constantly correcting the car's driving direction. During the entire driving process, you must focus on the front and use the steering wheel to continuously correct the direction. Otherwise, even if you are traveling in a straight line, you may also deviate from the lane. Drivers who are fatigued are unable to correct their directions because they are sleep, and the vehicles are increasingly off course. In this case, even a small crash in a few seconds can cause serious consequences of car destruction.

Reconstruction and driving are completely different fields, but the truth is the same. We often make mistakes when using refactoring methods to modify code (people make mistakes ). Making mistakes is like moving away from course, so we need to constantly correct them. Since it is correction, there must be a correct standard and a correct method. The correct criterion during driving is whether the vehicle is correctly driving in its own driveway. The correct method is the visual inspection of the driver's friends. Similarly, the correct criterion in the refactoring process is whether our software maintains the external behavior before the refactoring, and the judgment method is testing, whether it is manual testing or automated testing.

This is simple, but the problem is that you cannot test it at any time and correct it at any time. This is impossible. Therefore, we must have a cycle, that is, the interval between tests and correction. The longer the cycle, the higher the chance of a major problem, just like the sleeping driver. The shorter the cycle, the higher the cost we need, because every test is costly. The duration of the cycle needs to be constantly weighed.

However, unlike driving, the rebuild test cycle depends on the rebuild and code submission cycle. Because software refactoring is always such a process, first modify some code so that the program is in an error and cannot be compiled and run, and then completely modify all other relevant code, resume the program compilation and runability. In this intermediate state, we cannot test, or the test is meaningless. The test is meaningful only when the relevant code is modified and the program is restored to the running state. Every time we complete such a process, we call it "completing a reconstruction ". The time taken to complete a refactoring is a key factor that determines our test cycle.

In this case, how long does it take for us to complete a reconstruction? It sounds like a mathematical derivation, but the truth is that. The time taken to reconstruct a rebuild is determined by our design. Small design: The amount of modifications to the code is small, and the reconstruction time is short. Large design requires a large amount of modifications to the Code, and the reconstruction time must be long. The reconstruction takes a long time, and the test period is long. We find that the error takes a long time and the loss may be huge.

Why can't we afford the big layout? Long business organization and long design and development lasted for several months. We have been unable to assess whether we are correct over the past few months. After several months of hard work, we were told that we had made a mistake. Everything was too late, and the project had to slide into the abyss of failure. This is the root cause of the previous story system transformation failure.

We said that big layout is not acceptable, but big design is also impossible. I started to refactor. We thought about a lot of problems and used a lot of reconstruction techniques to complete a reconstruction. Such refactoring requires a lot of code modifications, a long reconstruction cycle, and a high risk of errors. Therefore, our reconstruction should be a small design. Use one reconstruction method to solve a problem, complete one reconstruction, pass the test, and use another reconstruction method to solve another problem and complete another reconstruction ...... In this way, this is the development model I mentioned earlier, "small steps and fast running.

However, the concept that I must clarify is that determining whether it is a big design metric is not the number of lines of code. To give a simple example, we can move a piece of code with thousands of lines from one function to another without moving it to another function, but the Code itself is slightly changed. Isn't this a big design? Obviously it does not belong to, because we do not have much code to modify. We will see later that this code is often moved during the refactoring process.

The small step enables us to focus only on one problem each time we refactor and use one reconstruction method to solve this problem. In this way, we will not think too much or too far every time we modify the problem. However, this is not because we have no long-term plans. You can have a long-term plan, but this plan should not be done too early. It is easy to ignore this plan too early. After working for a while, do some basic work, let us have a more comprehensive understanding of the system as a whole, and then plan, this will get better results.

At the same time, it requires us not to be too careful about future planning. The more recent the plan, the more rough the plan will be. Some people are eager to make careful future plans because they are worried about what they are doing today. When they find that they are wrong in the future, they have to change their plans. So today, let's think more and make more plans. But the question is, is the plan correct today? If it is good, but the reality is often true or not. Incorrect planning is often counterproductive, which puts us in a dilemma that neither solves the current problem nor has to bury the ticket for wrong design. Therefore, the thought of restructuring completely breaks this habit of thinking. Refactoring is not afraid of modification, because it makes tomorrow's code modification safe, rather than walking the wire. It believes that today's task is to change today, even if tomorrow is regarded as wrong, it will change again tomorrow.

Big talk rebuilding serialization home: http://blog.csdn.net/mooodo/article/details/32083021

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!