The art of maintenance programming
The recent project personnel change, half time is safeguarding the code of others, it is a little uncomfortable, mainly the beginning is nothing to know about Maintenance Programming, too much, thinking that it is possible to work. I don't know how other people have maintained the code left by others.
Two days before I saw the CodeProject on a short man: Maintenance Programming Good Practices:
Http://www.codeproject.com/gen/design/artmaintion.asp
Unfortunately I saw a bit late):
People said 9, too lazy to turn over, have not seen it, I'm going to talk about:
Get to Like IT (I like it first)
It is easy to do it, let the write procedure will be willing to maintain the code of others, but also like Like, it is really difficult.
2. Get Familiar with the functionality of the software you maintain (familiar with the function of the software you need to maintain)
You have to maintain it, you have to change your bug, and you don't know how difficult. But I still feel painful.
3. Get Familiar with the architecture of the software you maintain (familiar with the architecture you maintain the software)
Familiar with familiarity.
4. Communicate with the use of the user (more to users)
There is no harm in communication.
5. If Possible, Communicate With Original Developers (if possible, multi-communication with the original developers)
Usually this is unlikely. If people are still there, PM generally does not let others maintain this part of code.
6. Keep The History of Changes (Reserved Records)
This is basically relying on version control software.
7. Be Conservative (the more conservative)
I don't believe in the beginning, some maintenance is more painful, I also try to override it, and I found it silly when I didn't pass, I only returned to a week before.
How would it benefit your organization and its customers? The fact that some code is ugly, or looks ugly to you is not per se a reason to rewrite it. If a customer wants a feature that can not be added to existing code, that could 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 (Test Code Every time you change)
This program written by C is too difficult to do. Try CPPUnit and Tut, CPPUnit is still better, can be embedded in the IDE of VC6, but write test code is not bored. I also know that Test Driven is a good stuff. Whoever uses it to handle it, you must share your experience.
9. Adopt EXISTING CONVEN EVEN IF you don't like them (even if you don't like the original code specification, you should accept it)
Code Conventions Are Something People Get Religious About. But if you don't force yourself slowly adapt to your pre-coding habits (at least when you maintain code), you will get more and more painful. The author said, Adopt One of the Existing Conventions, and Don n't Introduce Yet Another ONE.
