思考详细设计

新一篇: 思考详细设计——maillist中的讨论
Ai92 2006-8-2
 
设计在软件开发中扮演的角色，相信大家都很清楚。设计的好坏直接影响着软件产出的质量。设计一般分为架构设计（概要设计）和详细设计。架构设计主要从系统整体上来考虑使用什么样的架构、如何划分模块以及制定模块间的通信规则。因此架构设计从规模或者粒度上都比较好把握。而详细设计则与架构设计不同，它的工作量通常不小而且粒度不好把握。所以详细设计往往实践的不是很成功，要么流于形式，要么直接被pass掉……。
下面是我对详细设计的一点思考，其间alexwei12、chinakite给出了很好的建议，并将经验分享给我。
 
设计之痛——编写文档
详细设计作为软件开发中不可缺少的过程，理应由输入、活动、输出这三部分组成。最重要的部分当然就是“活动”这一个环节，在这一环节里面，设计人员根据需求和架构设计构思可行的解决方案。而“输出”部分就是这一节要讨论的详细设计文档。我认为详细设计产生文档的主要作用大抵是为了和实现人员或者任务交接人员进行“沟通”，使别人明白你的设计意图和设计方式。当然它也有着在设计时理清思路的作用。
Gresham法则如是说：“程序化的活动容易将非程序化的活动驱逐出去”。详细设计文档的编写的确很容易占用原本用于寻找解决方案的“活动”时间，而使得真正用于设计的时间变得急促。这种本末倒置的现象是如此的普遍，似乎成了合情合理的了。
造成这种局面的原因大概就是因为编写文档的痛苦和难以维护。
在软件过程普遍得到重视的今天，每个公司大多都有一个所谓的过程财富库。财富库中都有一些所谓的模版来统一文档编撰的格式。而其中的“详细设计模版”大抵是这个样子的：总的类结构图，总体说明，每个类的定义，每个属性的定义，每个方法的定义，每个参数的定义，返回值的定义，甚至注释的定义、伪代码……。详细的可以称作代码的文档版。坦白的讲，编写这样的文档是件很痛苦的事。
如果你能做到一次设计即可完美的将需求实现到代码中去。那么费一次劲将《详细设计说明书》编写完成，也可以算是一件事后很愉快、很有成就感的工作。但是需求的变更、设计的险恶以及自身能力的限制让你总是与完美保持距离。而这时，修改和同步《详细设计说明书》就变成了噩梦之旅。当然，你也可以选择放弃，于是这些文档就变成了废纸甚至误导其他人的陷阱。
再者，这样编写出来的文档并不比代码好看多少，特别是当文档的厚度达到一定程度之后。很难想象一个可怜的人抱着几百上千页的《详细设计说明书》进行“沟通”的场景。何况习惯于阅读代码的人是不会想去阅读一个没有任何IDE支持、很可能存在错误甚至已经过时的代码文档版的东西。
 
那到底如何来编写文档呢？是不是这根本就没有意义？
解决这个恼人的问题，似乎有以下几种方式：
1.         引入工具支持。比如RUP的双向工程（没有条件使用，因此不做评论）。
2.         使用图形代替《详细设计说明书》。我认为在设计中理清思路和表达理念的最佳方式还是抽象的图形（而为了统一大家沟通的语言，制定一个标准表达方式还是不错的主意，而UML就是一个现成的不错选择）。用能够简单、清晰的表达设计蓝图的图形来整理你的设计思绪，并作为“沟通”语言传递给实现人员或者任务交接人员。注意，是简单、清晰的图形，而不是面面俱到、事无巨细的图形。
3.         使用API Doc代替《详细设计说明书》。花了大力气来编写一份没有作用的文档，不如将这份精力投入到编写好的高质量的代码上去。事实上，没有任何比源代码更详细、更易读的文档了，那么就将你的详细设计作为注释写到代码中吧。
4.         2、3结合使用。
5.         在项目最后编写文档。如果无论如何都要上交一份《详细设计说明书》的话，那就把这个任务留在项目最后吧，因为这时设计基本趋于成熟，编写文档的痛苦可以降到最低。
 
       也许有人会提到文档裁剪、设计评审等有效缓解设计之痛的方法。但是在我见过的公司里面，这些环节都形同虚设（将别人表面的东西拿来做重要内容，又将别人重要的东西拿来做表面功夫）。这又应了Gresham法则。  
 
重在过程，把握粒度
       详细设计是一个经验与智慧并重的创作过程，详细设计是技术更是艺术。看一个人的详细设计成果，可以很好的检验他的技术功底和实战经验；全面参与一次详细设计过程，则可以很好的锻炼自身能力与团队意识。它不仅仅存在于预先设计阶段，而且也存在于编码阶段。这是一个逐步细化、深入的过程。
 
       在设计阶段，详细设计到什么程度才算好呢？哪些应该放到编码阶段中去细化呢？ 
RUP中讲究裁剪，详细设计的粒度同样也需要裁剪，有时详细设计会细化到可以生成代码，而有时详细设计则仅是几张图纸（又说了句实在的废话）。下面是来自chinakite对如何把握详细设计粒度总结的经验：
1.         看工期。如果工期非常紧，则简化到概要设计的程度；正常情况细化到类的结构，关键点——比如用户认证框架运行机制细化到方法及使用顺序。如果工期宽裕的话，你不仿做的详细些。团队项目就这特点，跟自己编程不一样，你必须为你的项目负责。
2.         看功能。如果很复杂的功能，比如我原来做的权限部份，我觉得很复杂，这部分已经不只靠UML就能说明白了，除了详细的UML外还要加上doc文档说明。如果复杂程度一般，比如一个用户的权限设定，细化到类一层就足够了，序列图在这时相对重要，因为这能表明你的逻辑，类图并不很重要，可画不可不画，以后能找到能看懂就行。复杂程度很低，就不需要做，比如就简单地向数据库写条记录，做了就是在无聊。
3.         看人员水平。如果大家水平都较高，那么能简化则简化，如果水平一般或以下，最好还是做得详细些吧，不然将来有得头疼的。
4.         看业务层次。越底层的东西对详细设计的要求就越高，要时刻记着这些东西不只是你一个人看的，是给所有你的受众看的。不要以为你给了接口他们就会满意了，有时他们更想知道你的想法以及对你的想法提出建议，上层的相对简化。
           
当然，你可能还要结合实际项目的规模、模块权重等等因素做出适当的折中和取舍。完成了预先设计阶段的任务以后，在实现阶段我们可以通过重构、代码走查等方式来进一步细化设计，最终得到一个让人感到满意和清爽的设计结果。
 
以上是个人对于详细设计方式的一些浅见，欢迎大家讨论，如有不妥之处敬请斧正。