（34） 如何做详细设计？

项目经理可以不去参与详细设计，但是他应该了解这个过程，这样便于把控详设的进度和质量。一般的项目组中，都会有2~3个技术专家，或者说是技术骨干。这些技术骨干基本上都是一些经验丰富的高级开发工程师，没有8年以上的编程经验，不敢说自己经验丰富。项目成功的团队，也基本上得由这些技术大拿撑起半边天，否则可能累死项目经理。即使有些项目经理自己也是技术大拿，但是也经不起程序员们反反复复的提问，在设计和编码阶段，问题多如牛毛，没有几个技术高手分担压力，这个项目失败的风险会非常大，即使前期有非常好的方案。

至于项目经理如何施展自己的魅力将技术骨干纳入自己的项目组中，这个不是我这个系列的主题，而且每个人的方法也都不一样，所以这里就略过不提。这里单说详设阶段我们需要注意的几个问题。

1、详设不能等同于概设，这点在概要设计中已经描述，一个是系统架构设计，一个是程序结构设计，如果非要打个比方的话，概设就是做房子的框架，或者说是建筑设计，详设就是做室内装饰，应该叫装修设计。可能这样比喻并不是很恰当，但是大致就是这个意思。

2、详设基于系统的结构，而不是系统的架构。所以经常有人将详设叫做功能设计（不是功能架构），基本上是差不多的意思。详设解决的是系统模块内部的程序逻辑设计、接口设计以及关键接口的实现的算法设计。实际上，详设还有一个重要任务就是完善数据库的结构和SQL语句以及存储过程。

但是，很多项目组很难完成详设的任务，大部分浮于形式，总是将详设推到编码阶段，甚至在项目完成后再追补详设文档。之所以出现这种情况，主要有以下原因：

a. 详细设计时间太短，项目总体计划留给设计的时间非常短，估计不超过一个月，这么短的时间很难做出完美的设计，尤其是详设文档的工作量又非常大；

b. 经验不足，对系统的程序实现缺少整体设计，如果遇到这种情况，一定要借助现成的技术框架，这样可以将精力集中放在程序的逻辑处理上；

c. 对业务的细节不够熟悉，很多人在概要阶段没有吃透业务，从而将麻烦留给了详设阶段，因为业务逻辑夹生，导致无法决定程序逻辑，最后不得不将程序设计推到编码阶段。

3、详设关键要素。函数定义、流程图、输入、输出。有人看到这里，会马上说了，不对啊，概设里已经说到流程图了，怎么这里又要画流程图。不错，概设里的确是画流程图了，但是那里的流程图是业务流程图，而详设里画的是程序流程图，它是描述算法的，所以不是一样的东西。另外，概设里是功能定义，这里是函数定义，也不是一样的东西，一句话，概设里讲述的是基于业务进行描述的，而详设里是基于程序逻辑和接口实现进行描述的，不是一回事。举个例子，概设里就是在画个房子的图纸，至于房子怎么去做，人家是不管的，谁管？工程队或者施工队，他们拿到概设的图纸之后，也会开会讨论，制定详细的施工方案，张三小组打地基，按照什么流程去做，李四小组做现浇，应该按照什么流程去做等等，这个就是详细设计了，虽然施工队包工头不懂得设计，但是实际上他已经在做设计的事情，当然他之所以能够设计，主要还是靠他的经验。

4、详设的工具很多，主要是画接口关系图、程序流程图，最好在描述函数（我称之为业务函数）的时候，用表格比较清晰一点。如果你有其他更好的方法，也是没有问题的。

5、详设并不要求描述所有的函数，而是主要函数和关键的函数，什么是主要函数？一般是指与业务接口对应的主函数，一个业务函数可能会有很多其他的函数配合实现。什么是关键函数？就是在程序中或者与系统有很大关系的函数，比如某一个加密函数，这个就比较关键。其他的函数可描述也可不描述，当然不嫌麻烦的话，描述总比不描述要好。

6、详设的结果也是有模板的，至于什么样的模板并不重要，重要的是将详设的结果描述出来就可以。

现在有一些软件能将详细设计直接转成代码，这也是个趋势，如何将由自然语言描述的业务转换成程序语言，是需要经历一个漫长的过程，但是目前还不是很成熟，相信将来会实现的。

详设就聊到这里，下一节我们聊聊编码，欢迎大家继续关注我的系列，谢谢！