查看原文
其他

【第91期】前端开发者的代码回顾清单

Jinjiang 前端早读课 2021-01-11


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


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


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


理念


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


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


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

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


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


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


清单


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


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


0. 编码规范

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


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


1. 代码质量

A:代码质量能够确保:

B:减少 bug 数量;

C:让每个人都读得懂。

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


2. 一致性

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


3. 简单

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

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

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

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


4. 可维护性

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

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

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

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


5. 性能

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

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

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



    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存