软件设计是怎样炼成的（7）——细节决定成败（详细设计）

richsky 2014-03-13

展开全文

摘要：

当我们需要考虑类、类的内部细节、类之间的关系时，这时我们已经开始做详细设计了。详细设计不一定是一份文档，也不一定是Word文档，详细设计也不一定叫“详细设计”，有时候“编码就是设计”也是未尝不可的。对于MIS类型系统来说，架构设计和数据库设计做好的前提下，详细设计的难度其实是比较小的了，但MIS系统会有一些特殊的需求点，我们需要识别出来并想清楚应对办法。如果你做的软件是高技术含量的非MIS系统，情况将会更加复杂。

大纲：

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

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

8.细节决定成败——详细设计

8.1 什么是详细设计？

当我们需要考虑类、类的内部细节、类之间的关系时，这时我们已经开始做详细设计了。详细设计不一定是一份文档，也不一定是Word文档，详细设计也不一定叫“详细设计”，有时候“编码就是设计”也是未尝不可的。下面是我的一些最佳实践：

实践一：模块设计

我早期的一些项目会写一份详细设计文档，但后来的项目我会将详细设计文档分拆为N份模块设计文档了，这样做的两大好处是：

1）一份详细设计文档太大，不利于阅读，不利于指导编码工作，分拆后就好多了；

2）N个模块设计的任务可以分派给不同的软件设计师（或程序员）来负责。

实践二：代码就是设计

有时候我会“偷懒”，我觉得没有必要再写什么设计文档，直接在开发工具中定义好类，写好类的公开接口，写好注释等等，这时我其实就是在做详细设计的工作，我将代码框架写好后，才写具体的实现代码。这种工作模式其实就是将详细设计与编码实现融合在一起了，效果和效率更好！当然不是说不再需要写Word文档格式的详细设计了，对应比较复杂的详细设计，一般还是需要通过另外的文档来描述一下比较好。

但可能会有一种比较详见的“特殊”情况：你可能会遇到开发人员死活写不出Word文档格式的详细设计，你和他沟通多次后，他还是写不出有质量的Word文档格式的详细设计，这时你不如让他直接写代码，先写个框架看看，然后你通过评审代码来修正他的设计。

实践三：Demo就是设计

设计逻辑复杂时，可能需要文档来应对，但文档毕竟是纸上谈兵，可能最切实的办法是做一个 Demo 实现你的算法和设计思路。只要 Demo 是 Work 的，就可以将这个 Demo 的代码重用到实际的项目中。

举一个例子：曾经某项目中需要写代码解决判断一个点是否在多边形内，算法有点麻烦，光写文档说算法没有实质的价值，于是我用了半天时间写了实现的代码和测试的代码，将这个Demo提交给项目组。

实践四：“无”详细设计

无详细设计的意思不是真的不考虑详细设计了，而是对于这种情况我们已经驾轻就熟了，几乎是闭着眼睛都会做了，所以我们就“无”详细设计直接编码了。

8.2 详细设计的基础

我曾经评审过一份设计文档，该文档内容详细、思路清晰，清楚描述了某些技术环节的实现办法，而且实现办法都是可行和有效的，这个文档可以算是一份比较好的详细设计文档了。但可惜的是，整个项目只有这样的一份设计文档，从全局来看这个文档只解决了局部问题，缺失了一些核心内容：

1）没有架构设计的的内容；

2）没有数据库设计的内容；

3）系统的需求很复杂，大部分的需求没有对应的设计考虑。

前面的文章曾提到，我做过的项目一般至少会有一份概要设计文档，详细设计文档不一定是必须的。详细设计固然重要，但针对整个系统的全面考虑更加重要，详细设计之前应该具备以下条件：

1）应针对全部需求（包括功能性和非功能性的需求），系统需要有整体上的考虑，也就是前文提到的架构设计。

详细设计需要考虑类、类的内部细节、类之间接口等，这些是需要符合系统的总体架构和分层架构的。

2）应有数据库设计。

如果没有数据库设计，建筑在数据库之上的代码是很难写的。当然如果你是用“由中间到上下”的设计方法的话（什么是“由中间到上下”？请参考前面的文章），数据库设计没有，只要有中间层的建模的话，表现层和逻辑层的代码还是可以写的，但数据库操作层的代码还是依赖于数据库设计的。

3）部分情况下，还应该有部分或全部的用户体验设计（用户体验设计下一篇会分享）。

用户体验设计主要考虑的是软件的表现层，最能充分体验“由顶而下”的设计思路，将会直接影响具体的代码实现。

