拥抱变化的需求

　　最近越来越深感到，在企业应用软件开发这个领域里面，最复杂而又没有现成解决办法的事情其实是各种相似但又不完全相同的需求对设计带来的冲击，有的产品还没开发完就黄了，而有的从dos时代一直用到现在。是什么带来如此巨大的差异？我觉得想要解答这个问题可以参考进化论，只有适应环境变化的生物才能生存，只有适应需求变化的软件才能长久。

　　学校里通常只教学生技术知识，不会教学生怎样设计，因为老师如果一毕业就当了老师，那他基本上不太可能会设计可靠、可伸缩、可扩展的软件，何谈指导学生。

　　个人认为应对需求变化，一种不好的解决方式是妄图一切都用配置来解决，比如有的项目负责人比较忌讳产品重新编译，认为用配置解决需求问题的话测试开发可以少点时间，只要不重新发布，那就算一个产品，就可以减少测试，省事。但实践中我发现，如果有这样一种导向——“只要需求变了不编译代码的解决方案那就是好的解决方案”，往往最后的结果并不理想。首先，开发时我们需要思考哪些地方当前这个项目可以用未来改改配置又能完成另一个功能，对配置和多余功能的提前实现将有很大一部分变为过度设计的部分，这些部分无论从设计、实现、测试等各个环节都给大家带来一些多余工作量，而且只有对所有配置项的各种组合进行过周密的测试，才敢在以后的项目中应用新配置，否则某个未来要用的未测试配置项实际上是形同虚设——谁也不敢用，用了还有可能要重新编译，所以这种方式实际上已经是把未来要做的事现在做了，根本没有省去什么工作量。另一种例子就是试图把程序写的非常“智能”，可以自动干这个、自动干那个，改改配置就可以让它变得无所不能，

　　比如我们经常遇到对大量数据进行多字段组合查询分页的问题，针对不同的情况开发人员必定要对数据库进行一些不同的索引优化。极端一点去思考，如果配置能解决问题，还要程序员干什么？如果没有良好的设计，配置只能是在非常狭窄的范围内适应某些需求变化，但对推进软件进化来说，用配置解决需求问题其实是饮鸩止渴，需求和设计的阻抗会导致极其复杂的配置管理，最终回到一个解答——大面积重写（完全或模块级）。最根本的解决方法应该是让软件进化起来，利用良好的可扩展性设计，举一反三的发现未来可能的变化，拥抱变化的需求。