设计评审【Design Review】

【Design Review】

    近期参加了公司的一个详细设计评审，从评审的开始到评审结束以及评审后的作为都不甚满意。

　 在这里谈谈自己对于详细设计评审的一些看法。后续有更成熟的想法也会继续在这里完善。

【详细设计的内容】

   在我们公司，详细设计从上一级的概要设计秉承而来。是对功能点的进一步细化，详细设计的文档力求做到：

看到文档的人就能知道怎么编写代码。具体会有：

1、 功能点描述。

2、 完成功能点的程序流程图。

3、 文字描述。

4、 异常处理。单列一章出来，说明公司很重视代码的健壮性。

5、 配置。

6、 代码设计：包括类图和时序图。都用Rose生成。

7、遗留问题。这里从来没写过。^_^。

  具体我就不再一一展开。

【评审存在的问题】

1、  设计的随意性太大。随意性表现在相互之间的接口在评审之前都没有确定下来，当发现哪个流程走不通时，

就随意的让某个类添加某个功能，以让流程走通；

同事给出的理由是工期太紧。从长远来看，代价必然是惨重的。代码的可读性和可维护性都无从谈起。

更不用谈整个代码的框架了。

2、 评审的准备明显不足。由于大部分人都不是在项目的早期就参与进来，都没有摸透项目的精髓所在。

在评审时，其他人几乎都没有意见。看起来不是来评审的，而是来打酱油的。

3、  负责人对于评审的把握相当糟糕。

评审的主题不明确。恩，是根本没有说明有哪些主题。其实每一次评审都会有不同的侧重点。

评审的引导不够。

考虑问题过于片面，只注重于代码的效率。而不注重整个设计的结构。

      大家都知道第一次评审完后的结果是相当糟糕的，但是没有组织第二层评审。而是马上进入了编码阶段。

      不够包容。对于有不同设计的，一概否决。不采用好的设计的理由是进度太紧。

4、  评审的效率偏低。一个功能点能讲一个上午，所以负责人一定要检查每个人的准备情况，根据准备情况决定评审是否应该延期。否则是在浪费时间。

5、  缺乏评审记录。没有记录下来评审存在的问题，后续就比较难落实。

【怎么改善】

   首先评审应该从小范围开始，再到最终评审。它是一个渐进的过程，在这个过程中问题会逐渐减少，到最终评审时的设计就相对比较成熟。

   其次每个人在评审之前提出自己的质疑。

   最好由评审的负责人发布评审邮件。

【评审邮件】

   [说明评审的地址、时间]

   [评审的参与人员、指明评审的记录人员]

   [评审的主题]

   [评审的流程]  //从哪个模块开始，到哪里结束。每个人负责讲述自己负责的功能点的设计。回答别人的质疑。

   [评审要达到的目的]

【评审主题】

1、  是否涵盖了概要设计的所有功能点。重点检查是否有遗漏的点以及对功能的理解是否正确。

2、  检查流程是否清晰、正确，是否考虑到所有异常。

3、  类的设计是否合理。从封装、粒度、独立、灵活、可重用性方面考量。

4、  从时序图考察各个功能点的逻辑是否有重复的地方。

5、  考察重要算法的效率。

转载于:https://www.cnblogs.com/maoye/archive/2010/04/09/1708446.html