我们的目的并不是定义一套固有的代码回顾实践方式，而是为回顾者 (reviewer) 提供一份清单。
当然，它也帮助开发者了解在代码回顾时如何扮演好一名回顾者的角色。回顾者本应如此专注于撰写更好更简洁的代码。
因为代码的作者没有进行自我回顾。所以开发者需要一种新的方式——很显然他们可以持续提炼并改进代码。
代码回顾对事不对人 (Code Review is about the code not about the coder)
首先，代码回顾只专注在写出来的代码上。
这种场合最应该做的是确认代码符合既定标准、最佳实践等等，务必回避指责作者的行为。
没有人能够挑战这一原则，不论他是新雇员、老鸟、主管哪怕是 CTO。
我们必须意识到，没有任何代码是足够优秀到不需要回顾的。
同时，这也是分享开发技术技巧的绝佳时机，再顺便探讨一下当下流行的编码方式，何乐而不为呢？
这里的清单是指一套代码回顾时遵循的要点集合。
同时这份清单也会帮助开发者理解哪些东西需要回顾。
这件事情排在步骤 0，因为实际上它并不算在清单本身的范畴内：编码规范是需要时刻遵守的。
也就是说，每一名开发者都必须遵循既定的编码规范。
代码质量能够确保：
- 减少 bug 数量；
- 让每个人都读得懂。
前端团队可以通过 JSHint 或 Plato 等类似的工具来监控 JavaScript 代码的质量。
回顾者要确保写出的代码能够满足需求，正常工作。
回顾者要确保代码直接有效的解决了问题。
然后我们可以通过 JSHint (详见第 2 条) 来计算条件复杂度。
复杂度和 bug 的出现频率是由相关性的。
基本上，越是复杂的地方，就越要简化。
回顾者确保另一名开发者也可以对现有代码进行快速修改。
回顾者确保代码是 (比如通过一些模式达到) 模块化的，并且变量和方法的命名是清晰的。
HTML 和 CSS 选择器也同样如此。我们必须能够理解 class 或方法表现出的含义。
还要确保一个方法做一件事的原则。
性能问题不仅限于 js 或 css 文件的压缩比率以及对图片精灵的使用。
它还存在于循环、数组操作、DOM 操作等方方面面……
jsPerf 是一个非常棒的工具，它可以在线测试一段代码在各种浏览器中的性能：http://jsperf.com/。
例如 : 比较 jQuery 1.7 中各种选择器的性能差异
- CodeShip 的代码回顾: http://blog.codeship.io/2013/08/22/the-codeship-workflow-part-2-pull-requests-and-code-review.html
- 一个清单示例: http://courses.cs.washington.edu/courses/cse403/12wi/sections/12wi_code_review_checklist.pdf
- Hadoop 的代码回顾: https://wiki.apache.org/hadoop/CodeReviewChecklist
- Yassine Azzout (创建者)
- 勾三股四 (中文翻译)