The Art of Maintenance Programming
最近项目人员变动的，自己有一半时间都在维护别人的（也有自己的）代码，真是有些不适应，主要是一开始对于Maintenance Programming没啥认识，太想当然了，本以为既能学东西还能算工作量。不知道其他人都是怎么维护别人留下来的代码的。
前两天看到CodeProject上一篇短小精悍的好文把Maintenance Programming 的Good Practices说的头头是道：
http://www.codeproject.com/gen/design/artmaintenance.asp
可惜看到有点晚了）：
人家说了9条，俺也懒得翻了，没看过的听俺大概说说：
1. Get to Like It （先喜欢上它）
说起来容易做起来可难，让写程序的心甘情愿去维护别人的代码，而且还要like，确实难。其实多想想就平衡了，听人家说咱们这个工种干的活都是靠左脑配合双手就可以完成了，基本上用不到大脑右半球的功能，所以也就谈不上啥真正的创造性，那维护别人的代码和自己写新的其实并无太大区别。
2. Get Familiar with the Functionality of the Software You Maintain （熟悉你需要维护的软件的功能）
你得维护还得改bug，想不熟悉都难。但还是觉得一开始比较痛苦。
3. Get Familiar with the Architecture of the Software You Maintain（跟你维护的那个软件的架构师混熟）
这个也比较容易，只要他没跳槽。
4. Communicate with the Users（多跟用户沟通）
沟通一下也没啥坏处。
5. If Possible, Communicate with Original Developers（如果可能，跟原来的那个开发人员多沟通）
通常这个是不大可能的。要是人家还在，PM一般也不会让别人来维护这部分代码。
6. Keep the History of Changes （保留改动的记录）
这个基本上就靠版本控制软件了。
7. Be Conservative （越保守越好）
一开始俺还不信，有些维护起来比较痛苦的地方，我还试图把它重写一下，后来发现行不通的时候自己都傻了，只能退回到一个礼拜以前的状态。
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’t 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（每次有改动都跑一下测试代码）
这条对于C++写的程序来说太难做到了，俺试过CppUnit和TUT，CppUnit还好一点，可以嵌到VC6的IDE里，但写测试代码也是不胜其烦。俺也知道Test driven是好东东，有谁用的得心应手一定要把好经验分享一下。
9. Adopt Existing Code Conventions Even If You Don’t Like Them（即使你不喜欢原来的编码规范也要接受它）
编码规范之争本来就是个生死攸关的原则问题Code conventions are something people get religious about。但是如果不强迫自己慢慢适应你的前任的编码习惯（至少在你维护代码的时候），到后面会越来越痛苦。作者说了，adopt one of the existing conventions, and don’t introduce yet another one.
