The art of maintenance Programming

The art of maintenance Programming

 

Recently, project personnel have changed, and they have been maintaining others' code for half of the time. Some of them are really uncomfortable. The main reason is that they didn't know much about maintenance programming at the beginning, I thought that I could learn something and calculate the workload. I don't know how others maintain the code left by others.

 

Two days ago, I saw a short article from codeproject, which tells the truth: Good Practices of maintenance programming:

Http://www.codeproject.com/gen/design/artmaintenance.asp

 

Unfortunately, it's a bit late ):

People have said nine things, and they are too lazy to turn over. If you haven't seen them, let me talk about them:

1. Get to like it (first like it)

It is easy to say and difficult to do, so that the Write Program is willing to maintain other people's code, but also like, it is indeed difficult.

2. Get familiar with the functionality of the software you maintain (familiar with the functions of the software you need to maintain)

You have to modify bugs to maintain them, which is hard to understand. But I still felt quite painful at the beginning.

3. Get familiar with the architecture of the software you maintain (familiar with the architecture of the software you maintain)

Be familiar with learning more.

4. Communicate with the users (communicate with users more)

There is no harm in communication.

5. If possible, communicate with original developers (if possible, communicate with the original developer)

Generally, this is unlikely. If people are still there, PM generally won't let others maintain this part of the code.

6. Keep the history of changes (record of changes)

This basically depends on version control software.

 

7. Be conservative (the more conservative the better)

I didn't believe it at the beginning, and I tried to rewrite it in some difficult ways to maintain it. Later I found myself stupid when it didn't work, and I could only return to the Status a week ago.

• How wocould it benefit your organization and its MERs MERS? The fact that some code is uugly, or looks uugly to you is not per se a reason to rewrite it. if a customer wants a feature that can't be added to existing code, that cocould be a reason to consider rewriting it.
• Are you sure you understand what this Code does and how it works?
• Are you sure you understand how it interacts with other parts of the system, and which modules and functionality depend on the code you want to rewrite?
• Are you sure you can make it better? Maybe you run into the same problems the original developers did, and make it same or even worse.

8. Test after every change you make (run the test code every time there is a change)

This is too difficult for a program written in C ++. cppunit and tut have been tested. cppunit is a bit better and can be embedded in the IDE of vc6, but writing test code is also annoying. I also know that test driven is a good stuff. Who can use it with ease must share the good experience.

 

9. Adopt existing code conventions even if you don't like them (accept it even if you don't like the original encoding standard)

 

Code conventions are something people get religious about. But if you don't force yourself to gradually adapt to your predecessor's coding habits (at least when you maintain the Code), it will become more and more painful. The author said, adopt one of the existing conventions, and don't introduce yet another one.