The things that software develops: the cycle of software development

--a deep reflection and discussion on software analysis design

How many years have you been doing software development? Are you beginning to feel confused, tired, forget? Should you find a hotel in California to take a rest? This article may be your hotel in California, it gives you a problem, reflect on the problems in software development, explore ways to solve these problems, that is, build models-use case model, domain model, analysis model and design model.

Talking about software development, I started 10 years ago. At that time the sky is blue, life is beautiful, the program design is also relaxed and happy. If someone had told me that designing a program would take tens of millions of years to complete, I would stare at you for 10 minutes with a big mouth. At that time, the design of an application system is too simple, I and my teacher, and another classmate, three people spend three months can handle a system. We do not have to consider what middleware, what technical framework, what commonality. Follow the teacher to the customer to talk about the needs of the afternoon, draw a pile of ER diagram, and then use the Power Designer tool to generate the database, began to use the Power Builder design program. The design program is also quite simple, one afternoon you can design a stack of data windows, a person can design a few days a module. The project at that time was quite clear, for a department of a unit, or for a specific business. No need to consider versatility, the design is very rarely needed to change, big deal and redo a set of finished.

But then things began to change, the scope of software application is more and more extensive, initially a business, then many enterprises, and then the whole group, the entire system, and even the entire industry. Technology is also increasingly complex, from C/s to B/s, a variety of frameworks and technical routes, the integration of a variety of products. With the development of software, software design becomes more and more difficult with the increasing of the scale.

I personally experienced countless projects, but also watched others do countless projects. Although each project is different, but the whole process is stereotyped, are two words: Collapse! Almost every project begins with a good start, and the project leader will gather together to convene a seminar to summarize past lessons and prospects for the future. Almost every seminar everyone spit, listed the past is not, put forward a variety of perfect plan, everyone is passionate, feeling that they have entered a new era. Then each of them went back to their seats and began to work with care and care in accordance with the prescribed statutes. Months went by, everything was in order, and the problems that had arisen did not reappear, and everyone was secretly thankful. Perhaps, finally can go through a perfect development process.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

Then things happened, and the user hurried to say that the program was not as well designed as he wanted. OK, programmers have to make changes in their own perfect code, but the days of software delivery are on schedule. What to do? The programmer didn't start to change the code at random, and the functionality was implemented, but some bad design started. Many of the changes have changed the original design, hey, regardless of the original design document has been set aside. When the software is finished, the test begins. Soon, the tester put a bunch of problem reports to the programmer in an evil way. In order to complete the task, another heap of bad code appeared. Perhaps a programmer would say to himself, if it had been so designed, it would have taken one night to refactor the code.

Then again, the software is delivered to the customer. As the classic phrase describes: I changed when I saw it (the requirements began to change when I saw the software). When our software went through several rounds of customer change, everything became unrecognizable. This change is really the ultimate test of software design, but unfortunately, so far no one I have been involved in the software system has been living this test.

Once, the customer needs to modify a business logic, very clear business requirements, a very clear business change. But it's hard to find out when we actually start making changes, because countless people implement this business logic in their own modules, which means that the business logic is scattered across countless code, so a change in the business logic means that all of that code has to be modified accordingly. Crash, we plunged into endless overtime. Perhaps you might ask, why didn't you implement a common method for everyone to call? Yes, I want to ask the same question, but the situation continues, and similar events continue.

In this way, we maintain one system after another in pain, two or three years, 56, no fun. As time goes on, the people who maintain the system are also changing, and when the new people look back at the design materials in the past, it's not that they are incomplete or that they are different because of previous changes, and he can't get useful information from them. Even ask the client is incomplete memory, perhaps reading code is the real world, it is a crash ah. People have to vent their frustration by arguing loudly. Finally one day, our client generously said, well, let's redesign a system. OK, everything is free, we started another reincarnation. Continued