摘要：
前文提到我们应该需求驱动设计，那就直接来一个更干脆的做法，我们将需求表示为一个一个的用户故事，软件设计分别针对用户故事来做就行了，只要将用户故事逐个实现了，系统也就完成了。果然能这样做吗/p>
大纲：
1.什么是优秀的设计br>2.优秀的设计能节省项目工作量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感觉好才是真的好——用户体验设计
10.持续提升设计水平
本文章是系列文章之一，如果你还没有看过之前的文章，建议先看完前面的文章再看本篇，这样效果更好。
4.软件系统不是木桶型的
4.1 某种“需求直接驱动设计”的工作方法
案例分析：某敏捷实践项目小组的设计方式
某项目小组正在如火如荼地实践敏捷，任务看板上已经粘贴了很多“用户故事”，项目小组经常在看板前讨论问题：
1）讨论每一个用户故事的实现方法，并进行估算；
2）项目小组成员领取用户故事，负责实现该用户故事；
3）每天检讨进度情况和遇到的问题。
该工作模式给项目小组带来了新鲜的动力，调动了大家的工作热情，取得一定的工作成绩，但也带来了一些思考：
1）只要我们将每一个用户故事的设计想好并实现，每个用户故事都能通过测试，软件就能完成br>2）用户故事之间没有关系吗件设计不需要统筹考虑全部的用户故事吗/p>
4.2 软件是木桶型的吗/strong>
请看图：
图3.2 软件常见的工作模式
此图说明了以下问题：
1）需求并不是由一个个孤立的“用户故事”组成的，业务概念、业务流程其实是贯穿多个用户故事的，软件设计应该多从业务概念、业务流程的角度来思考；
2）表面上看上去一个用户故事对应一组界面，其实界面之间是很可能有重用和共享部分的；
3）业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应，存在交叉、共享和重用的可能；
4）数据操作层的代码，有可能是用工具自动生成的、通用的；
5）数据层中的某张表，通常会支撑多个用户故事而不是一个用户故事。
下面我在列举一下无法单独考虑的设计点，以下列出来的可能都需要从软件架构上做一个整体的考虑：
1）权限控制；
2）性能要求；
3）日志记录；
4）工作流；
5）全文搜索；
6）多数据库支持；
7）搜索引擎优化；
……
实际上很少需求是可以通过单独添加一些类，加一些数据表就搞定的，需要通盘的考虑。如果我们硬生生地将系统看成是木桶型的，去添加系统的木条，会让软件很丑很难用，存在诸多漏洞，而且工作量会更大。
4.4 小结
有时候由于目前能力有限，无法全面考虑需求，只能暂时按照木桶型的方式来设计系统，这样也不是不可以的，但要注意的是至少要做到：
1）用户信息和权限信息是共享的；
2）要杜绝安全漏洞。
木桶型的设计方法其实会让系统很难用、弹性很差、工作量更大，而且部分需求我们无法通过添加木条的方式搞定，我们需要尽快升级我们的设计水平，下一节开始为你介绍比较实用的软件设计方法。
本文是系列文章的第3篇，要做软件设计师一点都不简单啊，请留意后续文章！
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
www.umlonline.org创办人
来源：张传波
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！