最近刚好在写一份关于系统维护的应标书，突然对系统维护有了一点想法。
众所周知，系统维护是很头疼的，需要维护的有以下几个地方：

1. 在使用过程中用户提出新的需求变更，要求修改系统；
2. 系统有bug，需要修改完善；
3. 系统运行的外部环境发生变化，需改进行维护，比如：数据库迁移等；

系统维护面临的困难也有如下几点：

1. 你不是系统的最初开发组成员，理解别人的代码有难度；
2. 系统缺乏必要的项目文档，造成对业务不熟悉，对项目整体把握不足；
3. 代码不规范，造成代码可维护性不好；
4. 软件维护的工作没有吸引力，使维护的开发人员没有成就感。

我个人觉得要降低系统维护的成本，最主要的是代码质量，其次是业务流程文档，再次是开发文档。对程序员而言，最好的文档就是代码。良好的代码结构层次可以大大降低维护工作量。如何组织良好的代码结构是我想说的重点。我这里并不讨论多层数据访问，也不讨论OO的思想，想说说关于一些组织代码的细节。

场景1：我们常常遇到这种情况，有一ComboBox需要加载某基础数据项(假设为客户名称)，需要用到 id和name两个属性；因为客户资料有多个地方用到，所以有多个界面用到类似的combobox。Binding数据的代码也都相同，分布在多个界面中。当初客户的需求是必须从下拉项中选择客户，所以多个界面也都设置好了属性，不允许编辑，只能从列表选择。现在客户改变了需求，需要增加查询的功能，在combobox中输入内容回车后，按模糊查询的结果列出来。于是一个一个界面的改，oh，my god，终于改完了。第2次，客户又提出类似的需求，要求对另一个基础数据（物料）也如此修改。开发人员又做重复劳动，一个一个界面改完了。那如果我们这些基础数据的列表集中起来管理不是更好吗？

那就建一个类：

public class CustomerComboBOxHelper
{
    private ComboBox cmb = null;
    public CustomerComboBOxHelper(ComboBox cmb)
    {
        this.cmb = cmb;
        //do something;
    }
}       

这样所有需要用到客户资料ComboBox的界面，直接调用此方法，当然如果由工厂创建实例更好。类似的需求还有，有时我们需要多处用到级联的ComboBox,比如显示：省，市，选择某个省，列出省下面的所有城市，这样的控制代码显然是一样的，那么我们也可以把它封装在一起，节省维护的成本；

场景2：系统中用得非常多的消息提示(MessageBox)，winform项目中到处都是类似这样的代码：MessageBox.Show("程序异常，请联系管理员！详细信息：" + ep.Message, xxxx系统, MessageBoxButtons.OK, MessageBoxIcon.Information);或者其它的类似的代码。客户提出需求变更，这样的错误消息提示不够友好，要求修改。你就慢慢一个一个去改吧。那为什么不把所有的MessageBox的方法封装在一起，包括显示错误消息，显示提示消息，显示Y/N，显示Ok/Cancel等等；参考代码：

public static class MessageBoxEx
    {
        public static DialogResult AskYesNo(string text)
        {
            //do some thing
        }
        public static DialogResult AskOkCancel(string text)
        {
            //do some thing
        }
        public static void ShowInfo(string text)
        {
            //do some thing
        }
        public static void ShowError(Exception ep)
        {
            //do some thing
        }
    }

当然，显示错误信息的方法单独写成一个类也行，这样如果想修改成自定义的界面显示错误消息，也仅仅只需要修改一处即可。

篇幅有限，上面讲的都是一些细节，这样的场景还有很多，但是它们都遵循一个原则，封装。尽可能使多处用到的代码封装在一起，辅以必要的注释，相信会大大减少项目维护的工作量。