摘要：

十几年前刚毕业不久，我从事第一份软件开发的工作，要完成一个项目，但没有任何软件设计的思路，于是请教我的老板。我的老板给了我两种思路：1）先假设软件已经做出来了，想好软件的外在表现，由此倒推软件的实现方法；2）思考程序的数据结构，先设计数据库，然后再搭建软件的上层建筑。老板给了我很大的启发，随着工作的开展，后来我又发现了第3种设计的思路。本文将为你分享三种软件设计的思路：1）由顶而下；2）由底而上；3）由中间到上下。

大纲：

1.什么是优秀的设计br>2.优秀的设计能节省项目工作量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感觉好才是真的好——用户体验设计
10.持续提升设计水平

本文章是系列文章之一，如果你还没有看过之前的文章，建议先看完前面的文章再看本篇，这样效果更好。

5.软件设计的“大道理”

5.1 我的第一次商业软件的设计经验
1999年刚毕业不久，我从事第一份软件开发工作，当时要负责一个大型桌面软件，但不知道应该如何开展软件设计工作，于是向老板请教。老板也仅仅是年长我几岁，不过公司的核心产品是老板开发的，老板说他其实也没有什么系统的方法，不过有两种思路供我参考： 1）先假设软件已经做出来了，想好软件的外在表现，由此倒推软件的实现方法；
2）思考程序的数据结构，先设计数据库，然后再搭建软件的上层建筑。 上述的两种软件设计思路，相信很多有软件设计经验的朋友都能体会到。后来我又体会到第三种的设计思路，后文将会为你分享我对这三种设计思路的一些体会。

5.2 N层架构是怎么回事/strong>
这三种设计思路都与软件系统的N层架构有关系，我们以常见的四层架构为例子，请看图：

图5.2 四层架构与实体类
补充说明一下什么实体类/span> 实体类通常是一个只有属性没有方法的类，通常我们会将某一业务对象的数据装在一个实体类中。例如：某请假单实体类，该类可能有请假人姓名、请假起止时间、请假类别和请假事由等属性。

5.3 “由顶而下”的设计思路
看了图5.1和图5.2，你大概就清楚了什么是软件的“顶”么是软件的“ 底”/span> “顶”就是表现层，“底”就是数据层。那么“由顶而下”的设计思路，其实就是先想清楚软件的表现层，然后再思考逻辑层、数据访问层、数据层的实现。 前文我们提到要“需求驱动设计”，这个说法有点笼统，我们需要进一步思考：“什么需求”驱动“什么设计”/span> 请看下图：
图5.4：由底而上的设计思路
这个图也分成了上下两部分，上部分的内容其实和图5.3是一样的，只是左右顺序不太一样而已。

5.5 “由中间到上下”的设计思路
这种设计思路是我从事软件研发工作若干年后才认识的，当时是因为项目出现了特殊状况，为了应对这样的状况而采取的一种设计方法。
案例分享：客户要改SQLServer为Oracle 签订合同时，我们和客户约定的项目技术架构是.net+SQLServer，当时客户没有反对，我们就按这样的技术架构完成了系统，并且部署上线。但是不久客户居然提出了这样的要求：要求我们使用Oracle数据库，而不能用SQLServer数据库！我们通常是按照“由底而上”的思路来设计软件的，如果数据库要更换，基本上整个软件就等于重做！ 如果你遇到这样的状况，你会怎么办呢不能按需求变更来处理呢有客户愿意付钱，我们就愿意干！但客户愿意付钱吗可是要付推翻重做的钱啊！！
最后我们的领导决定免费重做，领导决定免费重做的原因是： 这是公司的一个核心项目，我们期望这个项目将来能产品化，能持续赚钱。但我们技术选型主要是根据我们当前的技术情况来决定的，没有充分考虑客户的情况。客户是某重要行业的企业单位，单位体制内的所有企业基本都是用Oracle的，但我们选择“视而不见”，选择了我们最熟悉的SQLServer来开发系统，其实迟早是要遇到问题的。客户除了用我们的系统，还会用其他更大型的更重要的系统，客户的其他系统基本上都是使用Oracle数据库的。所以如果我们要在这个客户领域打开市场，将项目做好，就有必要将系统改造为Oracle数据库。
但是我们已经有部分客户使用了我们的基于SQLServer的系统了，将来也有可能会有部分客户要求用SQLServer，所以我们领导决心改造软件的架构，要让我们的软件可以支持SQLServer，也可以支持Oracle！于是我们按照“由中间到上下”的思路，重新打造了软件架构，请看下图：
图5.6 由中间到上下的系统架构
图中见到数据操作层接口有两种不同的数据库实现，分别是SQLServer和Oracle，如果要考虑第三种数据库，那么再增加一个实现就搞定了，而系统的上层建筑（表现层、逻辑层）不需要改变。
这样的设计方式看上去很酷，是不是应该所有系统都要考虑用这样的方式来打造呢/span> 不是滴，这样的设计方式是有缺点的： 1）系统将不能充分利用数据库的特性，一般会禁止在数据库中写存储过程、触发器、甚至是视图等，程序的的性能其实会降低；
2）因为不能充分利用数据库本身的特性，所以大部分甚至是全部的业务逻辑只能靠程序搞定，这样其实增加了程序的复杂度和工作量。
所以每种设计方法都是有针对性的，都很难做到十全十美，一般只能针对主要矛盾做出一些取舍。

5.6 小结
如果系统没有多数据库的要求，我会比较建议你用“由顶而下+由底而上”的设计思路；如果程序需要支持多数据库，那么可能考虑“由中间到上下”。上面介绍的三种设计思路，其实在实际工作中我们往往不会只选其一，往往是结合了多种思路的。不要局限自己的思路，软件设计的可能性是无穷的。

本文是系列文章的第4篇，要做软件设计师一点都不简单啊，请留意后续文章！

作者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

www.umlonline.org创办人

来源：张传波