产品发展越快，对代码的管理也就需要越严格。通常代码在进入QA测试环节前就要进行代码review。review的目的倒不是为了发现bug，主要是为了避免代码设计上的缺陷和保证代码的可维护性。当然还有针对性的review比如安全性、性能、易用性等等。代码review除了可以提高代码的品质外，还能加强团队的协作精神，以及提高团队的整体技术能力。显然这是一件非常有意义的事。

前端代码更需要review。对于本身就不严谨的前端开发语言（html/css/javascript）来说，规范性尤为重要。常常因为各种原因凑合，最后注定要花费更大的代价挽救。也许做好这件事最大的阻碍是时间，活都干不完，哪有时间review。大家对review如果有消极或抵触情绪，review的意义会大打折扣。实际情况如果不能保证上线前所有代码都经过review，即便强制通过工具做到，也会流于形式，反倒丧失原本的意义。

重新调整前端代码review的目的：
1. 落实规范。代码风格的一致性是保证代码可维护性的基础。为此针对代码风格会出台一系列Guidelines，人review和机器review（如jslint等工具）结合是落实规范的有力保证。在制订这些规范时，要考虑它在这方面的操作性。参考http://bit.ly/douban-css, http://bit.ly/douban-javascript。

2. 教育意义。review的过程也是相互学习的过程。大到使用某种新技术，小到一行代码的写法，从中都可以学到东西。从这个方面来说，即便上线前没时间review，上线后能够总结收获和经验，对其他人起到某种教育意义这样的review也是很有价值的。

3. 荣誉感。对于工程师来说，这是比奖金更强的动力。众目睽睽下一段丑陋的代码被别人指出来是多么尴尬的事情。同时，要为一周一次的代码review准备足够的可讨论的changeset。世界上没有甘愿平庸的工程师。

4. 发现问题和积累成果。如果没有代码review，在每周的周会上也可以讨论这些问题。但泛泛而谈远没有看着具体代码来的真切。所以我们废除周会改成周期性的代码review。

5. 促进团队协作。周期性的代码评审会也是某种意义的交流会，大家可以了解彼此在做的事情，哪些可以解决自己的问题，或是我做的正好可以帮到别人。review的内容不局限于产品代码，也可以是一个跟具体产品无关的基础类库。

当然，也可以利用工具，对上线前代码做强制审核，未通过的不能上线。但这样容易流于形式。我还是觉得面对面的review更好。

做好代码review需要注意的问题：
1. 规模。人数5、6人为佳，人太多，时间拖得太长，越到后面效果越差。

2. 时间。最多不超过1个半小时，最好控制在1个小时内。

3. 代码量。400〜600行代码之间。越多发现的问题就会越少。

4. 形式。提前将要review的代码链接、changeset链接准备好。找个会议室，集体看投影，或带上各自电脑。每个人轮流讲自己的部分。放点音乐活跃一下气氛也不错

5. 简要介绍应用场景。更多还是针对代码本身，诸如为什么做这些改动，删掉原来的代码解决什么问题，代码写法上有什么问题，用到哪些技巧性的东西等等。介绍完之后，留出一定提问的时间。
参考了：http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review

前端代码review我们也是在不断的尝试中。向后端工程师借鉴经验。重要是明确它的目的，不让它流于形式，真正起到积极的作用。