一般情况下我们应该在架构设计和数据库设计的基础上进行详细设计，否则很可能会让我们仅仅关注了局部的问题，而没有抓住其他更加重要的问题和全局的问题。如果没有架构设计和数据库设计，直接详细设计是不是一定不可行呢？有以下的一些特殊情况（不限于此噢）：

1）如果果你的情况是在原有系统上升级改造，系统原有的架构和数据库设计基本不变，那么直接进行详细设计是合适的做法；

2）有时候有些局部问题虽然很“局部”但又相当特殊或重要，哪怕没有来得及完成架构设计和数据库设计，也可以先进行详细设计的。

后文我们先从正常思路介绍详细设计，也就是先有架构设计和数据库设计再有详细设计，然后再分享一些上面第2）点的情况。

8.3 详细设计是架构设计的延续

前文的架构设计提到我们要对系统进行两个层次的拆解，分别是：

第一层拆解：思考系统需要开发什么软件和数据库等；

第二层拆解：考虑组件（Component）、代码包、某个分层等等，可能是“物理分拆”也可能是“逻辑分拆”。

不太记得或者看不懂的朋友，请先看看前面的文章啦。

而详细设计其实就是：

第三层拆解：进一步细化出类、类对外接口、类的内部细节等。

通常我会用UML的顺序图（Sequence Diagram）来表达“第三层拆解”，请看一个简单一点的图，了解一下顺序图。

图8.1 详细设计-顺序图1

我们通过这个图了解两个事情：

1）顺序图的基本语法；

2）顺序图如何表达详细设计。

这个图表示的是用户在某个查询页面输入查询内容、点击查询按钮等这些用户交互及背后的程序设计。通常顺序图最左边画的是用户，仅次之是软件的表现层的某个页面（界面），用户与表现层的之间的交互，会导致表现层后面的类的一系列动作。这个图还算比较简单，请看下面这个我在N年前完成的某项目中的其中一个顺序图：

图8.2 详细设计-顺序图2

架构设计需要考虑全部需求后设计出来，也就是说”全部需“求驱动架构设计，当然某些特殊的需求点需要特别关照；数据库设计主要是业务概念模型驱动的，业务建模及进一步提炼可以帮助我们设计出更有弹性的设计。那详细设计是不是仍然需要”需求驱动“呢？这是必须的！

我们可能用用例（UseCase）、用户故事（User Story）或者是功能点等方法表示需求，不管怎样的表示办法，最终都会拆解为一条条比较细的需求。每一条需求具体如何实现呢？顺序图就是表达这个实现方法的好工具！图8.1 和图8.2 分别说明的都是某个需求点的实现方法，图8.1 是查询用例的详细设计，图8.2 是修改材料设备信息的详细设计。一个系统的详细设计，就可以用类似图8.1和图8.2的图逐一表示出来。

我们通过下图再充分理解一下需求如何驱动详细设计：

图8.3 详细设计-顺序图3

上图红色框框部分的内容是需求，用户和系统界面之间的交互设计是对需求的进一步细化；蓝色框框部分是在需求驱动下的程序实现，此图实现部分比较简单，大部分的程序实现逻辑都会比上图复杂，会涉及到逻辑层、数据操作层还有一些共用模块之间的调用等等。详细设计除了要需求驱动，同时也要需要符合架构设计，代码也需要基于已有的数据库设计，换句话说就是详细设计是需求、架构设计及数据库设计三者同时驱动的。

本小节所列举的详细设计的例子都是MIS类型系统的例子，基本上围绕数据库的增删改查进行，设计难度其实并不是很大。前面已经提到，如果对于已经很熟悉的情况，你没有必要再用顺序图来画一次了，直接可以”无”详细设计；但如果你的团队成员还不是很熟悉数据库的增删改查，或者实现逻辑比较复杂，这样就很有必要进行详细设计了。

本小节的例子比较“常规”，老鸟可能觉得没啥难度，下小节的难度将会增加。

8.4 详细设计是解决局部问题的良方

前面提到，有些局部问题虽然很“局部”但又相当特殊或重要，哪怕没有来得及完成架构设计和数据库设计，也是需要先进行详细设计的。

举三个例子：

案例1：针对网络负载平衡的特殊考虑

