【Design Review】
近期参加了公司的一个详细设计评审，从评审的开始到评审结束以及评审后的作为都不甚满意。
在这里谈谈自己对于详细设计评审的一些看法。后续有更成熟的想法也会继续在这里完善。
【详细设计的内容】
在我们公司，详细设计从上一级的概要设计秉承而来。是对功能点的进一步细化，详细设计的文档力求做到：
看到文档的人就能知道怎么编写代码。具体会有：
1、 功能点描述。
2、 完成功能点的程序流程图。
3、 文字描述。
4、 异常处理。单列一章出来，说明公司很重视代码的健壮性。
5、 配置。
6、 代码设计：包括类图和时序图。都用Rose生成。
7、遗留问题。这里从来没写过。^_^。
具体我就不再一一展开。
【评审存在的问题】
1、 设计的随意性太大。随意性表现在相互之间的接口在评审之前都没有确定下来，当发现哪个流程走不通时，
就随意的让某个类添加某个功能，以让流程走通；
同事给出的理由是工期太紧。从长远来看，代价必然是惨重的。代码的可读性和可维护性都无从谈起。
更不用谈整个代码的框架了。
2、 评审的准备明显不足。由于大部分人都不是在项目的早期就参与进来，都没有摸透项目的精髓所在。
在评审时，其他人几乎都没有意见。看起来不是来评审的，而是来打酱油的。
3、 负责人对于评审的把握相当糟糕。
评审的主题不明确。恩，是根本没有说明有哪些主题。其实每一次评审都会有不同的侧重点。
评审的引导不够。
考虑问题过于片面，只注重于代码的效率。而不注重整个设计的结构。
大家都知道第一次评审完后的结果是相当糟糕的，但是没有组织第二层评审。而是马上进入了编码阶段。
不够包容。对于有不同设计的，一概否决。不采用好的设计的理由是进度太紧。
4、 评审的效率偏低。一个功能点能讲一个上午，所以负责人一定要检查每个人的准备情况，根据准备情况决定评审是否应该延期。否则是在浪费时间。
5、 缺乏评审记录。没有记录下来评审存在的问题，后续就比较难落实。
【怎么改善】
首先评审应该从小范围开始，再到最终评审。它是一个渐进的过程，在这个过程中问题会逐渐减少，到最终评审时的设计就相对比较成熟。
其次每个人在评审之前提出自己的质疑。
最好由评审的负责人发布评审邮件。
【评审邮件】
[说明评审的地址、时间]
[评审的参与人员、指明评审的记录人员]
[评审的主题]
[评审的流程] //从哪个模块开始，到哪里结束。每个人负责讲述自己负责的功能点的设计。回答别人的质疑。
[评审要达到的目的]
【评审主题】
1、 是否涵盖了概要设计的所有功能点。重点检查是否有遗漏的点以及对功能的理解是否正确。
2、 检查流程是否清晰、正确，是否考虑到所有异常。
3、 类的设计是否合理。从封装、粒度、独立、灵活、可重用性方面考量。
4、 从时序图考察各个功能点的逻辑是否有重复的地方。
5、 考察重要算法的效率。
本文作者:网友 来源:其它 | http://www.cnblogs.com/maoye/archive/2010/04/09/1708446.html
CIO之家 www.ciozj.com 微信公众号:imciow