高分请教大家详细设计在开发过程中的使用. 谈者有分,不够继续追加

Question

呵呵，楼主的这个贴是好贴！欢迎这类的贴！做web不光是编码！架构和软件工程也很重要，大站的经验同样重要！讲一下个人实践吧！首先 没用过多少详细设计，也没见过正式的web开发文档！（一直试图这样做，但没成功过一个）
一般如下实践：
  1、简单功能分析和模块
  2、文档说明：就是各个文件是干什么的（是否有相对路径）
  3、流程文档说明（uml中的用例——文本型的）或基本流程
  4、源文件中的功能和过程注释   至于交互，顺序之类的暂未用到！个人如果是大站，最好还是要详细设计！考验逻辑！其次是如果是对不熟悉的领域进行设计，应采于uml开发并评细设计！
根据uml模式：
  用例就是需求分析！而且详细到步骤！
  如果复杂的话，可以用交互、顺序和协调等！如果是团队开发，较为重要！
  如果是个人开发，我觉得除了用例外，最好是有基本流程图就可以了！这样可以了解基本架构，（再细的，主浊编码问题了）。
  
  数据字典也是必要的，统一标准，有参数的，就查字典！（保证统一）
  基本原则：首先是流程清晰——能用；其次才是架构合理！

Answer 1

回一楼 : 没做过毕业设计.回2,4,5楼 
搞清需求肯定是首要要做的,但不是此帖的重要论点.  
在做设计之前搞清需求做好概要设计,这一点上大家是没有矛盾的... 
  
  我想讨论的是说明详细设计在软件开发过程中起到的做用.是独立的看待这个详细设计的. 更希望的是了解详细设计在开发中的应用.回3楼
非常赞同你的一些看法.
基本上我们现在是用用例图来做需要分析的,并把每个用例的详细档对应到用例中去.
交互图和时序图没有用过,个人感觉现实的网站开发中,也并不是太多的需求这个.
数据字典是好东西,希望三楼贴出来共享一下,
我现在用了几个:1 数据库字典,2 界面相关css 字典 3网页无素子典.

Answer 2

我们正在做一个人事管理的Web课程设计，先做的详细设计，不过还没有写完了，楼主的是好帖

Answer 3

这两天比较关注详细设计在开发中的应用.
我自己写了一些查数据库的公用代码,现在发现把详细设计中读数据的这点写细,就可以动的生成代码了.
举一个查询纪录集,用一个数组
例如: 
//查询描述:        我想做一个查询.  (对你这个查询的描述)
//查询所在包:      global         (这个查询所在的包)
//作者:           striker_un     (通常就开发小组的几位)
//话题标题          我的标题           ( 你对交查询命名的标题)
//目标文件         /home/httpd/web/user.php    (你希望将这个查询生成到哪个文件.)
//查询表            user               (此次查询所用的表.)
//查询条件          where uid <100   (此次查询的条件)
//查询条数限制      limit 10
//排序              order by uid desc
//查询字段          uid,uname,upwd
//查询结果数组名称  myuser
//todoList        你还要做些什么
//查询状态         (0|1|2)              待审|通过|回收
有两种方式, 
1用程序解析文件. (通常写设计的人,会用excel 来写这些,可能会转成xml ,json 这类比较好交换的格式)2 程序员根据详细设计填写相关表单,生成目标程序.
我目前用的后着,并针对所有的代码,用后台组件进行了管理.
//然后就生成了如下的代码.
 <? 
 //引入公用文件 
require_once("include/head.inc");
 if(!defined(DEBUG)) define(DEBUG,"1");
/****
* 我想做一个查询.
*@package   global
*@author    徐兴 
*@todo      我还想做些什么 
*/
$table = "user";      //求出相关的表名.
$cond ="where uid <100";     //查询的条件
$ord ="order by uid desc";       //查询的条件
$limit ="limit 10";     //对查询的记录数进行设置
$itemsString ="uid,uname,upwd";  //查询字符串
$myUser = Common::dbquery( $table , $cond , $ord , $limit , $itemsString ,  "" , "" , 0 );
print( "<pre>" );  print_r( $myUser ); print( "</pre>" );
//this file is create by programAdmin 2008-04-09 01:34:07
?>
//由于现在还在研发过程中,所以不太好定性这类做法的好处和坏处,但我觉得这样做,代码就易与维护. 特别 是想改的时候,会感觉蛮有意思的.直接上后台控制. 有了文档,前台的写界面,写模版的人,也好针对着文档去实施界面.

Answer 4

呵呵，我们组长最近一直在强调文档的重要性。PG（写代码）之前，要写BD，FD文档，即（对样式设计的一个
具体构思过程。
）

Answer 5

数据字典我只用于数据库，参数变量转换和公用变量之类的！没你那么细了！你23楼的设计，会提供不少节省节码的方法！主要是查询语句！但个人觉得代码生成的意义有待探讨！对于维护方面。实践中遇到以下难点：
1、公用变量，全局变量（配置文件，discuz等都这么用）；
2、包含文件（绝对还是相对路径）
3、功能实现用函数还是用文件？（函数中的相对路径问题和绝对路径问题）
4、用函数还是用类？从调用的角度讲，类好象比函数更好调用，更好移值！
5、设计核心代码！（RUP理念为迭代开发）
6、逻辑流程从维护的角度讲，写开发文档便于维护！原则上，程序要健壮，可移植，可维护！

Answer 6

首先感谢楼上的．
我之所以那样做，就是为了对那种常规的加工操作的一次提速过程，并不是希望通过那些东西来完全的取代程序员的劳动．
确实我在做的时候有一些想法，想是否一起连后台一起生成了，是否前台指定模版也一写生成了．（关于程序的模版，不是那种用于render 的模版）,但我觉得这些都不适合在现阶段过深的去考虑．
还有，现阶段我在看设计模式四人帮和headFirst，感觉此书不错．

Answer 7

还有，从可维护的角度讲，要多次分离
一、是页面分样式和结构分离，（CSS和div)，javascript分离
二、页面实现逻辑分离（即页面可随意组建）
三、应用和框架分离（这个是我瞎想的）——反正意思就是最后只要搭积目或部署就行了！
四、逻辑和数据分离！

Answer 8

好帖!
Mark,中午边吃饭边看,现在做工