系统维护工作的准确定义到底是什么我并不是很清楚，但是做过了半年的所谓的系统维护工作之后，对业务系统有了新的认识，有一些新的体会和想法。

我所做的系统维护工作的主要内容就是对一个正在运行的保险公司的业务系统按照用户的要求进行功能的添加，而这种要求是不断的，一个接着一个，修改和添加涉及到该系统的各个子系统。总的来说琐碎而又复杂，说它琐碎是因为大大小小什么样的工作都有，页面表示文字的修改，服务器增加安全补丁后的系统能否正常工作的确认，在既有业务的基础上增加新的需求等等，说它复杂是因为要理解现有系统的各个方面，从页面到数据的 batch 处理部分，而且现有的系统也是一步一步由最初的系统不断增加新的功能而来得，需要循其历史，究其根本。比起开发新项目，少了一些挑战和刺激，少了一些学习新技术的机会，还少了很多加班（这点我倒很乐意）。但是任何工作，只要用心去体会，总会有收获的，这段时间的工作，也给了我很多新的东西，值得在以后的工作思考和借鉴。

1．    系统维护与瀑布模型

这段时间的维护，采用的是瀑布模型。具体执行起来是这样的，用户如果有新的要求，就需要我们和用户进行交流并整理出需求文档，然后和用户一起 Review, 合格之后进行设计文档的编写，因为是在既有系统上的功能修改或者添加，所以设计文档要写出现有的式样以及新的式样，涉及的模块和文件，修改的方法。完成之后进行设计的 Review, 如果合格就编码，然后进行代码 Review, 然后进入测试阶段，根据设计来整理出测试用例，并设计测试数据，再次进行 Review, 合格之后，执行测试，提交测试报告，最后一步要整理出发布文档，该新功能发布时候使用。一开始我觉得很繁琐，但是一段时间后发现，这种模型是比较适合该现场的。由于参与 Review 的都是相关领域的专家，每一次 Review 都保证了该阶段工作的正确性，从需求到设计再到测试，一步一步踏踏实实走过来，很利于管理。而保险业务本身对系统的质量要求很高，现场的这种开发方式也有利于保证质量。在实际运用中，我稍微加入了点原型法，设计的同时作出一个原型， Review 的时候一起 Review, 增加了用户对设计的理解，我也能够确认对需求的理解是否有所偏差。给我的启示是，要在合适的场合选择合适的开发模型，有时候不妨在合适的地方大胆的进行一些增改。

2．    代码质量对系统维护的影响

        由于是要在现有的系统之上添加功能，现有代码的质量对工作的效果有很大的影响。一个逻辑清晰，功能划分合理的代码，修改和添加起来很舒服，如果遇到一个代码逻辑比较混乱，功能划分不合理的话，不光需要大量的时间去读懂代码，更重要的是你添加的代码也不得不屈从现有代码的设计，变得很垃圾。有时候我想重写以前的代码，但是又不敢冒这个险，不管怎么说人家现在工作的好好的，一旦修改不好的话，那就是大事故。所以，这里给我的启示就是，一开始就要保证好代码的质量，否则就会发生垃圾代码继续招引垃圾代码的现象。

3．    系统架构

        或许是一直开发中小型系统，对系统架构的理解就是程序，服务器和数据库。像保险业务这样的重要复杂的业务系统，还需要考虑如何保证业务间数据的传输，采用什么样的传输机制，数据的备份，故障时的恢复等等。总的来说，考虑的问题更多，视角更广。给我的启示就是，系统的架构一定要服务于业务，考虑一切问题的出发点只有一个，就是要保证系统正常稳定的运行。

4．    团队的管理

        给我的感觉该现场的 PL 很主动的跟团队里面的每个人沟通，适机的和每个人交流，答应过的事情一定做到。团队里的每个人也都很乐意提出自己的问题，想法和意见，整个团队的气氛很融洽，工作的心情很愉快。我想该 PL 功不可没。给我的启示是一个好的领导者应该懂得倾听下属的心声，确立权威的最好手段不是屈人，而是律己。