Reconstruction and serialization of big talk 9: you cannot afford the big layout

As a good developer, refactoring should become a habit. Naturally, we use the refactoring development mode to optimize and adjust our code. First, it requires us to master the refactoring development mode, that is, the development mode of "small steps and fast run", and use the design sequence of "two hats" to develop our programs. But as a beginner in refactoring, this is not easy, even if you have been working for many years.

The so-called change of a habit is like a person who is used to eating with his or her left hand. suddenly asked to change to his or her right hand, you will feel a lot of discomfort. First of all, discomfort is a psychological obstacle, that is, how to take the first step of code reconstruction requires a determination. Developers who are trying to refactor for the first time always have to go through a long time of tangle, struggling with whether to endure or refactor the existing code. Yes, it is not easy to take the first step of restructuring. It is a small step for you, but it is a huge step for this project and even the organization.

Another kind of discomfort comes from the mindset of small design or large layout. Let's take a look at a story I once experienced:

A typical legacy system is a large-scale software project that has been maintained for many years. After years of maintenance, the code is messy and developers have changed a lot, making maintenance increasingly difficult. At this time, both parties have reached an agreement through careful communication, that is, to carry out a large-scale transformation.

There is no doubt that the transformation work always starts from the meeting. After many rounds of meetings, I first talked to the customer, and then closed conferences. The Project Manager, Senior developers, and System Architects sat together to discuss one thing, action Plan for system transformation. At this moment, a very experienced System Architect spoke: "I have done System Transformation before. First, we should sort out the existing system and sort out its business functions. After so many years of maintenance, the Business Requirement documents are certainly incomplete. The functional business is not clearly organized. How can we transform it ?" It's quite pertinent.

"When the functions are clearly sorted out, we will start to sort out the system architecture: How to layer and How to Develop interfaces. This is a very meticulous task. The hierarchy must be reasonable and should be demonstrated repeatedly. Then, all interfaces are sorted and designed to form a design document ."

"It is very important to develop this design document. How can we develop it without a design document? Who is responsible for the wrong design? Isn't it a mess of porridge. Therefore, design documents should also be demonstrated, repeatedly demonstrated, and finally started development, testing, and delivery. It may take several months for the entire project to work out ."

After listening to the System Architect's speech, everyone agreed that it was feasible. Once again, with experience, the project manager made a shot like this. The next step was the analysis, sorting, development, and testing that lasted for several months. Dozens of people had a great deal of fun. At the end of the day, a harmonious society should be a very harmonious outcome. The system was successfully transformed and the new system was successfully launched. Both parties were very satisfied. However, it is a pity that this story does not have a harmonious ending. After years of maintenance, the original system has found and solved many problems. These problems are reflected in the very detailed design of the program code, but they are ignored by later analysis designers. Therefore, when the new system was launched for trial run, the new system seemed to be a replica of the old system several years ago. Many problems that have been discovered and fixed in the old system are re-emerging in the new system. At the end of the final system trial run, we spent months of hard work, and the customer did not mention the new system after the transformation.

What do you think after listening to this story? Have you ever had a similar experience? It is with such a painful multi-system transformation that many project managers have no doubt about system restructuring. People always like to learn to forget and forget the experiences that once stabbed us. Forget it. Don't touch that fragile nerve any more. Yes, you can choose to forget, but forgetting will never make us progress. The author always chooses to face the problem, face the problem, analyze it, and summarize it so that the error will never be committed again. Therefore, let's face up to the problem and analyze the root cause of the error. The root cause is the feedback that lasted several months.

By analyzing the entire project process, we were surprised to find that we had no idea about how to sort requirements, design interfaces, start development, test, and finally deliver for months, we are doing the right thing or not. As a result, the final outcome becomes a dubo, with either success or failure, each having a 50% probability. This is the key to the problem. What is successful project management? This is to minimize the chance of failure, but we have not done it here.

How can we minimize the chance of failure? If we can know whether the job is correct every month, the loss caused by the error is one month. If we check every Monday, the loss caused by the error is one week; for one day, the loss is one day; for several hours, the loss is several hours. In short, the sooner an error is found, the smaller the loss.

If time can be reversed, what should we do when we return to the previous conference room to re-plan the System Transformation Scheme? You can't afford the big layout if you don't try again! Do not plan the distant and uncontrollable future. It will only make you dizzy. A small design can make you succeed.

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!