软件设计 实践

1）什么是优秀的设计br> 2）优秀设计从分析需求开始
3）软件系统不是木桶型的
4）软件设计的“大道理”
5）规划系统的骨架——架构设计
6）打造系统的底蕴——数据库设计
7）细节决定成败——详细设计
8）用户感觉好才是真的好——用户体验设计

1）什么是优秀的设计/span>

1.1.  什么是优秀的设计/span>

某项目的设计文档评审会上，各路技术大牛进行了“热烈”的讨论，讨论的焦点是怎样的设计才漂亮！大家围绕着如何OO，如何高内聚低耦合，如何反转控制等话题进行了“热烈”的争论。

你觉得以下标准可以成为“漂亮”设计的标准吗/p>

1）高效
2）可靠
3）易用
4）安全
5）可扩展
6）兼容性强
7）移植性强
……

如果每次设计文档评审，我们都采用上述标准来评审，你觉得这个设计评审会有效果吗/p>

当时我参加了这样的一个设计评审会，觉得气氛很不对，照这样开下去，这个评审会岂不是变成了“神仙大会”！

于是我问了两个问题：

1）谁能说说这个项目的主要需求br> 2）这些需求，设计上是如何考虑实现的/p>

结果没有人能答上来！

我们从书本上看到的那些”通用“的设计标准，说得难听一点，就是废话！对实际的项目工作基本上没有实质用途！

请看下面4个例子，分别思考这4个案例的软件设计思路，你会发现上述“漂亮设计的标准”，真的是废话！

案例1：某项目要求在很短时间内完成，而且客户对系统的当前认识还是比较初步的，你打算怎样设计这个系统/p>

案例2：某软件公司接了一个“ 页+数据库”类型的项目，这类项目已经做过多个，但这次的业务却是新的，你怎样考虑这个项目的设计/p>

案例3：某软件公司已经成功为n个医院做了管理系统，现在需要为一家新的大医院做类似这个系统，你会怎样考虑这个系统的设计/p>

案例4：你接到一个任务，要做一个即时战略游戏，目标是要在当前游戏市场找中杀出一条血路，你怎样考虑这个游戏的设计/p>

4个案例各有特点，分别代表了4种“典型”：

案例1：需求很朦胧，工期很紧，技术上基本上没有积累。

案例2：需求是新的，但可以重用“ 页+数据库”的技术架构。

案例3：需求是类似的，技术架构也是类似的，相信你会直接重用之前的系统。

案例4：这是一个需要创意和高技术含量的游戏，而游戏软件的需求和技术都是充满挑战的。

上述4种情况，相信你采取的设计策略是不一样的，你可能会发现所谓的优秀设计没有固定的标准。

如果硬是要来一个优秀设计的标准呢/p>

我会这样说：就是做高性价比的设计！

一个优秀的设计应该具备以下特点：

1）优秀的设计都是需求驱动的，不熟悉需求就做出来的设计是不靠谱的；
2）优秀的设计应该是当前团队能理解能实现的，太超前的设计项目团队做不出来，这个设计只能是摆设；
3）优秀的设计应充分考虑当前各种限制条件，适当做出平衡，能保证达成项目的目标：
4）优秀的设计能尽量降低项目的整体工作量，让整个项目更加可控。

1.2.优秀的设计能节省项目工作量

设计案例：开发某线上 区 站

背景：某 区已经举办了多期沙龙活动，为了拓展沙龙的影响力，让更多朋友受益，树立良好品牌，将来实现盈利，有必要建立一个线上的 区 站。

该 站应有这样的功能：

1）发布各种活动信息。
2）发布业界新闻。
3）能开展线上沙龙活动，包括在线视频沙龙。
4）具备SNS 区，可汇聚人气。
5）每位会员有自己的博客，能维护自己的个人页面。
6）支持简体中文、繁体中文、英文三种语言随时切换。
7）支持全文搜索。

你打算如何设计上述系统呢/p>

你可能会问，有工期限制吗/p>

你说呢实项目一定会有工期限制的，这个项目你的工期只有1个月！

你可能会说：你当我是神仙啊，1个月有可能怎样死都死不出啊！

这个时候能帮助你的就是优秀的设计，优秀的设计有可能能让你用很少的工作量就做出来，优秀的设计也不一定需要你全部从零开发的，我们可以拿来主义！有不少开源软件是可以基本满足上述要求的，我们可以直接拿来用，这样你需要付出的工作量就少很多了。

我曾经用某开源软件做了这样的一个 站出来，但发现没有全文搜索功能，结果我想了一个“投机取巧”的办法，自己不写一句代码，直接利用谷歌的这个搜索功能“site:域名 关键字”，让谷歌帮我搞定全文搜索。当然这样做出来的效果还不是很完美，但至少我能在很短时间内能做出个大概啊，如果自己开发还不一定能做出这样的效果呢！

小结：

受工期限制、受能力限制等制约因素，十全十美的设计基本上是很难做到的，但如果因为赶工期而在软件设计上节省时间甚至是直接忽略这步，其实是得不偿失的。在软件设计上“节省”1小时，可能会让你将来多投入成倍的项目时间；越是工期紧，越需要冷静思考软件的设计，合适的设计能大大地降低项目工作量，让你后期的工作轻松很多。

2）优秀设计从分析需求开始

设计应该针对需求来做，这个大道理似乎人人都懂，但实际操作时往往就不是这样。所以我们 也不说大道理，直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始。

2.1 案例挑战：考勤系统的软件设计

某公司要做一个内部用的考勤系统，希望达成以下目标：

1）规范员工的上下班、请假、外出工作等行为。
2）方便计算员工的薪金。
3）方便管理各种带薪假期。

你如何考虑本系统的设计呢/p>

