Legacy systems: The pain of the age of software industry

I often feel fortunate that we are now in an exciting time, and we are in the age of software industry. In this era, our software development is no longer a small workshop, we are in the group of large-scale development. The software we develop is no longer an auxiliary tool designed for a workshop or process, it moves from one unit to the whole group, to the whole industry, and even to society as a whole, playing an increasingly important role. The role and impact of software has been far beyond the imagination of all, to become a region, a society, and even the entire country an integral part. Slowly, it is hard to imagine what it would be like to live and work without a certain software or system. This is the era of the software industry important characteristics of the times.

However, in this exciting era of software industry, the major software companies in the times are frustrating. Software is becoming more and more large, the software structure is more and more complex, but the software quality is becoming more and more low, software maintenance becomes more and more difficult, so every small change becomes need bones. The developers have done a great deal, and testers are the only saviors, and every little change requires a huge price to test. Software companies are struggling to sustain themselves in such a vicious circle. There is no doubt that this has become another feature of this exciting era.

Yes, we are not ready to face the software industry era. In the past, a software lifecycle was 2-3 years old, and as software requirements changed, we always chose to push the software over and over again, but now things are changing. With the expansion of software, the accumulation of software data, the enhancement of software influence, we, as well as our customers, are acutely aware that it will become more and more difficult and impractical to tear down a software redevelopment. The result is that our software will be constantly modified, maintained, modified, and maintained ... Until forever. What a painful thing it is!

Software, when it was first developed, everything was clear: clear business needs, clear design ideas, clear program code. But after a few changes in demand and maintenance, everything becomes less clear. Business requirements documents become ambiguous, design ideas have not followed the pace of change, the program code with the complexity of the business logic and bloated. Software development work is no longer a pleasure for programmers to start reading without understanding the code.

Over time, the software has changed and maintained over several years, dozens of of times, and the situation is getting worse. The original programmer was no longer willing to see his code and chose to leave. His successors became even more passive, and because of the ignorance of the program, every modification of the code was a tightrope. Testers become the only hope that every modification of a developer means that testers need to test all the programs. The successors began questioning the original designers, how the program was designed. If there is any new technology at this time, it will appear more old system dilapidated and unbearable.

Believe that this is the software industry in the era of all enterprises have to face the embarrassing situation. Does it really mean that our original design was wrong? Yes, we've all questioned ourselves, so we started trying to put more effort into software design at the beginning. We began to devote more time to demand research, to consider more possible changes in requirements, to do more interfaces, and to achieve more flexible but complex designs. And then, did we solve our problem? Apparently not. The demand has not changed as we think: The changes we thought might have happened did not happen, and the design we made for it turned out to be a device; we were caught off guard, the software quality began to fall, we were beaten back to the original. Is there really no medicine to solve it? In my opinion, if we do not understand the laws and characteristics of software development, then we can never find the long longing for the antidote. Now, let's really calm down to analyze the laws and characteristics of software development.

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

Software, especially management software, is essentially a simulation of the real world. We can improve our production efficiency by simulating the real world and realizing the information management of the computer. However, the reality of the world complex and changeable, we know the world is a simple to complex step-by-step process, this is a we can not change the objective law. Therefore, there is no doubt that, following such an objective law, our software development process must also be a simple to complex step-by-step process.

Initially, we developed a simulation of the simplest, most important, and most central part of the real world. Because it's simple, our thinking becomes clear and straightforward. However, our software cannot always just simulate the simplest, most important, and the core parts. Our customers in the process of using the software, if they encounter the less simple, less important, less core situation, our software can not be processed, this is not acceptable to customers in any case. Therefore, when the first version of the software is delivered to the customer, the customer's requirements begin to change.

Customer needs will never be divorced from the real world, that is to say, the real world does not exist things, phenomena, relationships can never appear in the software requirements. But real-world things, rules, and connections are not so simple and clear. As our software simulates it more and more carefully, the business logic of the program begins to become less clear and easier to understand, which is the most critical internal cause of software quality degradation.

The design of any software is always closely related to the complexity of the software. For example, customer information is an important information that many systems have to record. At first, our program is simple, customer information only records some simple information, such as customer name, address, telephone and so on, but as the complexity of the program increased, customer data began to become complex. For example, the first "address" field just needs a string, but as the requirements change, it begins to have the provinces, cities, regions, streets and other information. Then there will be postal code, community, police station and other information. We can do it in the "Customer Information table" When we add a two field at first, but we have to adjust our design in time, and then we need to get the address to form an "address information table" separately. If not adjusted in time, "Customer information table" will become more and more bloated, from 10 to a dozen fields, into 50, 80, 100 ...

This is true of the information table, especially for business operations. The initial business operations are so simple and clear that we don't need to spend too many classes to describe them clearly. For example, invoicing operation, the initial requirement is to read out the notes issued, save, and statistics this month and the amount of invoicing. Such a simple operation, designed as a simple "invoicing business class" reasonable. But then the business logic becomes more and more complex, we have to check whether the customer exists, the drawer has the authority, whether the bill is still in stock, and so on. At first, there is only one way to invoice, but with the addition of irregular invoicing, the way of invoicing is no longer single, and the statistical way changes ... As the business continues to grow, the size of the software code is also changing in quality. If we do not adjust our design in time, but all the programs are hard to "invoicing business Class", then the quality of the program will inevitably degenerate. "Invoicing Business Class" from the original dozens of lines, the surge to hundreds of lines, or even thousands of lines. The code will be difficult to read, and maintaining it will become a pain and no fun at all.

In the face of such a situation, how should we get out of the predicament? There is no doubt that refactoring, the refactoring of software. Does the checksum before invoicing really belong to the invoicing business class? Whether they should be extracted and decoupled into a single validation class. Do normal invoicing and abnormal invoicing really should be written together? Whether we should abstract the "Invoicing business Class" into an interface, as well as the implementation class for normal invoicing and abnormal invoicing. That's what I'm giving you: when software starts to degrade as demand changes, use software refactoring to improve our structure to adapt to changes in software requirements.