在前几周的课上，我们学习了同行评审并且进行了演习，在其中学习到了很多知识。
所以这周的博客我想总结一下同行评审的知识点。
同行评审：同行评审是在软件开发完成之前，通过技术专家发现潜在缺陷的一种有效手段，和在代码完成之后进行的软件测试可以相辅相成，提升软件的质量。
同行评审（Peer Review）是一种结构化的正式评审，由生产者（作者）的同行，为识别异常和需要修改的部分而对工作产品进行的有组织、有计划的检查。
同行评审并不是对个人的工作不信任，其目的是尽早有效地消除软件产品中的异常。
同行评审的原因：
第一，凡是人皆有出错的时候，要保证你做出的东西错误尽量少，就需要他人对其进行评审。这就是所谓的“三个臭皮匠，顶个诸葛亮。”
第二，对于软件产品来说，缺陷发现得越早，纠正缺陷所需的费用就越少。因此，在软件的开发阶段，如果严格进行同行评审，那么后续流程中出现的错误就会很少，这也可以为公司节约纠错的成本。
第三，同行评审过程中发现的错误可作为案例传承下去，避免开发人员再次掉进同一个陷阱。“前事不忘，后事之师”，别人所犯的错误对自己有警示的作用。特别是对于新员工来说，经常参与同行评审，可减少试错的次数，也能够达到对新工作及早上手的目的。
同行评审的对象：
在产品开发的各个阶段中，需要参与同行评审的对象包括：
-
概念阶段：产品需求说明书等。
-
计划阶段：系统方案、项目计划等。
-
开发阶段：详细设计、单元测试规程（方案）、集成测试规程（方案）、代码、数据库脚本等。一般而言，在开始编码之前，先要进行详细设计评审，以确保程序流程的正确性，减少后续修改带来的不良影响。
-
验证阶段：系统测试计划、系统测试规程（方案）等。
同行评审分为五个角色，分别是：
Moderator：
负责评审过程的关键人物，收集检查数据错误分类、严重程度，控制评审进度、时间、内容
防止内容发散（评审变为发牢骚、幻想、工资待遇的讨论会）
Inspectors：
负责从通常的视点出发 发现成果物的缺陷，以及缺陷影响到的技术领域
局内评审人：熟知成果物的相关知识，对发现缺陷有积极性
局外评审人：可以为评审提供客观的新的视点和见解
Author：
成果物的（文件的）的信息做成人，为评审全过程提供评审材料的信息，在时间和成本允许的范围内，负责修改主要缺陷、及任何小的、零散的缺陷。也兼有评审员的身份。
Reader：
会议中负责阅读或意译成果物的细节，也兼有评审员的作用.
Recorder：
记录实际的评审过程中发现的缺陷,也兼有评审员的作用.
同行评审流程固然重要，但要彻底地执行下去，需要做到以下几点：
第一，公司要明确规定所有的软件开发项目必须走同行评审的流程，并定期抽查同行评审的执行情况。
第二，作者本人要持有开放心态，愿意分享自己的工作成果，并勇于承认自身的不足而加以改进。很多人都不大乐意被别人指出自身的问题，而同行评审的目的就是要发现问题，因此，这在一定程度上是对作者心态的考验。作者本人要明白是产品有缺陷，要对产品中的问题进行完善。
第三，评审人员要对事不对人，要懂得同行评审是为了发现产品的缺陷，而非人自身的问题。不要将同行评审活动变性为针对作者本人的人身攻击，这就有伤整个团队的凝聚力。同行评审的一个宗旨就是大家在一起学习，取长补短，共同提高。
第四，公司要对同行评审的结果进行总结，并以文档的形式保存起来，方便后期查阅。很多软件产品出现的问题都是相似的。在着手开发产品之前，如果能够了解前期类似产品中出现的问题，那么大家就可以少走很多弯路，工作效率和产品质量也在无形中得到了提高。
为了确保软件产品的质量，所有的工作成果（包括程序、文档、图形等）都应该接受同行评审。“三人行，则必有我师”，不管是老员工，还是新员工，都能够从同行评审中受益。
在我们进行演习的过程中，发现了很多的细节细节需要我们注意：
-
同行评审要确保每次评审不超过规定的时长
-
确保专家发现的缺陷数的下限
-
最好不要针对一个问题讨论过长的时间
-
在评审过程中主持人要保证不要偏离主题
-
指定作者以外的人作为记录员
-
要注意纪律的保持
-
在评审结束之前对评审纪录进行检查，确定纪录无误与完整
-
在评审结束之前总结这次的经验教训
最后我觉得同行评审还是相当重要的，的确能在讨论中发现很多的问题，比如一些语言的规范，一些容易引起歧义的语言应该避免，此外，同行评审有利于提高产品的质量，更有利于团队的发展。