首先要感谢“朱老忠”的支持！但更新速度较慢，真是对不住！近期天气恶化，染病了……

笔者学习网页编程，其实才一年半（在大学时也没接触过，大学时最感兴趣的是西方经济学，论文还拿过校级优秀～欣慰^_^），和大多数人一样都是自学，从DreamWeaver开始（工作后才学，比较少见），按自己买来教程一步步地做（难得有份闲心），从静态网页HTML到ASP到SQLServer2000一路学来，还弄了个卡片查询系统（IIS＋ASP＋SQLServer2000），为企业带来一定效益，因此还获了奖，甚是鼓舞！

为什么要学ASP.NET 2.0？实用！高效！新鲜！……如果新开发的项目还用ASP，维护起来肯定够呛！一人开发，能有多少时间编写文档？就是系统的修修补补、更更改改也烦死你！（系统建立了，相应更深入的需求就是一个接一个。）

ASP.NET 2.0要实现一个功能、完成一个页面，花的时间与精力远远小于使用ASP来达成，所以面对多变的需求，它可以更好地兼顾。

江水滔滔提到“在过程中，需求变化你是如何改动你程序的？”

在实际工作中，需求变化肯定会经常遇到的。首先一点就是，你通过自身的经验应该可以预测到一部分，这时，即使需求部门完全没有提出来，你也应该在系统中先做好铺垫。什么铺垫呢？在这方面我被我们的老总教育过的，她说“虽然他们没有提，但你应该事先想好嘛！系统不能写得太死，不是说你做错了，但你在设计系统时应该多弄几个开关，一旦业务需要，走这条路行，走那条路也行。灵活应变！”

我们老总虽然不懂技术，也不知道程序员职责就只是遵照需求办事的。不过，我觉得她说得很有道理，作为系统的设计者，灵活搭建构建系统、根据业务发展趋势去构思也是十分必要的。比如说，我在VIP客户服务系统中，就预先埋伏了“支行专管”这个角色。不知道读者是否还记得我在本系列（三）中提到过为用户表中加入“支行号”和“卡中心用户号”。当中的“卡中心用户号”主要是用来关联“客户经理”（支行）和“经办员”（中心）。而“支行号”实质在现有投产的系统中是没有作用的。那我为什么要留着它呢？这是我们可以预想得到的，卡中心经办才3人，管理或辅助本地区37个支行（400个网点）的800多客户经理，能应付得来嘛？我们是要考核客户经理的，而客户经理又归属于支行，这样实际考核的就是支行业绩。肉紧（重视这项服务）的是支行本身，那支行如何去管理这批人？系统中可没有这样的角色。而写系统需求的人是本中心的人，他们不会考虑这样的问题。但现在，却有支行的信用卡专管员向他们提出，希望拥有权限去监督客户经理完成的进度与情况。也就是说，该系统的功能不久又要增强了。

如果我没有事先想到这一点，那么新需求提上来时我就需要对所有涉及权限管理的数据表都重新设计，并增加字段。这样做，虽然也不是太复杂，但在进行结构更改时肯定又会遇到这样的遗漏或那样的冲突等。

因此，需求的变化最好你能先预见到，并在系统架构的底层设埋伏，这样敌来侵扰也能轻易搞定！

除了预测性，还必须讲究规划性！什么是规划性呢？也就是说你得明白什么样需求或功能，它可能在开发过程中会经常变动，什么样的功能在需求变更时影响极坏？经常变动的，就简略的先弄个Demo就行，要改就改。影响极坏的，要和提需求的人先反复探讨确定，尽量避免改动。还有一点，看过《世界是平的》你就应该知道，在拉平世界的十大因素中有“外包”这一项。什么时候外包？没太大把握实现的功能，或者甚至是可以外包就外包（最好不用你做^_^，毕竟要一个人在短时间内完成会做死人的）。系统中，业绩的统计采用了外包（每月用foxpro做完业绩统计导入系统），这样的小系统做OLAP分析有必要吗？当然，如果要做的，肯定使用SQL Server 2005中强大的功能，但实在是没有必要啊！

小结，面对需求的变化，本人认为可以运用预见性与规划性来应变。而具体的技术上或程序中的更改，讲到时我们再细述^_^