Large layout for refactoring

As an excellent developer, refactoring should become a habit, naturally using refactoring development patterns, and naturally optimizing and tweaking our code. It first requires us to master the development model of refactoring, that is, the development model of "small step Running", using the "two hats" design sequence, to develop our program. But as a beginner, it's not easy, even if you've been working for years.

The so-called change a habit, as if accustomed to the left hand to eat people, suddenly be asked to change to the right hand, you will inevitably feel a lot of discomfort. The first discomfort is a psychological obstacle, that is, how to take the first step in refactoring code, which requires a determination. Developers who try to refactor for the first time will always have to go through a long period of entanglement and struggle with the existing code to forbear or refactor. Yes, the first step out of refactoring is not easy, it's a small step for you, but it's a big step for the project and even for the organization.

Another kind of discomfort comes from a mindset, a small design or a large layout. Let's take a look at a story I've been through:

A large software project that has been in maintenance for many years, typically a legacy system. After years of maintenance, the code has become messy, developers have changed a lot of stubble, maintenance work becomes more and more difficult. At this time, the two sides after careful communication reached a consensus, is to carry out a large-scale transformation.

There is no doubt that the renovation work always begins with the meeting. After many rounds of meetings, it started out as a conversation with a client, followed by a closed-door meeting, where the project manager, senior developer, and system architect sat down to discuss one thing, a system-wide action plan. At this point, an experienced system Architect said: "System transformation I have done before." We should first comb the existing system to comb its business functions. Maintenance for so many years, the business requirements of the document must not be complete. Functional business are not combed clear, how to transform it? "That's pretty fair.

"The function combs clearly, starts to comb the system structure: how stratification, how to develop the interface." This is a very meticulous work, layering must be reasonable, to be repeatedly demonstrated. Then, all the interfaces are sorted out and designed to form a design document. ”

"It is very important to develop this design document and how to develop it without a design document?" Who is responsible for the wrong design? will not be disorderly into porridge. Therefore, the design document should also be demonstrated, repeated argumentation, and finally began to develop, test, delivery. It's going to be months before the whole project is done. ”

Listening to the system Architect's speech, we agreed that it was possible. The idea that he had done it before and experienced it was the project manager's decision. followed by a few months of analysis, collation, development, testing, decades of people do a good job. Finally to the end of the time, the harmonious society should be a fairly harmonious outcome, the system is successful, the new system smooth line, A and b both sides are very satisfied. But unfortunately, the story did not get that harmonious ending. The original system after years of maintenance, found and solved a lot of problems, these problems are embodied in the program code in the very detailed design, but for the subsequent analysis of the designers are ignored. So when the new system is on the run, the new system seems to be a duplicate of the old system a few years ago. Many of the problems that have been discovered and repaired in the old system are repeated in the new system. When the end of the system test run ended, we spent months of hard work and water drift, the customer no longer mention the new system after the transformation.

How do you feel about hearing this story? Have you ever had a similar experience? It is with so many system reform painful lessons, only then so many project managers to the system reconfiguration secrecy. People always like to learn to forget, forget those who have hurt our hearts experience. Forget it, don't touch that fragile nerve. Yes, you can choose to forget, but forgetting is never going to make us progress. Brave people always choose to face problems, face up to problems, to analyze, to sum up, so that mistakes will never be repeated. So let's face the problem and analyze the root cause of its mistakes. The root cause is feedback that lasts a few months.

Analyzing the whole process of the project, we were surprised to find out that we were right or wrong, from tidying up requirements, designing interfaces, initiating development, testing, and finally delivering, for a whole few months. The end result becomes a dubo, either success or failure, each 50% probability, which is the crux of the problem. What is successful project management? is to minimize the chance of failure, and here we are not.

How can you minimize the chance of failure? If we can know that the work of this month is right for every one months, the loss of our mistake is one months; if we check it once a week, the wrong loss is a week; if it is a day, the loss is a day; for hours, the loss is a few hours. In short, the sooner the mistake is discovered, the less we will lose.

If time could turn upside down, what should we do when we go back to the same conference room and redesign the system reform plan? Do not go to cloth so big Bureau, big layout you can't afford to hurt! Don't plan that distant and impossible future, it will only make you dizzy. Small designs can make you successful.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/