摘要：本文主要讨论，软件开发过程中，针对详细设计同行评审的必要性，以及针对详设的评审的人员配置，以及大致的评审流程。主要是笔者的日常理论积累和工作中的实际经验。可能在有些方面并不完善，如有缺陷，欢迎指正。
        关键词：同行评审，详细设计，质量，软件开发人员，软件测试人员
        在软件开发过程中，当某个模块详细设计文档（Detail Design）完成后，软件开发人员会按照详设文档的设计要求进行代码开发，而软件测试人员会按照详设文档的要求进行测试用例设计。因此，详细设计的内容是否完善、有无重大缺陷；软件开发、测试人员是否正确深入的了解了详细设计的内容和设计思路，都直接关系到该模块的开发进度和产品质量。
        那么怎样才能够完善模块的详细设计，并让开发、测试人员正确的贯彻设计人员的设计思路呢？针对详设级别的同行评审可以有效地解决这个问题。
        针对详设的同行评审，其主要目的是检查和确认详细设计中的缺陷，以便在模块开发周期中的早期阶段清除设计方面的缺陷。就缺陷修复的成本而言，在代码开发工作开始之前就清除设计方面的缺陷，其所付出的成本是较低的。而且这个检查和确认的过程，对评审的参与人员而言，也有助于他们了解参评的模块。
        那么，当我们确定对详细设计进行同行评审时，其主要参与者都应该是哪些角色呢？
        试问，在一个软件项目团队中，除了详计文档的设计人员之外，还有谁对详细设计质量拥有发言权呢？有人可能会说是详细设计的Reviewer（检阅人员）。诚然，详细设计的Reviewer往往是团队中比较有经验的“牛人”级角色，也有可能是详设人员的直属Leader。从技术角度上讲，他们对于模块的详细设计是有发言权的，能够对详细设计得框架进行把关，但是由于角色、职责、精力等方面的限定，他们往往不会对其审查的详设文档进行仔细的分析、走查。其审查往往只能做到走马观花式的宏观把握，而对于细节问题往往予以忽略。
        在很多大型项目中，模块的划分数量很多，要进行评审的详设文档更如烟海。要同行评审中，如果能有Reviewer级别的人物参加，当然最好。但是基于时间和效率方面考虑，让Reviewer参加每一次详设评审，是很难做到的。他们往往只参加一些重要级别模块详设的同行评审。
        其实，对于一份详细设计文档质量优劣，感受最深的往往是工作在详细设计层下游的软件开发、测试人员。他们的工作，直接依照详细设计进行，详细设计文档的质量直接影响到他们实际的工作效率和产品质量。他们在日常工作中，对于详设文档，往往是逐字逐句的斟酌揣摩，对于文档中的一些细节问题尤为敏感。
        因此，各模块的开发、测试人员应该参与自己所负责模块的详设评审，并根据自己的工作职责和需要，对详细设计提出相应的修改意见。开发、测试人员的加入，不但可以使模块的详细设计更加贴进于实际的开发工作，同时也可以让参与同行评审的开发、测试人员明确是设计者的意图，确定自己要开发的或要测试的是什么样的软件。
        但是由于专业知识得限制，一些初级的开发和测试人员往往难以对能够对详细设计中的一些复杂的设计问题，提出实质性的改进意见。因此如果条件允许，还有必要邀请一两位有经验的专家，参与评审。
        除了保证详细设计质量外，同行评审可以给设计、开发、测试人员提供一个跨部门的横向交流机会；同时也可以从“设计”、“开发”、“测试”等不同的角度来对整个模块设计的合理性提供意见；相关人员汇聚到一起进行同行评审，通过相互沟通，较好的了解模块的相关背景知识，避免了日后繁琐的交流，减少了“因为对项目设计思路的理解不一致，而产生错误”的可能性。
        在实际操作中，由开发和测试人员参与的详细设计同行评审，可以以“走读”为主；在技术实力较强的情况下，也可以进行“技术评审”。所谓“走读”，其主要是对文档进行检查，通过走读发现文档中存在的缺陷（可能包括逻辑矛盾、描述模糊和文法错误等），同时参与人员也可以进行技术交流，初级人员也可以学习一些技术方面的知识，了解设计者的思路。而“技术评审”是一个相对正式的评审过程，其在规格、标准等方面进行评审，并在评审后给出相应得修改意见。
        理论上，一些模块构架级别的东西，应该在概要设计阶段就已经的得到了解决。我们在评审时，不需要在框架问题上多花功夫。但是在实际操作中，一些构架方面的东西往往到编码的后期还在不停的修改。因此，在进行概要设计评审时，设计者应该做好改变甚至推翻模块原有框架的心理准备。
        详细设计的评审，应该提前制定相应得计划，并做好充分的准备，制定评审的入口准则和相关规程，确定评审时间，安排相关组织者和与会人员，准备所需材料等。
        同行评审由专门的组织者主持，并有作者和相关同行出席。其规模不宜过大，大致可以控制在七人以下。在会议过程中，可以先由作者对其详细设计进行讲解，引导大家进行走读。然后参与者们共同对详细设计进行评审，确认问题，并对其进行分类。
        一般情况下，同行评审可以被控制在两个小时之内。一些简单的模块，可以把同行评审压缩到一个小时之内。在评审过程中，如果遇到问题需要延时，可以由作者决定是否召开“第三小时会议”。
        评审结束后，有必要对评审问题进行跟踪，以便确认确陷的到了修改，并且没有引入新的缺陷。
        作者简介：王俊夫，软件测试工程师，早年曾参加51Testing软件测试培训，从师于周峰、宋峰、王琰等测试牛人门下。其在学习期间注重于测试流程的理论研究，后加入上海新致软件有限公司，现为中国软件测试行业非资深软件测试工程师。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。