朴灵：打破限制，从前端到全栈（图灵访谈）
朴灵，真名田永强，文艺型码农，Node.js 布道者。现就职于阿里巴巴数据平台，任资深工程师，著有《深入浅出 Node.js》。他活跃于 CNode 社区，是线下会议 NodeParty 的组织者，同时也是 JSConf China（沪 JS、京 JS，以及杭 JS）的组织者之一。朴灵热爱开源，是多个 Node.js 模块的作者，个人 GitHub 地址：http://github.com/JacksonTian。叩首问路，码梦为生。
从前端到全栈
“当时我们团队的 Leader 不会去限制工程师做什么事情，而是说这件事是你在负责，所以你就要从前做到后。”
问：你从什么时候开始编程的？
我高二的时候才刚刚接触互联网，那时候看别人搭一个 BBS 我心里就特别崇拜，我很好奇这个过程是怎么实现的。以前有一个叫“中国博客网”的网站，上面提供了可以自己编辑模板的功能。在那个年代，脚本特效很流行， 我经常把代码拷到那个模板里面去，测试效果。后来上大学之后我才知道，这个论坛的构建者其实就是利用了一个类似于 Discuz 的系统，搭这个网站并没有想象中那么复杂。
问：听说你在大学学的是 Java，在这过程中你的兴趣点有没有转移？
学校教了很多东西，但是我的重心一直放在前端技术上。虽然学校教了C和 C++ 这样的语言，但是教了之后也不告诉我们这个东西到底有什么用，所以我当时仍然痴迷于网页。工作几年以后才发现学校教的东西很有用，所以现在再回去补。
问：你是怎么变成所谓的全栈工程师的？是你自己的兴趣使然还是工作环境给了你这样一个机会？
我一般不说我是全栈工程师（笑）。我刚进大学的时候，目标其实很明确，就是想看看那些 JS 特效是怎么实现的。2009 年毕业之后我开始工作，就侧重去做前端。那时候前端也才刚刚兴起，后来我就成了一个真正的前端工程师。
去了淘宝之后，我碰到了 Node.js 这样一个我很感兴趣的东西，我用了两年时间完成了从前端工程师到全栈工程师的演变。我的个人习惯就是，如果我对什么感兴趣，就会在这块投入精力去研究。所 以通过这一两年的学习，我已经可以完成所谓的后端的工作了。当时我们那个团队由空无和玄澄带领，他们不会去限制工程师做什么事，而是说这件事情是你在负 责，所以你就要从前做到后。
问：在你看来全栈意味着什么？你在 QCon 大会上主持了这个专题之后有没有带给你一些新的思考？
以前我认为全栈就是一个开发者能力的提升。如果你在某个领域非常专，有一个点很擅长，这时候别人才称你是专家；如果你有多个点比较擅长，那别人 才有可能称你是全栈工程师。另外，责任也很重要。一个人不再只是负责在前端写 CSS，也不只是在大工程里面做一小块东西，而是有了一个全局的视野。我以前对于全栈工程师的理解可能就是集中在工程师个人能力以及责任这两点上，通过主 持 Qcon 的全栈工程师专题，我觉得还有一点，就是环境对全栈的影响。
个人能力是不太好复制的，有的工程师能力强，有的工程师能力没那么强，这种情况下你对能力稍微弱一点的工程师做这种要求，是很难达到目标的。 Coding 的分享给我带来了这个想法：基础设施建设对全栈的影响也是很大的。如果你不能帮助一个工程师成长，那就应该在环境上做出改变，你要去打造适合这样的人才成 长的环境才行，这样才是正向循环。
问：淘宝现在使用 Node.js 的范围有没有扩大，主站有没有在用？
主站也有在用。现在几乎每个 BU 都在用 Node 做尝试，不管它做的是大系统还是小系统。我看到有很多团队尝到了甜头，但我也看到有很多团队不愿做改变，不愿去尝试新技术。
问：方便说一下你现在的工作内容是什么吗？
我最近半年在社区都不怎么活跃，是因为我做的内容刚刚开始，现在才有了一些进展，将来我们有计划把我们做的东西对外产品化。我现在的主要工作就是改 Node.js 和 V8。在 Node.js 上改动我会直接接到 Io.js 的仓库里面，现在已经提了很多。
我可以举个例子解释一下我们现在做的事情。在 Node.js 社区上有一些性能调优的工具，比如 Chrome 上有个 CPU 调优工具，它可以帮你找出哪段代码运行得比较慢。我们在这个基础上做了更多的工作，我们做的这个性能调优的工具不仅要知道慢，还要知道为什么慢。用我的工 具扫过之后，我就知道怎么去改，其实现在我打的很多补丁都是通过这个工具发现的。造成性能慢的原因可能有很多，我们尽量去发掘这些问题。
另外一件我在做的事情就是帮助公司内的一些 Node 开发者。比如，这些开发者可能做业务开发时没有什么问题，但是运维或者运行的时候就会出现问题。我们工作几年来，并没有因为使用 Node.js 而造成什么故障，高手写代码不太容易出现问题。但是对于每个工程师来说要求是不一样的，我现在的工作重点就是：出问题的时候能够马上解决。线上代码慢的原 因是什么，为什么会有内存泄露，我们做了一些工具来解决这件事。
虽然用一个新技术的时候可能感觉很爽，但是这个技术会带来什么后果或者副作用，可能对于很多人来说都是没底的。为了让阿里的技术环境能够更健康 地发展，我们的工作就是要让大家知道，我们不怕这样的问题出现，能出现我们也能解决。现在我们努力在公司以内创造更好的环境，在未来我们有计划把这些东西 推出来，希望国内其他用 Node.js 的公司也能从我们的工作中得到一些好处，独乐乐不如众乐乐。我们希望自己能够做更多的事情，有朝一日能成为 Io.js 或者 Node.js 项目里面的核心贡献者，然后去影响它。
问：淘宝 UED 正在实践前后端分离，应该也有其他团队在做类似的事情，你怎么看？
我个人没有直接参与这样的事情。我觉得前后端分离是否能完成的核心在于服务化的程度。如果系统都是面向服务去设计的，那么在这个过程中解耦可能 很容易完成。所以当你真正做一个前端应用层的东西时，就不需要 Java 的同学来参与帮你写模板，而这个应用层可能是跟业务相关的。
这里的一个概念就是产品应该有两个部分：一个部分是系统层，另一个部分是应用层。应用层的需求可能天天变，但是这种改动基本上不怎么影响底层系 统的稳定性。系统层应该是趋向于稳定的，除非业务模型上有一些大的变化的时候才会去改动。而平常的日常迭代，也就是应用层，会有频繁的发布和改动。
如果把两层东西都混在一起的话，整个系统就会很庞大，界限不清晰。后端的人会干预前端的东西，前端有需求的时候可能后端的同学也不能理解。在这 过程中我觉得可以把应用层独立出来，让前端的同学能够在中间有一个缓冲地带，既能适应应用层的频繁发布和需求改动，又能让后端稳定。
问：JavaScript 有很多框架和库，对于初级学习者来说，怎么能在这些资源中选择适合自己的来创建个人技术栈？
我觉得 JavaScript 最核心、最源头的东西就是它的规范。当然，如果你纯粹去读规范的话也没有什么目的性，但那是一个核心。当你遇到困惑的时候就不妨去规范上找一找，通常你都能找到答案。这对于我来说是核武器一样的东西，一般不能用的（笑）。
另外，ECMAScript 不算是纯粹的 API，它定义的实现就不能更改，对于那些没定义的实现，你要去看那些 API 是怎么去做的。我基本上主要靠这两个东西。
他眼中的 Node
“有一个圈子，有一个社区，其实你会收获很多东西。"
问：能不能简要介绍一下 Node 生态环境的发展现状？
这个话题其实我已经很久不再提了，因为现状已经太好了。前几年的时候模块有几个了、有几千个了，然后过了一年这个数字就上万了，再过一年就蹦到十万以上了。
我是蛮喜欢这样一个形态的，在跨过一个相对比较低的起点之后，大家可能都有能力来完成一个模块。但是，每个工程师的能力有强有弱，每个人的意识 都是不同的，所以这个生态环境又是特别真实的。这里面的东西多，水平参差不齐，但你会发现在很多情况下，如果一个模块是活跃的，它就一直是活跃的；如果它 的质量不好，它就永远都是质量不好的。说不定几年以后，你会发现越来越多的模块都是以不断迭代更新的状态生存的，总是有最好的模块来适应当下最需要的事 情。
问：我之前听你在采访里说，你当时推广 Node 的初衷是因为你看到国内外对 Node 的理解存在很大差距，现在还有没有这种差距？
现在还是有。我觉得最大的差距就是在国内推一个技术的时候，总会有很多人来黑。这些人可能也没有什么前提，不管怎么样，就是嘴巴爽了再说。另 外，国内外环境还有一个差距，就是在国内大家主动刷新自己知识的能力还不是太强。你会发现有一些工程师可能已经能完成当前的工作了，但是他在持续学习上可 能不会投入太多。
问：你认为前端工程师和后端工程师谁更应该学习 Node.js？谁学习 Node 获益会更多？
其实无论什么工程师学习 Node 都可以有收获，但是我觉得前端工程师的收获会更大。
为什么要有前端这个工种？我不知道国外是不是这样，但是国内很多人会说前端工程师就是写 HTML 和 CSS 的，这种工作就像流水线一样，已经被限定在一个划定的圈里面去发展。当前端工程师发展到某一个阶段的时候，他会发现这个圈子对他是一个限制。我觉得前端工 程师需要打破这个圈子，打破之后就会发现更开阔的视野。当我们想要解决一个问题的时候，就不只是再用已有的熟悉的办法来解决，而是发现视野以外的、能够更 好地解决问题的方法。反过来说，如果你总是不想去了解服务器端的一些技术，总是用前端的方法来解决问题，那成本可能很高，做出来的方案也可能不理想。
前后端有 Node.js 连接以后，你就会发现自己的工具链已经完成了一次革命。很多工程师可能会用 Java 或 Ruby 来写一些工具，但是前端工程师不熟悉 Java，也不熟悉 Ruby，他要去完成目标的时候就会特别困难。现在 Node.js 出来以后，你就发现很多工具直接用 Node.js 就可以写了，比如说 CoffeScript，还有一些像 LESS，Sass 之类的工具。前端工程师用自己熟悉的东西就能够改良自己的工具，这是第一步。改良工具以后视野就会放开，你会发现还有很多其他东西可以放手去做。
问：你怎么看 LinkedIn 放弃 Node 和 Scala？
做任何一件事情都会有最适合的方法。我觉得像 LinkedIn 这么大的系统，其实是一种很复杂、很复合的模式。我们在淘宝推广 Node.js 的时候，也不可能去用 Node 把那些最底层最核心的东西替换掉，这是不现实的。如果说在某个系统里面，Node.js 不能胜任某些工作，那就不要用它好了。
据说 LinkedIn 也并没有完全放弃 Node，只是某一部分弃用。我觉得 Node.js 是有它擅长的地方的，只要能够在适合的地方去用好就行了。
问：Io.js 和 Node.js 分离开来，是因为 Node 更新太慢造成的吗？
大部分原因可能在于，虽然 Joyent 公司高管对这个项目还算重视，但是他们对开发进度没有实质的帮助。
从 2014 年 7 月份开始转岗以后，我的工作重点就是 Node.js 的内核，所以我对 Node.js 和 Io.js 的提交列表和 PR 都是比较熟悉的。我发现当我提交一个补丁上去的时候，在 Node.js 下面的处理速度特别慢。我刚进去的时候看到的 PR 列表大概只有两百多个，现在 Io.js 分出去以后 PR 列表更长了。那些在这个项目上做贡献的人，基本上 80% 已经不在这家公司了。所以现在出力的人并不是来自这家公司，而是社区的一些开发者。如果这家公司只想享受商标带来的好处，贡献者们就不会同意，所以他们就 独立出来了。
目前来说我自己是比较喜欢 Io.js 这个项目的。我跟他们提一个问题上去，很快就会有反应。他们的态度也更开放，就是说不管你的贡献是大是小，只要对这个项目有好处的，他们都会接受。并且他 们对新事物的接受速度也更快，比如现在 Node.js 的 V8 版本处于 3.2，而 Io.js 里面的 V8 已经是 4.2 了。如果更新慢的话，ES6 的一些特性就没办法引进来。因为 Io.js 中有这些新的特性，所以开发者就更愿意进入这个项目。
但是 Io.js 也给我造成了一些困扰。以前一个版本发布至少也要一两个月，但是现在的版本发布速度已经是以周为单位的了，几乎每周都能出一版。他们更新速度太快逼着我要 去做很多工作，需要不停地打版本。话说回来，实际上企业内部升级版本的速度要求不是太快，升级一个大版本以后，如果不需要接下来小版本的功能，就可以先忍 忍。
问：你觉得 Node 阵营的分裂是一件好事吗？
我觉得是好事。我记得很久以前就有人特别想给 Node.js 的异步 IO 全部加上 Promise，如果不分裂，这件事情永远不可能。虽然现在的 Io.js 也不能完成这件事，但是只有分裂才有更多的可能性，才能产生更好的东西。
问：很多大公司比如 Paypal，从 Java 转换到 Node.js 非常成功，在后端 Node.js 会取代 Java 吗？
不太可能，Node.js 还是在应用层上更有优势。无论是我们在系统层所做的尝试，还是现在已有的案例，都没有能够证明 Node.js 能够取代 Java。我举个简单的例子，现在没有人能拿 Node.js 来完成缓存或者涉及到集群的大计算，但是 Java 已经能够做到了。
但是 Node.js 在应用层上是有优势的，它的最初设计目的就是要优化 IO 和 CPU 的关系。以前的 IO 都是要阻塞 CPU 计算的，Node 把所有 IO 相关的东西全部从主线程上剥离以后，主线程就变得比较高效。而我们在 Java 里面去实现异步是比较麻烦的，可能需要启用多线程。虽然 Java 也有框架去做这件事，但是对已有的开发者来说，由于他们对原有的模式已经很熟悉，所以不会愿意去做改变。应用层就应该能够快速运行并且面向很多系统。我可 以用 Node.js 快速地开发，调用各个系统。
问：刚才你也提到，有些人认为 Node.js 在设计上最大的失败就是它的 API 是基于 Callback，而不是基于 Promise 的，你同意吗？
当时的情况就是那样，ES6 没有出来，Generator 也没有出来，如果让 Node.js 创始人 Ryan Dahl 去做这件事，他不仅要去改上层的东西，还要去改 JavaScript。但是现在的情况已经有变化了， ES6 已经出来了，它里面有一个东西叫 Generator，运行过程中我们让程序调用栈停下来，然后在某个时间再重新把它唤起来。新的框架 Koa 就能够利用好这个特性，写程序的时候你会发现程序已经顺序执行了，但是背后的实质还是异步。我觉得这些变化将来可能会慢慢影响 Node.js 本身的设计，甚至将来 Io.js 的 API 可能也会慢慢去改。
另外，之所以当时会有 Callback 这样的设计，就是因为当时的 Callback 特别适合异步调用。这样做的原因也跟当时选 JavaScript 有很大的关系。Ryan Dahl 去调研过 Java、Ruby 之类的语言，他发现这些语言提供的 API 有很重的历史负担。这时候如果给开发者提供新的 API，大家也不会去用，因为这会改变他们的思维模式。他在设计这个模型的过程中，发现事件循环里面有阻塞 IO 的话就会导致效率急剧下降。而 JavaScript 特别适合完成这项工作，它不主动提供同步的 API 给你，所以阻塞的方式就不存在。
问：今年你还会不会举办京 JS 或者杭 JS？
今年举办的会叫深 JS。我们今年没有主动去办会，而是由之前我们的一个合作方去承接了这件事。他们是上海的一家外企，对 JS 社区有比较高的热情，过去三年举办的会他们都帮助我们做了很多事情，这次交给他们办也是顺理成章的。
问：以后你还会再举办这样的活动吗？你在这几次办会的过程中遇到过什么困难？
我们以后不排除仍然会举办这样的活动。有一次在北京办会，我们三个人都身在外地，所有的事情都是通过远程操作，在外地办会感到资源上的限制。另外的一个困难在于沟通，比如怎么去邀请国外的讲师或者跟我们国外的主办方沟通，中西方的文化差异会造成一些困扰。
我觉得办会最重要的还是内容，对内容的挑选和审核，讲师怎么邀请，主题要怎么规划。不能某个主题今年讲，明年讲，后年讲，有的公司可能出于商业目的有这样的需求，但有些东西是不能去妥协的。
问：纵然有这么多困难，但是你还是一直在坚持做这件事，举办这样的活动对社区来说最大的收获是什么？
其实在办活动这件事上，我有一个老师叫周裕波，我在上海工作的时候就遇到过他，他经常会办一些前端的活动。对于个人开发者而言，他们很少愿意主 动出来组织这些活动，但周裕波做到了，我觉得我应该也能为 Node 做一些事情。当时我看到 Node 没有这样的氛围，国内的很多开发者都不愿意出来，当时的社区也关注不到这个东西，所以我就办了很多次 NodeParty。
这个过程其实收益还是很多的。首先我对这个社区更加了解了，跟很多高手都很熟悉。另外，我接触了很多赞助商，各种资源其实都是大家互相需要的。 没做过这件事的人可能会觉得非常难，但做了以后你会发现没有想象中那么难。因为你总是会得到一些帮助，来自各个方面的帮助，你在经济上也没有什么损失，还 会结交一些的朋友。有一个圈子，有一个社区，其实你会收获很多东西。