Old System Maintenance

Old System Maintenance

Today I am talking about an old topic about how to maintain an old system, especially a very heavy old system, which has been less than 3-5 years old, and more than 7-8 years old. I don't know who wrote the first version of code, this old system has sent away a group of programmers, which can be regarded as the vicissitudes of the company. Today, it is both a hero of the company and a burden of the company, every company has more or less old systems.
Developing a new project to replace the old system requires a lot of manpower and material resources. After a period of time, it will take some time to work with its stability. Will the new project be better than the old one? There is still a high probability of project failure, and no one is willing to take such risks. In contrast, it is conservative to maintain an old system and upgrade it to meet new requirements, but it is stable and has low risks. What should I do? It makes sense to exist. Otherwise, the system will be overturned and restarted.
At this time, it is natural that the maintenance personnel of the old system suffer.
As you can imagine, there is no database table design specification, no requirements or design documents, and the code style is different without several annotations. The same open-source framework can coexist in multiple versions, what does an old system without any hierarchical design bring to maintenance personnel?
I hope you understand it.
I have also recently maintained a system like this. Since I have no choice but to accept it, I have to find fun, gain experience, and make progress in it, isn't it?
Project Background: The development platform is used for projects developed by other project teams. My task is to continuously patch the development platform, it also provides platform support for other project teams.
This is for your reference only.
1. If you do not want to be scolded by the person who takes over the project, make sure to comment on the modification description during the modification. The more detailed the modification, the better, there are even more lines than the code you modified. You can even modify it by attaching a document to the same directory. I believe that later people will be grateful to you.
2. How can I change it if there is no database specification, no documentation, no comments? Don't worry. Many programmers face the same problem as you. The company won't let you drink tea and read newspapers. If you encounter such a problem, calm down! Communicate with the personnel who raise requests and raise bugs in depth: first, do you have to change it? Can you convince the customer not to change it. Describe the interests. 2. If a customer buys your software, it will naturally be God, and there is no way to make it necessary. Well, it should be written so that the customer can clearly describe the problem and developers can understand it, the two have had a practical communication. If developers are dealing with implementers, they need to conduct in-depth communication to prevent useless work. What comes out is not what the customer wants, and the loss is worth the candle. Finally, the communication must be changed to what it looks like. I have a good idea. Then I start to communicate, communicate, or communicate more.
3. Backup or backup. Don't think you have SVN. Most of the time, the code in SVN and the customer's on-site deployment are not a single thing. Many modifications are made at the customer's site and are not reported to the company's SVN server. You thought the modification was wrong. SVN still had it. It would be okay to download another copy. That's not the case at all. Therefore, before modification, please manually back up and write down the backup date, current version, why, how to restore the backup, and the operator.
4. Sometimes someone will ask some questions about your maintenance project. After a long time, repeated questions are always asked over and over again. Well, you will want me to write a document, put it on the company's Internet so that I can save trouble. I can only say that you only do half of it. Slowly, you will find that you will still ask the same question. Clearly there is a document, and you will not go to it, but will still directly call for the question. Why? First, you don't know where there are documents. Second, it's better to ask people quickly, because every time you answer them one by one. Therefore, you have written a document to inform everyone. If you still ask, well, you can try to tell him. Wait a moment, I will send you an email and never send a document, simply send a link and send a Warm Reminder. If you encounter any problems in the future, you can find them. Sometimes you get used to it and cultivate your habits.
5. Next let's talk about the technical details: 1) Install patches, write as independent functions as much as possible, and tune the plug-in to minimize the original code, that is, introduce fewer bugs. 2) avoid global variables as much as possible. Introducing global variables is very dangerous for the system and should be understood by many programmers. 3) What have you modified for each version? A document says that it is easy for you to restore it back or find a version targeting a customer. 4) Don't rush to launch the patch to all projects. First, push a project team. After a while, it will prove that the patch is stable, and then push the patch in a large area. You know. 5) There are many text comparison tools that can be used and are essential for maintenance. 6) to implement the function, we should try to reduce the number of interactions as much as possible. Do not use a master-slave table without using a master-slave table. Split a table into a single table and then split it into a single table, if you can use a pop-up window, do not maintain two tables on a single form. In short, the more simple the function is, the less difficult it is to introduce problems and the easier it is to maintain.
6. Changing the bug will make it hard to get angry, or even stay awake at night. Please drink plenty of water and relax.
Write so much first.
I wish all the staff who are doing maintenance now a smooth job and a pleasant mood.