转载

编写可维护的JavaScript

每次亚马逊或者京东满xxx打折的时候,总会凑单撸各种奇怪的不知道哪年才会翻开来看看的书(大家不是都这样么:) )。前两天给同事 code review JavaScript 代码,由于我经验不丰富,看着总觉得心里没底。转眼瞥见书架上夹着一本 《编写可维护的 JavaScript》 ,虽然怎么想也想不起是什么时候买回来的,但记得 Sneezry 老师推荐过本书,便立马拿出来翻了翻。

作者 Nicholas C.Zakas 曾是 Yahoo! 的首席前端开发工程师(现在跑到 Box 去了),在书中介绍了编程风格、编程实践和自动化方面的 best practice 。大师果然就是大师啊,短短数小时内,我便产生了深深的共鸣,脑洞也各种大开。内心的喜悦不能独享,我决定为它写篇博文,讲一讲其中的“高光时刻”。

编程风格

本书的第一部分讲解如何使用统一的编程风格,降低团队项目的维护成本。几乎每一门语言都有自己的 styling rule ,靠谱的技术企业甚至会在企业内部推行的自己的编程风格(比如在 baidu 写 C++ )。

当我们谈论风格时,我们其实是在说

  • 缩进
  • 换行
  • 行的长度
  • 花括号的对齐
  • 注释
  • 命名
  • etc

你几乎可以在每一本语言书上找到这些章节。书中推荐使用 JSHint JSLint 等编程风格检查工具,个人觉得,选择其中一种并且推行下去既可以了,事半功倍。

编程实践

这一部分就是讲编程过程中的 best practice

UI层的松耦合

我们知道在Web开发中,用户界面由 HTML, CSS 和 JavaScript 三层一起构建的

  1. HTML 定义页面数据和语义
  2. CSS 给页面添加样式,创建视觉特征
  3. JavaScript 用来给页面添加行为

我们应当努力减少这三层之间的依赖性,让更改单独修改某个组件时无需修改其他组建。作者给出的建议,有这几条我觉得值得牢记

  1. 将 CSS 从 JavaScript 中抽离。举一个实际的栗子,我们经常在页面上实现 lazy loading,在 request 发送出去之后,我们会秀出一张菊花图提示用户正在加载,加载完毕后,隐藏或者删除掉这个张菊花图。最直接的做法就是在 ajax call 前后调整这张图片的 display 属性。但是这么做会带来一个问题,样式是由 JavaScript 而非 CSS 来加载的,当出现样式的问题时,我们会第一时间查看 CSS,但�最直 当我们查到精尽人亡的时候,我们才发现样式是由 JavaScript 改变的,一定会哭的。Best practise 是把所有样式保留在 CSS 中,当需要用 JavaScript 来修改元素样式时, 操作 CSS 的 className (计算元素定位例外)。
  2. 将 JavaScript 从 HTML 中抽离。很多初学者都会把脚本嵌入到 HTML 中来运行,比如在 element 上绑定 onclick 属性或者使用 <script> 标签。在这种情况下,当你需要更新这个方法的命名,你总需要更新 HTML 页面;内嵌的 JavaScript 会给调试和 troubleshoot 带来难度(至少是增加了复杂度)。Best practise 是 把绝大多数的** JavaScript 代码放在外部文件中**。
  3. 将 HTML 从 JavaScript 中抽离。模版化发展到今天,这条规律几乎不言自明了。

避免空比较

这个比较绕口,举个例子大家就明白了,通畅我们设计一个函数时,需要考虑传进来的参数是否正确,比如不能为空,不能为 undefined 。像下面这段代码:

function Process(items) {  if (items !== null) {      items.sort();   items.forEach(function (item) {});  } } 

事实上在这段代码中,我们真正关心的是 items 这个 object 是否为一个 Array 。单纯的和 null 进行比较,代码的可读性不好,coverage 也不够。本书的建议是,使用诸如 typeof, instance of 等来检测原始值( primitive value)、引用值和函数等。

 if (typeof name === "string") {  } 

上面的代码就清晰的交代了函数期待 name 这个 variable 是一个 string 而非其他类型的值。

其他

这一部分其他章节,个人觉得在其他编程语言中也基本适用,比如

  • 避免使用全局变量
  • 使用命名空间和模块
  • 将配置数据从代码中分离出来
  • 自定义 error

或者比较 hacky,比如 浏览器嗅探。读者可以在互联网上找到更全面的解决方案。

自动化

第三部分,作者花了八个章节来讲解如何对前端代码进行开发、测试、部署、文档的自动化。作者写这本书的时间距离现在已经过去数年,前端自动化已经逐渐成熟并且被广泛接受,你一定或多或少见到过以下工具

  • Task Runner. Grunt/Gulp,这两个工具其实代表的是一套工具链,比如代码合并(concat),代码压缩(minification),代码风格审查( JSHint/Lint)等等,然后通过 task runner 将这些工具组合到一起。
  • CI. Jenkins/TeamCity
  • Test Framework. Protractor/Selenium
  • etc…

如果你们的前端团队还没有使用到上面提到的任何工具(或者自己造了类似的轮子),那情况可能就有点不妙了。

放在最后

不管我自己是否承认,我已经成为了一个半路出家的前端工程师了,和我最先估计的职业生涯路线有点偏差。我司大部分部门招人的策略是招聪明的人而非招专业的人,这就导致了来我司前你耍什么技术已经不那么重要。过去我司比较保守,一定要 dogfood,大家来了就只能使用 .NET,使用开源或者别家的技术十分谨慎。但是这两年突然 open 起来了,按照需求你可以自由地选择前端框架(像我们就用 Angular)、缓存(Redis已经称为第一选择,大阿哥AppFabric被废黜了)、搜索引擎(elastic search 大家都得用啊)、测试框架(Selenium已经接连KO VS测试框架和MTM)等等等等,不知不觉中人人都变成了全栈工程师。也不知道这算不算好事。

简言之,读者朋友们不太可能在我的博客上看到 .NET 的文章了,让你们失望啦 :)

正文到此结束
Loading...