后期维护的一点心得

近半年的主要工作还是对项目的后期维护，现在经手的项目从建立到如今也有将近一年半多的时间了，感触颇多。

当时记得项目经理语重心长跟我说，跟客户交流，沟通，直接到现场了解客户需求，是程序员技术提高的一个快速成长阶段。说真的，那时还真的有点不以为然，不就是改改细节嘛，会有什么难度呢

可随着与不同客户的交流的深入，才发现自己想法的幼稚。

单就项目而言，因为参与了项目的整个过程，包括需求分析，框架搭建，项目的核心编程，后期的维护测试整个阶段，就好比自己养着的小宠物，看着它长大，为它的健壮成长而欣慰，为它的生病而着急。

在与客户的沟通过程中，发现很多想法都太想当然了，说是说站在客户角度，可因为角色的错位和对项目的熟悉，很多时候还是以开发人员的思维去模拟客户的思想。而最大的区别莫过于界面的美观性和便捷性。

回想项目开发过程，在开始时，主要还是考虑程序的正确性，很少考虑到用户的心理，或者说以用户的思维去测试项目的正确性。比如以用户对项目的不熟悉程度，很可能在做一个操作后又进行了后退操作，特别保存的时候，就要防止程序的重复提交，删除也同理。有时候测试的结果很蹊跷，让人找不到头绪，很可能第一次进行某个操作是正确的，第二次就会报错，而第三次又是正确的，又或者报错的概率是随机出现的，这时候就需要静下心来耐心的测试。现在想想自己急躁的性格也在项目开发过程中磨合了好多，这也是一个收获吧

还有，在测试的时候，如果进行某个操作自己都觉得很不方便，特别是批量操作的时候，就要考虑优化程序了。同样，如果类似的代码在好多模块重复出现，就要学着去重构，或者将代码的抽象部分提取出来做成接口封装。

上半年学的模式其实很多都是平时项目中接触过的，而模式的学习只是系统的将平时的感想梳理了一遍，有了一个更加清晰的概念。

还有对客户的要求，刚开始是有求必应，客户说改什么就改什么，可能同一个问题会重复改来该去好几次，后来觉得这样效率太低了。在客户提出修改时，有必要要求一个正式的书面文档，一般是邮件，同时深入了解客户的需求。很多时候客户的要求其实很简单的，换个方式当前的功能就能够实现，这时就要看你的沟通能力了，如何在让客户对你提出的建议采纳的同时，还不能产生任何的不满。

同时，充分利用客户的沟通过程也是一个关键点。不少时候需要到客户现场进行改动，在跟客户交谈过程中，提出平时开发项目过程中的疑虑，一般客户是很开心你向他们请教问题的。在项目应用的逻辑上，比如档案系统，档案管理员对档案的了解就远胜于一般的非档案专业的人了。

 

这些只是在后期维护中跟客户交流的一些心得，可能很多人都已经亲身经历过了

还好，写的不是很罗嗦，呵呵