软件的灵活与扩展

从前做项目时，当面对简单变化时往往问题需要改代码并重新编译发布，后来就习惯地预测一些变化并将其交给用户。这样似乎系统更加灵活，或者说更像是一个产品，能够适应更广泛的应用范围，但实际情况却不完全是想象中的样子。

　　用户懂业务但不懂软件，甚至于对于整个业务结构单个用户也不完全清楚，相反随着项目的进行开发者反而会更加了解商务逻辑与未来的趋势。不过开发者眼中的系统逻辑总是过于完善和理想，这必将导致设计与开发常常走向极端，尤其是面对头脑简单或胆小的用户时更加糟糕。比如用户处于较高的领导层时，他通常不关心细节只是想要尽快看到结果，所以当你问要不要考虑XXX时他总是会说不用考虑，其实他是懒得解答你各种分支情况。相反如果用户是一个最低层的领导时，他担心将来承担一定责任便会非常留意系统的扩展，因此你在寻问以后会不会有某种业务变动及延伸时，他总是会说“是”唯恐漏掉任何东西。那么最终结果是什么呢？前者有了变化还是会通知你进行相应修改，而后者听取上级意见后也同样会通知你系统太复杂不好用。于是程序员总是处在一个弱势的地位，其实多数项目的加班不过是一种毫无意义的徒劳或重复，工作总是不理想，面对如此客户态度可想而知，于是相应的连锁反应像多米诺牌一样相互触发。这样的压力之下就会有两种极端，一是给出一个裸体般的系统雏形，要什么加什么，提什么改什么，最终需求爆炸无法控制；另一种则是给出一个彻底参数化的系统，什么都让用户配置，甚至包括一些逻辑在内，如此使得系统异常复杂且配置内容庞大难于维护，结果用户和开发人员都迷失在其中。

　　记得老一辈人说过我们应当要实事求是，现在真是深有体会，一劳永逸或彻底解决问题的想法在软件开发中太可怕了，而走极端则根是致命的。软件开发尤其是做项目，不可以总是太过考虑扩展与灵活，否则只能是一步步走地慢性自杀。对于客户来讲功能强大需要建立在易用的基础上，特别是对于目前我们国内的领导，他们开始会认同强大的功能，可一旦实施就必然抱怨嫌麻烦。在系统实施之前，要有完整的全方位的文档报告，什么多级的权限控制，什么强劲的安全措施，什么流行的技术内容，什么未来的扩展预测，什么多皮肤的界面，什么并发处理等等能上得都上，还要搞制度化的管理层次和级别，一个字系统要“酷”，向上级汇报时的口号是：不求最好但求最大。当系统实施正式上线之后情况就不同了，首先要取消制度，什么登录，什么安全设置，什么审核限定，什么警告提示等等能去的都去掉，还要把所有的操作移交给下面人，一个字就是要“简”，对开发者反馈时强调：不求最强但求最简。这样一个项目做下来怎么也疯几个年轻程序员，老一点的早麻木了，你还别抱怨，这就是职业特点。所以面对需求一定要冷静，一定要慎重，千万别太把用户的话全放在心上，毕竟你的工程你做主，用技术术语和开发周期来敷衍一下还是很有必要的。

　　也许有人不理解为什么极端灵活反而不好，道理很清楚就是太接近专业了，但用户并不专业。就拿多皮肤来说，有几个客户在系统正式运行后还整天调样子，何况没有几个用户有这能力。有人觉得适应用户的需求变化确用不着重编译代码是很酷的事，但很多情况是值不值得为一个几年后才可能变得东西做个界面来维护参数。还有个关键的问题，当参数太多时，你根本就找不到要改得那个，找到时也许已经忘了如何改，而为他们写帮助文档又是多么怕的事。当软件做得极端灵活时它的参数配置本身就可能已经成为了一种脚本语言，用程序语言经过一系列得开发却得到另一种语言，想想就是一种多么可笑的事。但实际上不管你如何灵活也无法适应所有变化，因为程序语言本身就有特定的范围。很多组件和控件好用正是因为它们有自己的领域和限制，使得我们节省了精力。所以，有时硬性地忽略或限定一些情况是相当有益得，万能钥匙可以打开很多锁但绝大多数人还是宁愿带着甚至上百把的普通钥匙。

原文转自：http://www.ltesting.net