设计：依赖WORD还是依赖WORLD？——谈应对需求变更的软件设计

"客户说是这样的！"，"客户根本没这个需求！"

需求对程序员而言，往往犹如圣经，客户说了，我们就要这样做。但是，往往客户明天就变了一幅嘴脸，原本明明说好按钮在下面的，结果现在一定要挪到上面去，明明不需要保存颜色的，结果现在一定要把颜色也加上。于是我们从头改到尾，从下改到上，好不容易改完，好了，客户明天想法又变了！怎么办？继续改！

 

好吧，厌倦了这种可怕的生活了吧，于是我们希望应对这种问题，于是我们决定，通过设计一个完美的架构来解决问题，我们希望，当客户需求变更的时候，只要改改配置就可以应对。客户不是一会喜欢让Tab Header在上面一会喜欢让Tab Header在下面吗？那好，我就让我的TabControl支持上下左右四种模式。客户不是总是希望这个按钮能点，那个按钮不能点吗？那好，我们就做一个权限到按钮。

 

这下好了，不过多出的开发时间怎么办？组里的老程序员/架构师这个时候跳出来说，"小X啊，你要理解客户需求啊，凡是客户不要的，我们都不做。"，要么就是"你这样做，影响性能的啊！"，而且很可能，这些话会成为他对你工作的不良评价讲给老大听。

是不是很无奈？设计可扩展的程序，易维护的系统，就仿佛永远是蠢驴面前用棍子吊着的胡萝卜，永远因为项目进度，不能实施。你的才华，永远无法被上司所理解。

 

问题出在哪里呢？难道这就是软件行业的现状么？

 

当然不是！

 

其实很多人把"易于扩展的设计"曲解成了"包罗万象的设计"。 我们要做的，不是穷尽用户之所想，替用户设想所有可能需要的东西，然后等用户提出需求的时候，从中挑出一部分给用户，而是更好的用程序反应系统的内在联系，在抽象过程中谨慎地保持和现实世界一致的可扩展性。

 

是的，客户要你数农田里的胡萝卜，你的程序里不一定要有农田和萝卜坑这两个类。客户要你计算小鸟在火车中间飞的次数，你的代码里面也不一定要出现小鸟和火车字样。

 

应对需求变更，不是衡量设计优劣的标准，即使再好的设计，当你的客户要求把ERP系统变成学生选课系统的时候，应对的来么？

 

衡量设计的外在标准很多。比如，模块之间应该是高内聚，低耦合的；层与层之间，应该是单向依赖的；依赖关系应该是抽象的而非具体的；组件应该是易于复用的。这些是一个良好的软件设计必然体现出的特性。而从本质上，设计应该更好反应问题的本质。

 

程序员应该从客户的需求描述中理解客户面临的问题，进而设计程序去解决问题。前一阵爱民在w3ctech上讲过，抽象分为共性抽象和本质抽象。不论使用哪种抽象方法，抽象过程都是去除不必要的信息的过程。从场景中抽象用例，从用例中抽象特性，按特性设计程序，这样设计出的程序，才能保持良好的可扩展性。

 

程序员应该是比任何人都了解这个世界的人，写程序的过程就是不断地抽象现实中的需求，并且用编程语言表达出来。程序设计之好坏，取决于程序员的抽象能力。程序设计之取舍，在于抽象的范围和粒度。

 

PS.鉴于本文抒情性质明显，不幸被提到以及被含沙射影的各位千万不要扁我。