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.
发表于 @ 2004年12月31日 18:01:00|评论(loading...)|编辑