标签：
原文链接： https://www.sitepoint.com/the-importance-of-code-reviews/
原作者： Hugo Giraudel 发布日期： 2016.6.10
------------------------------------------------------------------------------------------------------------------------------
最近我在Twitter上读到这段话：
可悲的是，貌似对于很多学生、自由职业者和机构来说，代码审查都是一种无关紧要的行为。
显然，代码审查实际上很有帮助这一点并不是显而易见的。即使你说我幼稚， 我依然真心的认为这是所有IT公司应有的流程之一。但显然我是错的，这让我感到害怕。
在这篇文章中， 我希望表达我对于代码审查的想法，关于为什么我相信代码审查是代码产出过程中的一个重要部分，还有怎样开始代码审查。 如果你从不做代码审查，或者你觉得你可以做的更好， 我希望这篇文章会对你有所帮助！
什么是代码审查？
我们生活在维基百科时代，请允许我从引用代码审查条目的定义来开始这篇文章：
代码审查是对计算机源代码进行系统的检查（有时也被称为同行间的审查）。它的目的在于找到开发初期被忽视的错误，提高软件的整体质量。审查可以以各种形式完成，如结对编程，非正式的抽查，和正式检查
代码审查，顾名思义，是一个检查代码并确保其能正常工作的过程，并且尽可能的优化代码。
代码审查的各种方法
根据维基百科的字条定义，有各种各样的代码审查方法。然而，在这个大量代码都存放在github的世界里，代码审查经常需要手拉手的进行，我们称之为”拉取请求“。
拉取请求是在分布式版本控制系统（Git、 SVN、 Mercurial等等）中，用于引入一个代码库变更的请求。 他的工作方式是：请求通过”拉取“源代码，获取改动，然后提交一个请求将改动合并到本地代码中。
Github使这个过程特别简单和高效，这得益于它友好的用户界面，同时它让它的用户不需要具备大部分git知识也能很好的使用他。
为什么要回顾代码问题？
所以说，为什么要回顾代码问题？ 毕竟，我们都是能胜任工作的人。当然，即使没有人默默地站在我们背后看着我们也能写出代码。
理论上，是的。 但实际上，有很多原因支持固定一个代码审查流程是很有帮助的。让我们看看其中一些原因。
限制风险
这可能是所有原因中最重要的一个。有人能仔细检查我们的工作从不会带来坏处，并且这能减少因为粗心的犯错带来的风险。 即使再好的开发人员也有打马虎眼的时候。
能确认没有忘记什么东西总是好的。例如，正确的键盘导航、无障碍屏幕阅读器、灵活的国际化和用户友好度，无javascript行为等等，这些是在前端世界经常会被遗忘的主题。
极大的提高代码质量
让我们明确一些事情： 这与标准和代码检查无关（至少不仅仅和这些有关）。 这是关于让代码更高效的。
在团队中的每个人都有他们各自的背景和强项，追求进步（因为代码审查就是干这个的）永远是一个好主意。有些人可能会提出一个更聪明的解决方案，用一个更适合的设计模式来降低复杂度并提高性能。
让每个人都变得更好
通过合作，每个人都可以学习并进步。代码提交者可能希望得到关于他们的工作的反馈，让他们可以察觉到可能的问题和发现能改善的地方。审查者则可以通过读别人的代码学习到很多新知识和技巧，并找出适合他们自己工作的解决方案。
有助于熟悉项目
当一个团队在项目上工作，不太可能每个开发人员都能接触到程序的所有部分。通常一个开发人员会在一段时间内对一个较大的部分进行大量开发，与此同时，另一个人则完全在开发其他不同的部分。
代码审查能帮助人们熟悉那些不是他们写的，但是将来有可能要他们维护的代码。 它能促进代码库的知识在团队间传递，这将有助于提高未来的开发效率。
如何正确的进行代码审查？
再次，有一个既定的代码审查流程是非常有用而且重要的。每个团队生产代码时都需要进行代码审查，只是方式可能不同。
话虽如此，执行一个有意义且有帮助的代码审查并不总是像它看起来的那么简单直接。别担心，即使你做得不好，也不会带来什么副作用。 它只是没什么用和让你感觉在浪费时间而已。
最近在我公司，我要对我们的代码审查流程进行一个回顾。当我们意识到只有12个中的3个开发人员能通过代码审查时，我们已经知道有些东西我们做错了。
为了帮助我们改变这一现状，我们的其中一个Scrum负责人组织了一次回顾活动，来确定哪些地方还有优化空间，以及我们如果实现优化？
提前规划
最常听到的缺席代码审查的理由是它太花时间了 -- 这些时间是人们不能或不愿意承担的。
我必须要说，我真的不明白这个理由， 因为我经常想象这个画面：如果一个同事直接找到我并向我寻求帮助， 我不会说 -- ”我没时间， 也没兴趣。“ 我会腾出时间来帮助他。 虽然未必是马上， 也可能在一小时内 -- 但显然我会在他们身上花时间。 为什么？ 因为：
· 这就是团队意义的一部分
· 如果他们希望得到我的意见，不管怎样，这是因为他们看重我的意见，因此，我认为我只能说出我的意见。
“为什么你不参加代码审查？”
“我没空。”
对我来说，一个拉取请求和一个牛仔来寻求帮助没有区别。每次都说你没时间是一个完美的理由，但通过系统的拒绝帮助，你是在积极的将自己排除出团队。这种行为既不友好，也不积极。 请花点时间来提供帮助。
为了让开发人员能有时间，我们开始考虑到每个开发人员每天都会花一点点时间在代码审查上（大概30分钟）。即使最终我们花费了一个半小时来进行一个一个大型的代码审查也不需要感到惊讶： 这本来就是当天工作的一部分。
我们也尝试通过一次拉取请求来大幅降低代码整合的次数。我们过去都使用非常巨大的拉取请求 --- 一次拉取横跨几十个文件的几千个改动。
我们尝试再也不用那么做了。 通过制造更小的拉取请求， 我们让他们更容易审查， 得到的反馈更加有用，而且开发人员也更愿意参与这个过程。“更小更频繁的提交代码”。
给出上下文
第二大的问题是我们发现我们经常因为不清楚代码的上下文环境导致理解困难，如果你打算提供对别人有帮助的反馈，清晰的上下文条件是很有必要的。当失去对上下文的了解时，我们经常无法对语法以外的内容进行审查 -- 虽然这在一定程度上也是有用的， 但这还不够。 你只是简单的变成了“人肉语法检测机”。
幸运的是， 这个问题的解决方案也相对简单：对这个拉取请求添加一个关于其目的和如何得到的说明即可。 这不需要写一整墙的文字来说明；通常只需要几行字就够了。为这个请求添加一个链接和/或一个故事也是很有帮助的。Liv Madsen， 我们的开发人员之一， 甚至为了说明她干了些什么而添加过截图或相应的录屏， 真了不起。
真诚的请求
我们指出的第三个问题是我们有时只是简单的意识不到有些东西需要审查。让我们面对它，我们每天都会被成吨的邮件和通知淹没 -- 太多了，以致让我们无法保持原本的轨迹。 毕竟，我们只是人类而已。
再次回到原来的问题，解决方案非常简单：真诚的请求某人来进行一个审查。 这么做可以有很多方法，通过在办公室里大声吹喇叭来检查有没人有空；到他们所在的每个团队去问。
我们在Github上成里了基于我们的活动的讨论组， 而且当提交一个拉取请求时，我们总会告诉我们的讨论组。讨论组的成员会收到一个通知，而且能在他们有空的时候随意的抓住这个拉取请求。有时，我们会直接找到一个（或几个）开发人员， 如果这是与某人的工作关联特别紧密的。 这都可以。
因为有一些拉取请求被盲目的合并而且完全不顾提交附带的说明，我们指定了一个严格的“回复或解决一切”的政策。 当收到反馈，除非你已经修复或回复并解释清楚为什么你不遵照反馈来做。 在任何情况下， 你都不可以搁置任何注释， 当然你也不能在还有未处理的注释时合并你的拉取请求。
把东西都打包
拥有一个定期并高效的代码审查流程对维护高质量的代码标准是非常必要的， 这能让开发人员像一个团队一样成长并互相共享知识。
要求进行代码审查并不是软弱的标志。请求帮助一点也不应该感到尴尬， 当然这也不应该出现在代码审查的形式中。 接受所有给你的反馈，并提供有建设性的（理想情况下）评论给拉取请求的提交者。
找到对你有用的东西。 代码审查应该是代码交付流程中一个很大的部分， 所以你应该把它加入到你的团队中。 把它变成你希望的方式， 这回对所有人都很有帮助并起到积极作用。
快乐的审查吧！
------
2016.08.01
标签：
原文地址：http://www.cnblogs.com/bee0060/p/5703545.html
