zz不完全IT手册（六）-设计（2）

发信人: lmchen (匪兵丁), 信区: WorkLife
标  题: 不完全IT手册（六）-设计（2）
发信站: 水木社区 (Wed Jul  2 13:02:48 2008), 站内

http://chenleimin.blog.sohu.com/93482242.html
毫无意外的，在本篇的开始依然用一点废话来回应大家的评论

有人评价说看了咱的文章语文水平有所下降，这个没办法了，我就这么高水平，您捏着鼻子看吧。有人说文章太简明了，对人的帮助不大，这个，似乎也是我的水平问题，我要是有本事写个东西，让新手迅速成为专家，那么匪兵就不是那个匪兵了。有兄弟说文档其实比代码难写，这个我也很同意，不过我觉得其实文档比代码更重要，虽然文档不能执行。还有兄弟说组内成员写文档很差，首先对你们全部用E文写文档汗一个，再拜一个，其次为后面的某篇文章爆个料，匪兵我自己一直认为对吃程序员这碗饭的人来说，不会写文档比不会写代码还要可怕，实在写不好文档的话，要不考虑一下早点该行？

废话说完，开始新的废话。

本篇主要讲讲设计文档都写一些什么东西，这里有个前提，对设计文档来说，理论上讲，没有任何东西是必须要写的，没有任何东西是必须写成什么样子的，也没有任何东西是写了一点都没用的，写什么，不写什么，怎么写，最关键的是看你的项目条件如何，项目规模如何这些因素，一般来说，越是庞大的项目，文档就需要写的越细致。所以我这次的文章，在列举一些我认为重要的部分同时，会同时说明这部分的意义及重要程度，请各位自己把握。

1.功能流程：这部分个人一直以为是概要设计中最重要的内容，其实这主要是将你前面需求文档中的流程给技术化了，主要描述对什么样的输入数据做什么样的判断，然后给出什么样的输出，中间去哪里取什么数据，怎么存储，怎么传输等。这一部分基本上就是程序框图了，你写的时候也不妨直接把框图画上去。注意这种流程最重要的是与功能有关的流程，项目无论大小都要写清楚，部分仅仅与算法有关的流程，则可以根据情况写，或者只写个接口或不写，这个主要看你详细设计要做到什么程度。非常重要，概要设计的基本内容。

2.数据流：主要描述数据流向，基本上也是以图为主，文字说明为辅，描述数据流的，这个东西在不同的系统框架下重要度不一样，有的框架下，这个东西很重要，有的则几乎可以省略。根据项目需要非常重要或不重要（晕）。

3.数据接口：主要是指各个模块之间的接口，即不同的开发人员之间的接口，还包括各种数据结构定义（数据库定义，数据文件定义等），在不同的模块（主要是指不同的人之间），明确他们之间如何进行数据交换及流程的转换。这个东西要么在你的系统中没有，只要有，就是非常重要的东西，而且建议你自己亲自审，一个字节一个字节的审，理论上不要有任何歧义才好。同时，以后万一有了修改，也尽量的要主意敲锣打鼓的让你整个项目组的人都知道。只要存在就非常重要，建议单独写文档。

4.用户界面：可以先画一些空界面出来，这个主要看项目需要和项目大小，报表，打印凭条，这个也是界面的一部分。重要，但同样看项目特点而定（再晕）。

5.错误处理：这里包括错误代码的定义和处理流程，关于错误代码，我个人的习惯是用8位数字，头两位是模块代码，次两位是子模块，后面四位留给程序员自己用顺序号来逐一区分所有的错误。最后我们统一做个函数处理这个错误。错误要分等级，最起码分成“错误”和“警告”两级，当然你也可以无限细分，最严重的自动拨打110啥的。重要，可以简单写，但一定要有。

6.类定义（或函数定义）：这个就基本上属于详细设计的内容了，对于重大项目或项目中的重点流程，这个东西还是很有必要的，而且现在这么多辅助设计工具，写这东西也不麻烦，也不造成重复劳动，所以这个虽然已经近似于编码了，但在设计阶段，能写还是写了吧。重要，在不严重增加工作量的前提下尽量写。

7.测试：包括测试流程和测试用例，有的时候甚至包括要开发一些专用测试工具，这个东西我个人比较建议在设计阶段就都规划好，不管你们公司有没有专门的测试团队，关于对你的系统如何进行测试，毕竟是你最了解。重要，反正你早晚都得做。

最后再说说概要设计和详细设计之间的关系，理论上说是先写概要，后写详细，没错，如果你的项目很重要很庞大，而且客观条件允许，那么就该这么写，但对于一些中小项目，或者不具备条件的，不妨把概要稍微写细一点，就开始编程了，这么做肯定有风险，不过考虑到成本，对小项目而言，这个风险可以承受。

预告：从项目进程上说，下面该讲堆代码了，不过代码千变万化，匪兵我自己也不是编程高手，所以取个巧，主要讲与代码有关的东西吧，版本控制，进度控制，以及测试相关内容。