你可能会说：我靠，才三句话的需求，怎样做设计呢/p>

说得太好了！我们做软件设计的，第一步并不是直接去设计，而是分析需求！

2.2 如何分析需求/strong>

当你接受一个项目的设计任务时，可能会遇到比较尴尬的情况，那就是需求有问题！

具体的情况可能有：

a）需求很简单，几句话或者是一页纸的需求。
b）需求很详细，可能有几十页甚至上百页，这些需求是招标书中提供的，或者是客户直接提供的。不要以为有这么多需求是好事，这些需求通常是前后有点矛盾、逻辑有点混乱，甚至是不知所云滴！

c）你们有专门的部门或者专职完成了需求工作，提供了一份需求文档。你也不要以为这是好事，因为很可能会出现这样的情况：需求文档的提供者认为自己写的需求文档很牛逼，水平很高；但负责实现的开发部门认为该文档质量太差，比方说：不考虑实现的可能性和难度，没有考虑到客户的真正需求等等。有时候甚至出现开发部门忽略掉需求部门，直接找客户重新调研，重新编写需求文档的情况。

上述三种情况一句话总结就是：需求的质量有问题！

我们需要重新分析一次需求，先从业务角度审视一次，然后再从软件设计的视角审视一次。通常我们需要按顺序思考以下问题：

A）什么人会使用这个系统 用例图
B）不同的人将会使用这个系统的什么功能 用例图

C）还有哪些不确定或不具体的需求点 用例图
D）哪些需求对技术提出了怎样的要求用例图
E）系统的大致架构应该如何考虑 部署图

下面开始我们看几个图，按顺序逐一思考一下上述的几个问题。本小节回答问题1、2，后面的小节回答其他问题。

A）什么人会使用这个系统/span>

不少技术人员分析需求时往往是技术的视角，当你问他系统有什么用户时，你可能得到的结果有两种：

a）没有什么用户啊，所有人都是用户，因为系统只需要配置一下权限，谁都可以用。
b）系统有两种用户，就是：用户和管理员。

我们从业务的角度来审视一下考勤系统的可能用户，请看下图：

图2.2 系统的需求分析

图2.1和图2.2都是UML的用例图，两个图加在一起比较完整系统地表达了以下问题：

a）什么角色会用本系统/span>
b）这些角色通过本系统分别能干什么事情/span>
c）角色之间有可能会有继承关系，请留意父类能干的事情，子类也能干，例如：employee可以打卡，manager也可以打卡，尽管图2.2中manager没有直接与”打卡“相连，但图2.1中已经说明了manager继承employee。

UML是需求分析的有力工具，我的工作中很喜欢用UML。但你的工作中、你的需求文档中可能会没有UML图，不管你们是否用UML图，分析需求时都需要从业务的角度思考这些问题：

a）什么人（角色）会用这个系统/span>
b）这些人（角色）分别需要用系统的什么功能/span>

需求分析其实是一个复杂的高难度的话题，回答上述两个问题仅仅是需求分析的第一步而已，我们还需要深入分析业务，包括业务流程、业务数据结构等等。如果之前的需求工作不到位，就需要我们立马开展软件设计工作，其实将会埋下很多地雷，后患无穷。

2.3 找出设计关注点

本小节我们回答这两个问题：

C）还有哪些不确定或不具体的需求点/span>
D）哪些需求对技术提出了怎样的要求/span>

软件设计师需要有敏锐的需求及设计触觉，看着图2.1和图2.2 嗅出一些问题，你能嗅出一些问题吗/p>

请看下图：

图2.4 系统架构的考虑

图2.4是UML的部署图，这个图比较粗糙，而且为了降低大家阅读难度，我仅仅是用了部署图的最基本最少的语法来表达。

图2.4中的每一个立体的矩形，表示的就是物理上或者是逻辑上的一台设备，设备之间 有物理连接的话就用线条连接，每台设备中”{ }“括起来的文字是对该设备的进一步说明。

图可能是表达设计的最好方式，建议大家用UML，表达系统架构时，用UML的部署图、组件图和包图是比较合适的。我们设计的系统多数是分布式系统，不是单机系统，用部署图来表达分布式系统的架构设计可能是比较合适的。

图2.4针对图2.3中提出的问题进行了初步的回应，图2.4 就是一个初步的架构设计，当然后续我们还需要继续细化这个设计。

2.5 小结：如何需求驱动设计/span>

本篇的例子告诉我们：

1）优秀的设计是需要从分析需求开始的。
2）需求的质量可能有问题，那么我们需要从业务的角度重新审视一次。
3）从设计的角度审视需求，我们会提出很多需求细化及设计方案的问题。
4）架构设计是全面考虑各种需求、项目的工期限制预算限制，还有项目组人员水平后综合做出来的一种平衡。

3）软件系统不是木桶型的

3.1 某种“需求直接驱动设计”的工作方法

案例分析：某敏捷实践项目小组的设计方式

某项目小组正在如火如荼地实践敏捷，任务看板上已经粘贴了很多“用户故事”，项目小组经常在看板前讨论问题：

1）讨论每一个用户故事的实现方法，并进行估算；
2）项目小组成员领取用户故事，负责实现该用户故事；
3）每天检讨进度情况和遇到的问题。

该工作模式给项目小组带来了新鲜的动力，调动了大家的工作热情，取得一定的工作成绩，但也带来了一些思考：

1）只要我们将每一个用户故事的设计想好并实现，每个用户故事都能通过测试，软件就能完成br> 2）用户故事之间没有关系吗件设计不需要统筹考虑全部的用户故事吗/p>

3.2 软件是木桶型的吗/strong>

请看图：

图3.1 软件是这样工作的吗/p>

一般我们的系统会采用分层架构，以三层架构为例子：