Today, talk about an old topic, how to maintain an old system, especially a very heavy old system, less than 3-5 years, more than 7-8 years, the first version of the code is not known who is written, the old system ushered in a group of a group of programmers, can be seen as the company's ups and downs, now, it is the company's hero, is also the company's Burden,Each company is more or less some kind of old system.
The development of new projects to replace the old system, the need for a lot of manpower and material resources, but also after a period of time to run its stability, the new must be better than the old use it? The probability of a project failure remains large, and no one is willing to take the risk. In contrast, maintaining an old system, facing new requirements, upgrading the old system, although conservative, but very robust, the risk is very low. What do you say? There is a reason, otherwise the early overthrow.
This time, the natural suffering of the old system maintenance personnel.
Can you imagine that there is no database table design specification, no requirements and design documents, the code style is very different without a few comments, the same open source framework multi-version coexistence, no hierarchical design of the old system to the maintenance staff what is it?
Don't say, I hope you understand.
I also recently in the maintenance of a such system, since there is no choice, can only accept, but also to find fun, gain experience, make progress, is not it?
Project background: Development platform, other projects developed by the project are based on this development platform, and my task is to continue to patch the development platform to add functionality, but also for other project groups to provide platform support.
Sentiment of the talk, for reference only.
1, if you do not want to be behind the person to take over this project scold, please change in the time, be sure to comment on the revised instructions, the more detailed the better, than you modify the number of lines of code is not too much. You can even modify the point in the same directory with the previous documentation, I believe Yimeimei will grateful you.
2, no database instructions, no documents, no comments, how to change? Do not worry, many programmers and you face the same problem, the company recruit you do not let you drink tea to read the newspaper. Come on, calm down! The first and the request and the person to raise the bug in-depth communication: First, must change it? Can you persuade the customer not to change. Clarify the stakes. Second, customers buy your software, nature is God, there is no way to change, that good, put into writing, so that customers to describe their own problems clearly, developers can understand, both have a practical communication. If the developers are faced with the implementation of personnel, it is more in-depth communication, to prevent doing no work, out of things is not what customers want, not worth the candle. Finally communication, must change, change to what appearance, in the heart knows, then start hands, communication, communication, or more communication.
3, Backup, or backup. Do not think that there is SVN, you have peace of mind, dream it. Because most of the time, SVN inside the code with the customer site deployment is not a thing, many modifications are done at the customer site, there is no feedback to the company SVN server. You think the change is wrong, SVN, and then download a copy is OK, it is not so. So, before modifying, please manually back up and write good backup date, what version is currently in, why backup, how to restore that backup, operator.
4, sometimes someone will be on your maintenance of the project to ask some questions, days long, repeat the question is always asked again and again, that well, you will want me to write documents, put in the company online, so I am easy, I can only say, you only do half. Slowly, you will find that people will still ask you the same question, obviously there are documents, we do not go to see, still direct phone over the problem. What's the reason? First, people do not know that there is documentation; second, it is better to ask people directly because you have answered them every time. So, you have written a document to inform everyone, if you still ask you, that good, you can try to tell him, a moment, I send you an e-mail, do not send a document, directly sent a link, incidentally, a warm reminder, after encountering problems, where to find. Everyone's habits are sometimes you get used to, but also you cultivate.
5, the next point of technical details on it: 1) patching, as far as possible to write a separate function, in the place to adjust the insertion, less the original code, is less introduction of bugs. 2) As far as possible to avoid global variables, the introduction of global variables for the system is very dangerous, a lot of fellow programmers should understand. 3) Each version, you have changed what, to have a document said, so you want to restore back or find a version of a customer will be very calm. 4) do not rush to all projects to launch this patch, first push a project team, after a period of time to prove that the patch is stable, and then a large area of push, you know. 5) There are many text comparison tools that you can use to make maintenance essential tools. 6) To do the function, to minimize linkage starting, can not use master and slave table, you can split into a single table on a single table, you can use the pop-up window on a form to maintain two tables and so on, in short, the more single, the less easy to introduce problems, the more easy to maintain.
6, change the bug will change to Wohuo uncomfortable, even night can not sleep, please drink more water, relax heart.
Write so much first.
I wish all the temporary maintenance personnel work smoothly and in a happy mood.
Talking about the maintenance of old system
