“哦，不要让我开始代码审查！”加里Heusner，在定制软件开发的客户合伙人Geneca在那些只能被描述为马文安卓语音。“对于许多商店，代码审查是一样普遍的灾难恢复演习。”
要成功地运行代码复查，您的第一步是确保进行了代码复查。代码评审过程通常是项目中最先被抛弃的项目之一，Heusner感叹道，“通常是在有人修剪之前用户验收测试对于一个为期四个月的电子商务项目来说，要用不到一周的时间。”这种情况甚至在软件开发部门也会发生，在这些部门中团队个人关心质量。任何关于“代码评审”的提及都会引出这样的评论:“这样做不是很好吗?”或者“我听说有人做了最后一个项目”或者“值得为此付出努力和金钱来进行代码评审吗?QA仍然要测试一切无论如何？”
但它的一两件事，说你要做的代码审查。它是另一回事知道如何去过程中的权利，从而使最终的结果是最好的，最快乐的应用成为可能。理想情况下，你也建立一个协作的工作环境，创造一个更灵活的开发过程，哦，是的，在工作中有更多的乐趣。在这篇文章中（和它的伴奏），我分享几十个充满激情的软件开发商（哦，孩子，是他们激情四射！）什么时候和怎么做代码审查，谁应该坐在桌子收集的智慧和代码的严重后果评语是做错了。顺便一提，他们做错了很多。
我试图使这是一个明确的指导代码审查，这意味着我已经分裂的各种问题纳入了几篇文章。这让你可以专注于解决那个天色你的短裤扭成结的问题。但我喜欢认为你需要阅读整个事情;你没有在任何特定的顺序来做到这一点。这里的一切都在这个包：
运行有效的代码审查(本文)
进行代码审查的原因
在代码审查中寻找什么
使代码审查软件工具帮助，不会阻碍
如何领导一个代码审查（让我们建立和领导的审查）
如何不运行代码评审
这样做与远程团队喷滴代码复审
什么代码审查的种类是这样吗？
在你走之前桶形与打印输出的堆栈和当地的电话号码武装的会议室披萨外卖联合，确保你知道为什么你得到球队在一起。代码审查可以有很多用途，你将有一个非常糟糕的一天，如果大家有什么本次审查的目的是不同的想法。
您可能希望为项目的每个方面安排不同的代码检查，比如一个检查安全问题，另一个检查特别关注安全问题应用程序的性能。
“第一步应该是确定你为什么要检查代码”，暗示迈克尔拉朗德，在QLogitek技术总监，一个SaaS的供应链解决方案供应商。“这应该是从设计时的讨论，其中核心非功能性需求而制定的。这些可能包括，但不限于，全球化、性能安全和保障。“重迭代的目的在会议开始时帮助球队把它的注意力集中在实现最大的投资回报率的项目，拉朗德说，”举例来说，如果你正在寻找的表现，你不会在乎过程被称为在例外情况下，所以接受一个自动代码审查就足够的结果“。
一次只做一件事还可以确保开发人员一头扎进软件的单一方面，而不会一次尝试做太多事情。微软亚洲硬件中心(Microsoft Asia Center for Hardware)的软件导师Theron Welch正在帮助在中国组建一个团队，他说:“通常情况下，一个运行糟糕的代码评审会让每个人都关注同样的表面问题。”一个代码检查表可以帮助鼓励一个较小的小组深入关注一个特定的领域，另一个小组关注另一个不同的领域，等等。这有助于代码复查达到深度。”
审查的目标，这两个具体的审查，并在这个过程中一般是由业务需求，其体制上的偏见，队员们的状态和参与者的角色通知。例如，杰克Danahy，盎司实验室的创始人兼CTO，说道，“当你在银行的时候，你已经习惯了一个金库的心态在金融服务，有两个比较大的问题：隐私和数据的完整性，并该数据的非取得名声“。当金融服务机构进行代码审查，他们正在寻找一组特定的事情，他说，如要确保互动和授权链是干净的。Danahy补充说，“在公共部门，目的是更加围绕确保应用程序的工作，他们预期的方式。有没有那么多详细的重点，而是着眼于一般特征，‘它的工作原理？’”典型的代码评论是关于通用的政策，如确保输入验证，而不是在开发商必须更细化的政策确保私人数据被妥善保存， 他说。
保持对这个代码审查的目标，球队的注意，并避免与其他问题分心是很重要的。一个非常常见的错误，说SOA专家Mike Kavis，是供审阅人员挑战设计的。“这个设计应该已经被熨平设计评审而不应该是在代码审查讨论的一部分，“他说，”这就是为什么它是非常重要的设计评审进行;否则代码审查程序可以发送回开发的绘图板“。
芝加哥技术管理咨询公司Solstice Consulting的执行合伙人施万(J. Schwan)指出，个人背景也会影响评估结果，具体取决于开发人员是初级还是高级。例如，Schwan说，在初级开发人员的代码评审中，目标应该包括遵守设计阶段定义的设计或架构;确保编写的代码能尽可能有效地执行;以及使用通用代码模块。Schwan说:“对于高级开发人员来说，同级代码审查通常更有效。”“目标可以更集中于确保通用代码模块的使用，并确定其他通用代码模块可以被系统的其他部分重用。”
下一页：什么是正确的时间？
计划何时执行该代码审查
这一招，当然，是运行代码审查很快，往往不够及时发现问题，没有在第一时间编写代码的方式获得。
对于很多球队，代码审查周期应启动不久后，设计审查完成。史蒂夫·波特，在Imaginet技术研究院项目经理，表明球队的怀抱设计审查，而不是代码审查，因为后者有时会出现来不及纠正错误。“设计评审帮助识别不同的路径，你可以拿得到的最终解决方案，并帮助开发者或团队做出正确的选择的早期，而不是之后，时间已经花了审查编写代码。”
Christopher Buchino是微软公司软件工程总监GotVMail通信认为代码审查特别有用在一个新项目开始的时候或者当有人新加入的项目。这有助于开发人员学习球队的标准，风格，睿智和建筑。“代码库中有均匀性对可维护性非常有益的，这是让人们以类似的方式编写代码的好方法，” Buchino说。
建议QLogitek的拉朗德，“只要你觉得舒服的执行代码审查单元测试已经确定需要人工评审的代码。”
但总体而言，经验丰富的开发人员认为代码审查应该是软件开发的不可转让的部分生命周期，不应该是自愿的。亚历克斯·拉塞尔，在Dojo工具包大师谁现在是谷歌工作上的Chrome网络浏览器说，“代码审查不工作时，他们可选的。他们需要尽可能多的程序的一部分，从主干合并的。”
周杰伦迪金斯，Deacom的创始人和总裁，一个ERP软件生产商的建筑构件和批量处理行业，说：“该软件的代码审查过程确实应该关闭一个精心策划的开发周期，并不是一开始一步的点进行检查。“然而，他指出，该代码应该是合理的高品质让它在正式的代码进行复核。
时相比，可怎么往往更重要。这应该是定期。罗素说，“代码审查，一个月以后你写的东西后，很可能会成为一个验尸。获取反馈，你的头仍是‘代码’是显著更有价值比的代码审查你忘记的血淋淋的细节。“
对于一些开发商而言，这意味着每周的正式审查。对于其他人来说，这是一个简短的日常会议。
日常？！不就是花太多时间？如果你不打算申请敏捷过程前代码实现，诸如框图和非正式scrums在实施过程中，根据开发者查克·布鲁克斯。
杰森·科恩，公司创始人Smartbear软件（其中，你应该知道，销售工具，以帮助在这个过程中），表明开发团队，每个人都试图做代码审查仅一周，每天20分钟。“抛开你的悲观情绪只有那一周，并给它一个公平待遇。”科恩敦促开发团队来衡量所花费的时间，你有多少缺陷发现（刚刚在此试用期内），然后计算“每个缺陷，我们发现分钟。”您可能会发现它的8〜15分钟，科恩说。“有没有在您的公司的任何其他过程可在这样的速度发现和修复缺陷？难道这不是意味着这是一个好主意吗？”
当然，如果参与者不愿意待在房间里，那么所有这些都不会有任何好处。
警察正确的态度
有在代码审查两个实际管理的危险：自我和政治。大多数开发人员都提出了建立正确的态度来创建有效的代码审查的问题。这通常是为了确保开发人员愿意听取关于如何改进代码的输入——否则，为什么还要费心呢?以及避免人类把这些会议变成令人讨厌的竞赛的不幸倾向。
在很大程度上，这是关于信任。能有多大的开发商相信别人她的作品有给她有效和有益的批评？在一个健康的环境中，文化是支持，每个人都愿意帮助其他团队成员，通常这不是一个问题。（感激）。但话又说回来，它可能是。没有什么比个人作为艺术创造的人，和开发人员可以非常保护他们的工作，并渴望赞美。（所以文章的作者，顺便说一句，我只是在说）。
道格开利，产品经理康博Devpartner（注：另一家供应商）指出，开发商有时会认同自己有点过于紧密地与他们产生的代码。“代码审查可以使开发者感到过分批评，羞辱或以其他方式由他们的同辈或上司欺负。开发Alpha类型通常会出现并维护它们在代码审查过程中的最高角色。这可以在开发团队中释放出一系列组织、行为和情感问题。”
是现实的，特别是如果你是团队领导或经理。“虽然代码审查过程的目的是为了提高代码的质量和可维护性，现场代码审查仪式是充满了自我和个性的元素，可以使这个过程为开发商相当痛苦谁只想做一个好工作，”运营商说。
避免任何意义，审查是一种惩罚性措施，它是关于损害控制，或者说，它是专门对他们的工作正在审查开发商的目标，”建议杰夫·本森，在Geneca技术负责人。这是尤其如此熟练工级开发者。“随着编码器变得更有经验，评论往往被视为侵入和怀疑，”迈克尔·Ryding，在英国AXA的IT解决方案顾问说。
Smartbear的科恩表示，双方都需要开放的思想。“如果参与者希望代码评审过程失败，他们就会赢。如果你故意不去尝试，花很多时间却发现很少的漏洞是很容易的。”
因此，如果您正在运行一个代码评审，或者只是其中的一个参与者，那么使用正确的配置设置您的期望是很重要的。“代码审查的目的是互相学习;OPSWAT的创始人兼首席执行官Benny Czarny说:“如果没有详细的解释或公开的讨论，谁也赢不了。”OPSWAT为终端应用的安全特性提供开发工具和数据服务。
高级软件工程师Michael Doubez建议，在每次会议之前，最好重新建立规则(尊重、谦虚、富有建设性)，并重申代码审查的目标(设计与需求的相关性、编码标准、定位错误)。
让会议变得有趣、活泼、乐观，并培养自己共享启蒙的气氛。Ryding UK解释说，“每个人都需要知道，他们都可以学到一些东西，他们没有殴打，并在那个小家伙笑了。”