关于针对Detail Design（DD、LLD、详细设计）的同行评审

mingmou_1999 · 发表于 2008-1-11 17:29:43

什么是同行评审？
　　同行评审（Peer Review）：是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。其主要类型包括：正规检视、技术评审、走读等。

模块的DD在完成后，是否需要同行评审？
　　在Detail Design（DD）完成后，开发人员会按照DD的设计要求进行开发，而测试人员会按照DD的要求进行测试用例设计。因此，DD的设计是否完善、无重大缺陷；开发、测试人员是否深入的了解了DD的设计内容和设计思路，都直接关系到该模块的生产进度和产品质量。
　　那么怎样才能够完善模块的Detail Design（DD），并让开发、测试人员正确的贯通设计人员的思路呢？其实针对DD的同行评审可以有效地解决这个问题。
　　针对DD同行评审的主要目的是检查和确认设计缺陷，它可以在模块开发周期中的较早期阶段清除设计方面的缺陷。就缺陷修复的成本而言，在开发工作开始之前就清除框架设计方面的缺陷，其修复成本是较低的。而且这个检查和确认的过程，对评审的参与人员了解整个评审模块也是很有帮助的。让参与的开发人员清楚地确定，自己应该做出什么样的软件；同时也让测试人员确定自己所需要测试的内容。

那么同行评审的主要参与者，都应该是哪些角色呢？
　　试问，在一个软件项目团队中，除了DD设计人员自身之外，谁对DD的优劣最有发言权呢？有人可能会说是DD的Reviewer。诚然，DD的Reviewer往往是团队中比较有经验和发言权的“牛人”级角色，但是由于角色的限定，其对DD的审查往往是走马观花式的框架把握，而对于细节问题往往予以忽略。其实，对于一份DD文档质量优劣，感受最深的往往是工作在DD层下游的开发、测试人员。他们的工作，直接依照DD进行，DD文档的质量直接影响到他们实际的工作效率和产品质量。因此，各模块的开发、测试人员应该参与自己所负责模块的DD评审，并根据自己的工作需要，对DD提出相应的意见。但是，由于专业知识得限制，开发和测试人员不一定能够对“模块基本构架的合理性”提出实质性的意见，因此如果条件允许，还可以邀请一两位对程序框架设计有经验的专家，参与框架的评审。
　　除了保证DD设计质量外，同行评审可以给设计、开发、测试人员一个跨组交流的机会；同时也可以从“设计”、“开发”、“测试”等不同的角度来对整个模块设计的合理性提供意见；另外，相关人员汇聚到一起进行同行评审，可以较好的了解模块的相关背景，避免了日后繁琐的交流，减少了“因为对项目设计思路的理解不一致，而产生错误”的可能性。

如何进行针对DD的同行评审呢？
　　由开发和测试人员参与的DD同行评审，可以以“走读”为主；在有程序框架设计经验的专家参与的情况下，也可以进行“技术评审”。
　　所谓“走读”，其主要是对文档进行检查，通过走读发现文档中存在的缺陷（可能包括逻辑矛盾、描述模糊和文法错误等），同时参与人员也可以进行技术交流，初级人员也可以学习一些技术方面的知识，了解设计者的思路。所谓“技术评审”是一个相对正式的评审过程，其在规格、标准等方面进行评审，并在评审后给出相应得修改意见。
　　同行评审由专门的组织者主持，并有作者和相关同行出席。其规模不宜过大，大致可以控制在三到六人。在会议过程中，可以先由作者对其DD进行讲解，引导大家进行走读。然后参与者们共同对DD进行评审，确认问题，并对其进行分类。

　　一般情况下，同行评审可以被控制在两个小时之内。一些简单的模块，可以把同行评审压缩到一个小时之内。在评审过程中，如果遇到问题需要延时，可以由作者决定是否召开“第三小时会议”。评审结束后，有必要对评审问题进行跟踪，以便确认确陷的到了修改，并且没有引入新的缺陷。