Software maintenance nightmare

In many cases, we may not be so lucky to be called for software development, but to maintain existing software. For example, if our predecessors have switched jobs or arranged to do other work, the rest of the delivered software will need people to continue maintenance. This is a tough task. First, you must understand the knowledge of the predecessors.CodeAnd then software support and change Bug , Change features, new features, and so on. It is a painful repair and makeup work.

Compared with software development, software maintenance is simply boring. First of all, we cannot make achievements. Although it is easier to maintain a large amount of code than development, the previous software architecture is not good, and the maintenance is poor, you have a lot of work, but you have done a good job, that is, maintenance, without innovation, without credit. If you have credit, it is also the result of the previous generation's system design. Second, the work content is boring. Who is willing to read others' code with full effort? What's more, some codes have no documentation, no comments, and no code for the three without good naming rules. Even if there is a document, the document has not been updated for a long time, and the code is not correct. Looking at this kind of code, changing this kind of code is simply a torment and a test of your patience.

Even more frightening is that, although the architecture design described in the Design Manual is exquisite and flexible, the results are often not the same and are vulnerable to new functional requirements. Most of the time, you have changed a small place, and the result will touch many other hidden nerves. You must be careful when making any changes. Except for the originalProgramNo one knows exactly how many places a function needs to be modified and where it is associated. This function affects that function. Sometimes, even the list of required functional points is not left. This is simply a nightmare of software maintenance.

The final result is: "The money is basically spent, people are basically jumping, and the feelings between Party A and Party B are basically broken down ."

In fact, in terms of the software life cycle, one day, the architecture of any software will become increasingly unable to meet new requirements and will come to an end. However, the customer will not abandon the original system and spend a lot of money to develop a new system. So it is of some significance to discuss how to perform software maintenance.

 

Is there no system with good maintainability?

Some of the old systems I have seen have been operating stably for decades and maintained well. (It may be a bit painful for the last one or two years, but it has been stable for decades) for example, the old banking and power systems were not built into the new system until the banks began to gather in the past few years. Are their systems so powerful? Don't they have new requirements? Wrong, the secret is that the core business of the Bank has not changed, so the core value and functions of the software have not changed. What has changed is just the need for small edges, the Bank will continue to operate some non-core businesses and systems, but the premise is that the operation of the core business system will not be affected without modification. I think this is a little inspiration for people who do software development and maintenance. How can we mine things that do not change frequently? When designing the system at first, we should focus on the core business needs, because that is the biggest value and core of the software. Core value cannot be changed. The design of this core business value should be well scalable, maintainability, and stability. Of course, comprehensive and meticulous documents and timely updates are all very important and can withstand the risk of staff loss.

 

Re-recognize software lifecycle from maintenance

• Software maintenance usually accounts for 40%-80% of the total software cost. maintenance may be the most important stage in the entire software life cycle.
• Enhancements may account for 60% of software maintenance work.
• Software maintenance is a solution, not a problem ).
• Understanding existing software is the most difficult task in software maintenance.
• Complex logic, functions, and configurations all reduce the maintainability of the software.

 

Innovation in software maintenance: Restructuring

When assigned for software maintenance, you can also learn a lot, or think about how to refactor during maintenance. Because any successful software is refactored constantly to be truly successful1.0,2.0, Refactor3.0, Even8.0Do not think that the software is perfect at any time, and you can refactor it at any time. When the software is broken and overwhelmed, it is time to restructure the software. However, attention should be paid to the following points for refactoring:

First, restructuring should keep the core value of the system unchanged. For example, the biggest selling point of old software is that it is small and fast to start. The core value to users cannot be lost in future reconstruction; otherwise, users will be lost.

second, rebuild requires attention to risks. The premise for restructuring is to have a good understanding of the old system, including the functional points, architecture, implementation details, dependencies, strengths and weaknesses, related documents, and business logic. Another prerequisite for refactoring is quality assurance, unit testing, function testing, and regression testing, otherwise, any effort to reconstruct and decouple the system and improve the code structure, performance, and maintainability will bring great risks.