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

"客户说是这样的!","客户根本没这个需求!"

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

 

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

 

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

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

 

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

 

当然不是!

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

posted @ 2010-05-09 01:40 winter-cn 阅读(...) 评论(...) 编辑 收藏