以前总觉得系统维护是一件很遥远、也很高深的事情，既向往，又怕做不好。不过现在不会想那么多了，只想着怎么把它做好。
“维护事业”是从图书馆维护开始的。图书馆的维护可以说是分两个阶段，第一阶段是没有设置“管理员”，大家组与组之间直接“对话”，交接问题重重，而且每次任务散乱，效率奇差。第二个阶段，“请”出了蒋倩兰做管理员，维护日志都从她这获取，减少了组与组之间的对话，也减少耦合性。任务方面，每个小组每次集中完成一项任务（比如重装系统）。这样的任务相对集中，效率也高得多。组与组之间就相当于“流水线作业”一样，每个组每次只针对某项任务，聚焦点高了，效率也自然会上去。同时，也为我们现在正在着手的“图书馆在线维护系统”提供了有力的帮助。
YH维护是花费经历最多的维护。不过收获也是很大的。从大的方面来说，YH让我见证了一个商业软件从开发到销售，再到后来的维护的大部分过程，从而整体上浅略的认识了一个商业软件的实用价值。
维护工作，与客户的沟通，则发现了许多系统中为测出的Bug，设计上的不合理的地方，还有用户的新需求，为系统的升级，做足了铺垫。一个项目系统，只有通过了真实用户的真正考验，才可以体现它的价值，同时用户反馈的信息，也才是最有用、最具价值的。维护过程中一些维护事项，也颠覆了我对系统维护的想法。一般情况下我们都会给用户配置软件所需要的环境，系统得以正常运作。而维护工作有一多半儿的工作，都是非系统出错问题。我大致估算了一下:
最多的环境配置问题，包括软件和硬件2个方面的配置。不过多亏了各种文档，也节省了我不少时间。维护过程中也体会了对于系统函数也不能轻易相信。电脑的非正常关机可能导致时间错误而影响到项目系统的使用。所以我们可能需要用系统和网络的双重验证。
后期的新功能添加、测试和系统升级，从代码中也体会到了合作开发时的注意项。每一项功能都必须写好注释、负责人，完成时间，功能，修改人，修改内容，修改时间等等等等。这样在以后的维护的时候会轻松得多。BS网站的发布部署也学到了不少知识。前台的CS发布，后台的BS管理，都通过配置文件与数据库相连，对一个系统的运作有了新的认识。
YH是在短时间内做出来的，灵活性要差一些，一些可配置项被写死在了程序里，这样对于一些新需求的处理只能通过修改源码，进行升级处理。提高系统的灵活性，通过配置不同项来满足用户的新需求也可以增加用户体验度和产品忠诚度。
总得来说，YH维护让我清楚的认识到：
①. 有效的文档很重要，非常重要。
②. 维护工作很繁琐，但是对于我们对需求的理解帮助很大。对以后开发系统的易用性最为重要，健壮性和可靠性也会提升很多。
③. 软件不一定只做项目本身功能，为了提高用户体验度和系统易用性，还应该添加对运行环境的检测功能。比如说“网络连接状态”问题。
④. 合作开发，负责到人。合作开发，接口增多，负责到人，可以降低交流的耦合度。
评教维护相对于YH来说，可以说小巫见大巫。因为评教半年一次，但是维护系数要大一些。评教的文档特别少（当然软件问题的确很少），维护起来很麻烦，必须花时间去实验，去理解系统的功能和实现逻辑。不过对于评教的并发处理能力很有帮助，评教中对于并发处理的方法好像是将某时间段内的请求集体发给服务器集中处理，而非每一个请求都及时去处理，这样大大节省了服务器的系统开销，同时也提高了系统的反应速度。
当然维护的财富不只这些，有些财富就在面前，虽然可以看见，但是还没有得到，需要继续走下去。维护是一笔大财富，需要慢慢咀嚼，慢慢消化。