Skip to content

Latest commit

 

History

History
152 lines (96 loc) · 7.82 KB

readme.md

File metadata and controls

152 lines (96 loc) · 7.82 KB

前端开发者的代码回顾清单

我们的目的并不是定义一套固有的代码回顾实践方式,而是为回顾者 (reviewer) 提供一份清单。

当然,它也帮助开发者了解在代码回顾时如何扮演好一名回顾者的角色。回顾者本应如此专注于撰写更好更简洁的代码。

因为代码的作者没有进行自我回顾。所以开发者需要一种新的方式——很显然他们可以持续提炼并改进代码。

理念

代码回顾对事不对人 (Code Review is about the code not about the coder)

首先,代码回顾只专注在写出来的代码上。

这种场合最应该做的是确认代码符合既定标准、最佳实践等等,务必回避指责作者的行为。

没有人能够挑战这一原则,不论他是新雇员、老鸟、主管哪怕是 CTO。

我们必须意识到,没有任何代码是足够优秀到不需要回顾的。

同时,这也是分享开发技术技巧的绝佳时机,再顺便探讨一下当下流行的编码方式,何乐而不为呢?

清单

这里的清单是指一套代码回顾时遵循的要点集合。

同时这份清单也会帮助开发者理解哪些东西需要回顾。

0. 编码规范

这件事情排在步骤 0,因为实际上它并不算在清单本身的范畴内:编码规范是需要时刻遵守的。

也就是说,每一名开发者都必须遵循既定的编码规范。

1. 代码质量

代码质量能够确保:

  1. 减少 bug 数量;
  2. 让每个人都读得懂。

前端团队可以通过 JSHintPlato 等类似的工具来监控 JavaScript 代码的质量。

2. 一致性

回顾者要确保写出的代码能够满足需求,正常工作。

3. 简单

回顾者要确保代码直接有效的解决了问题。

然后我们可以通过 JSHint (详见第 2 条) 来计算条件复杂度。

复杂度和 bug 的出现频率是由相关性的。

基本上,越是复杂的地方,就越要简化。

4. 可维护性

回顾者确保另一名开发者也可以对现有代码进行快速修改。

回顾者确保代码是 (比如通过一些模式达到) 模块化的,并且变量和方法的命名是清晰的。

HTML 和 CSS 选择器也同样如此。我们必须能够理解 class 或方法表现出的含义。

还要确保一个方法做一件事的原则。

5. 性能

性能问题不仅限于 js 或 css 文件的压缩比率以及对图片精灵的使用。

它还存在于循环、数组操作、DOM 操作等方方面面……

jsPerf 是一个非常棒的工具,它可以在线测试一段代码在各种浏览器中的性能:http://jsperf.com/

例如 : 比较 jQuery 1.7 中各种选择器的性能差异

延伸阅读

作者与贡献者

当前

协议

MIT license