朴灵：打破限制，从前端到全栈

非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/article/197773

朴灵，真名田永强，文艺型码农，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。

这个过程其实收益还是很多的。首先我对这个社区更加了解了，跟很多高手都很熟悉。另外，我接触了很多赞助商，各种资源其实都是大家互相需要的。没做过这件事的人可能会觉得非常难，但做了以后你会发现没有想象中那么难。因为你总是会得到一些帮助，来自各个方面的帮助，你在经济上也没有什么损失，还会结交一些的朋友。有一个圈子，有一个社区，其实你会收获很多东西。

---

更多精彩，加入图灵访谈微信！