转载自:http://blog.csdn.net/fireball1975/article/details/18767793
摘要:
前文提到我们应该需求驱动设计,那就直接来一个更干脆的做法,我们将需求表示为一个一个的用户故事,软件设计分别针对用户故事来做就行了,只要将用户故事逐个实现了,系统也就完成了。果然能这样做吗?
大纲:
1.什么是优秀的设计?
2.优秀的设计能节省项目工作量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感觉好才是真的好——用户体验设计
10.持续提升设计水平
本文章是系列文章之一,如果你还没有看过之前的文章,建议先看完前面的文章再看本篇,这样效果更好。
4.软件系统不是木桶型的
4.1 某种“需求直接驱动设计”的工作方法
案例分析:某敏捷实践项目小组的设计方式
某项目小组正在如火如荼地实践敏捷,任务看板上已经粘贴了很多“用户故事”,项目小组经常在看板前讨论问题:
1)讨论每一个用户故事的实现方法,并进行估算;
2)项目小组成员领取用户故事,负责实现该用户故事;
3)每天检讨进度情况和遇到的问题。
该工作模式给项目小组带来了新鲜的动力,调动了大家的工作热情,取得一定的工作成绩,但也带来了一些思考:
1)只要我们将每一个用户故事的设计想好并实现,每个用户故事都能通过测试,软件就能完成?
2)用户故事之间没有关系吗?软件设计不需要统筹考虑全部的用户故事吗?
4.2 软件是木桶型的吗?
请看图:
图3.1 软件是这样工作的吗?
一般我们的系统会采用分层架构,以三层架构为例子:
1)最外面的是表现层,主要就是程序的界面了;
2)界面后面就是我们写的程序;
3)程序后面就是数据库。
按照上述的“需求直接驱动设计”的工作模式,只要有新的需求,其实就是有新的用户故事,那么在这个用户故事驱动下,直接设计对应的界面、程序和数据库表就行了。这样的框架下工作,我们可以无惧需求变更。软件就是一个大木桶,需要实现更多需求,那就增加更多的木条就可以了;如果要修改需求,那就修改某条木条就可以了!
我发现很多系统是按照这样的思路来设计的,举一个某电信网站的例子。
我到该网站交费,发现有免费宽带提速的服务,需要输入电话号码来确认该电话线路是否具备提速的条件。我觉得很郁闷,明明我已经登录系统了,系统应该知道我的电话号码,为啥还要我填一次?好吧,为了免费提速,我就输入一次电话号码吧,提交后系统告诉我一个订单号,告诉我大概什么时候会搞定之类的信息。过了几天再次上这个网站,免费提速宽带的窗口又弹出来,我很烦关掉它:我已经提交订单了,还干嘛一直提示我!但它又继续弹出来,我烦了,那再提交一次订单吧,居然可以提交成功!被这样的系统折腾几次其实也不算什么,只要能免费提速也就值了,但最终的结果是电信一直没有帮我提速,我也懒得去投诉了,按照我以往投诉的历史经验,那是折腾自己的事情!
很多商家在不同时期有很多的促销等市场活动,需要软件系统来支持。我们按照木桶原理来做系统的话,看上去似乎事情变简单,但功能与功能之间其实存在很多交叉点,不考虑这些情况,会导致很多问题:
1)首先是用户体验超级不爽。有些系统甚至没有做到用户信息和权限信息共享,就好像上述这个电信例子。
2)没有能发现功能与功能之间的“重用”部分,没有从架构上和数据库底层上认真规划,其实会带来更大的总体工作量。
3)会留下一些系统漏洞甚至是安全漏洞,万一出问题后果很严重。
4.3 软件的内部架构是怎样的?
请看图:
图3.2 软件常见的工作模式
此图说明了以下问题:
1)需求并不是由一个个孤立的“用户故事"组成的,业务概念、业务流程其实是贯穿多个用户故事的,软件设计应该多从业务概念、业务流程的角度来思考;
2)表面上看上去一个用户故事对应一组界面,其实界面之间是很可能有重用和共享部分的;
3)业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应,存在交叉、共享和重用的可能;
4)数据操作层的代码,有可能是用工具自动生成的、通用的;
5)数据层中的某张表,通常会支撑多个用户故事而不是一个用户故事。
下面我在列举一下无法单独考虑的设计点,以下列出来的可能都需要从软件架构上做一个整体的考虑:
1)权限控制;
2)性能要求;
3)日志记录;
4)工作流;
5)全文搜索;
6)多数据库支持;
7)搜索引擎优化;
……
实际上很少需求是可以通过单独添加一些类,加一些数据表就搞定的,需要通盘的考虑。如果我们硬生生地将系统看成是木桶型的,去添加系统的木条,会让软件很丑很难用,存在诸多漏洞,而且工作量会更大。
4.4 小结
有时候由于目前能力有限,无法全面考虑需求,只能暂时按照木桶型的方式来设计系统,这样也不是不可以的,但要注意的是至少要做到:
1)用户信息和权限信息是共享的;
2)要杜绝安全漏洞。
木桶型的设计方法其实会让系统很难用、弹性很差、工作量更大,而且部分需求我们无法通过添加木条的方式搞定,我们需要尽快升级我们的设计水平,下一节开始为你介绍比较实用的软件设计方法。