某客户的Web服务器采用网络负载平衡，有两台Web服务器，这与我们惯常的一台Web服务器场景很不一样。我们打算使用公司的框架来开发这个系统，但这个框架的其中一个地方很可能会出问题。框架使用了静态变量用来记录数据库中ID的最大值，当增加一条记录时就 ID_Max = ID_Max + 1，将新的 ID_Max 作为新增加记录的ID。这样在两台Web服务的场景下，就会有两个静态的 ID_Max，两边都很可能会出现不准确的情况，导致数据插入到数据库中时出错。本身这个修改并不算复杂，但我们需要同时考虑兼容框架，因为这个框架是同时支持 SQLServer 和 Oracle 数据库的，我们的首席设计师很厉害，在框架层面解决了这个问题，不仅可以继续保持框架的兼容性，还扩大了框架的适应面。

案例2：点是否在多边形内的求解

这个几何问题是由业务问题转化而已来的，这是一个某移动通讯公司的系统，先简单介绍一下业务。

我们的手机是通过基站进行通讯的，如果附近没有基站，就会出现手机没有信号的情况。我们所居住的城市当中，一般会有上百成千的基站，保证我们通讯畅通。基站与基站之间形成的通讯网络，会划分为以基站为中心的多个“多边形”，形成一个好像蜂窝的样子，这就是我们经常听说的蜂窝网络。但有可能会出现某个地方打电话有问题的情况，这个出问题的地“点”位于哪个“多边形”呢，系统需要通过点的坐标找到这个点在哪个多边形范围内，进一步定位到是哪个基站可能出问题。

上述就是原始的业务背景，我们将这个需求演化为一个几何问题，当时我参考了“放射线”的算法，直接通过“Demo法”来完成这个设计。前文的”实践3：Demo就是设计“中提到的例子，就是这个例子了！

案例3：让程序支持 Undo 和 Redo

如果要求你的系统支持 Undo 和 Redo，不知道你会如何考虑呢？支持 Undo 和 Redo 是非常酷的，但难度是相当之高的，你会先完成架构设计和数据库设计才考虑吗？23设计模式中的命令模式可以帮助我们，但命令模式仅仅是给出了解决问题的框架而已，你还需要演化为更实际的内容，否则又犯了”放之四海而皆准“的毛病了。命令模式很有难度，但很有意思和很有用，我们这里不详解命令模式，大家可以参考我的设计模式方面的文章。

这里举这个例子是想说明：某些需求看上去好像是仅仅很小的一个点的要求，有可能影响面很大，你可能需要先针对这个点去思考详细的实现办法，然后才能帮助你想清楚架构设计及数据库设计。

小结一下详细设计解决局部问题的两种特殊情况：框架未确定之前的技术预研，案例1、3属于这个情况；框架确定与否都不影响的局部问题求解，案例2属于这个情况。一般认为详细设计是概要设计之后的，大部分情况确实如此，但通常我们进行概要设计之前还很可能需要针对某些需求点进行技术预研，这些技术预研是需要用详细设计的程度来进行。

需要补充说明的是：某些技术难点的设计，通常仅仅靠顺序图是搞不定的，甚至不能用顺序图，我还会用到类图、对象图、活动图和状态机图等等，类图用到的机会最大，你看看23设计模式，设计思路基本上都是用类图来表达的。UML图仅仅是一种工具，前文提到的“实践二：代码就是设计”和“实践三：Demo就是设计”，对于难度高的详细设计是经常需要用到这两招的。

8.5 需要从详细设计中提炼出需要全局考虑的内容

前文提到”详细设计是架构设计的延续”，其实还需要补充的是“详细设计需要持续完善架构设计”。详细设计过程中，我们会发现很多共性的内容，需要提炼为整个程序需要遵循的设计规范。下面是一些例子：

1）用户体验设计；（下一篇再详细介绍）
2）输入合法性判定；
3）批量数据的传输约定；
4）实体类的生命周期；
5）逻辑类的生命周期；
6）并发冲突的处理原则，包括判定办法、提示办法；
7）连接打开、关闭原则；
8）采用事务的原则；

9）异常处理机制；

10）日志记录机制；

……

8.6 详细设计小结

对于MIS类型系统来说，架构设计和数据库设计做好的前提下，详细设计的难度其实是比较小的了，你可以用顺序图来完成设计，注意做到需求驱动详细设计，注意要满足架构设计和数据库设计。不过不少MIS会有一些特殊的需求点，我们需要识别出来并想清楚应对办法，某些特殊的需求点还需要进行前期的技术预研。

如果你做的不是MIS类型的系统，而是设计难度很高的软件，比方说技术含量很高的CAD软件、人工智能很牛逼的某些家用游戏，要解决这些软件的详细设计，你需要设计模式、工程绘图、数学、物理、人工智能等很多知识支撑才能搞得掂了！

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

活动信息：

我们即将在深圳举办的一个活动“敏捷遇上UML”，为你分享需求分析及软件设计的最佳实践。