百度FEX刘平川：做最专业的前端

刘平川，百度前端基础技术团队 FEX 负责人。从“有啊”和“乐活”到如今的 FEX，一种创业的热情一直跟随着他。FEX 的关键词包括开源，前端，全栈，和专业。虽然他们是基础技术团队，但是就像“内部创业一样”，他们也需要时刻面对来自产品线的各种反馈。刘平川希望可以让 FEX 的技术影响扩展到百度，乃至整个行业。但他也坦诚说，“我们需要很强的抗压能力”。

激情和责任

你从什么时候开始编程的？

刘平川：真正开始编程是上大学之后和朋友去做了一个网络监控系统，接触前端是当时工作关系写了几个脚本的 UI 开源组件。后来 2008 年当时百度在做“有啊”的 C2C，我对这个事情挺感兴趣。当时我虽然学了计算机，但实际上并没有真正从事这个行业，有些遗憾，于是我就来到了北京，真正开始了前端工作。

听说在此之后您还有一些创业的经历，能简单介绍一下吗？

刘平川：我在百度两年半后从“有啊”拆分出去创业了，叫“乐活”。当时有很多“有啊”的同事也纷纷出去创业。大家做 C2C 的时候聚到一起是因为有一个理想：把“有啊”这件事做成。虽然“有啊”最后没有做成，但是大家心里面都萌生了一个想法：下次一定要做出点事来，这也是我愿意拆分出去创业的原因之一。

我在乐活创业一年多遇到很多问题，最后创业算是失败了，但是学了很多东西。最大的感触是创业不是有想法就能做得成，大多数的创业其实是水到渠成的事，因为需要天时地利人和。

后来我回到百度，加入了 FEX 团队。回去之前我就想，这个机会如果再晚一年可能我就不会考虑了，如果过了当时的年纪要真正再去花所有的时间和精力去做好技术是很难的。所以既然来了，我就希望能在 FEX 团队安静地把技术做好。

刚来到百度 FEX 时情况是什么样的？

刘平川：原来这个部门人还挺多的，整个百度所有的前端都在这个部门。在我回百度之前，前端已经拆分到每个垂直部门了，还剩下大约一个 60 人左右的团队，支持公司很多产品线上前端基础技术上的业务。之前对这个部门了解程度有限，只知道这个部门有些不一样，也有很多技术牛人。但是怎么样去做好，其实说老实话我不知道。我当时的想法就是希望能让这个团队在这个行业里面留下一些痕迹而已。

60 个人已经是 3 个贴吧的规模了，如果有 60 个人，就不得不干 60 个人的活。这个规模至少得把好几个大产品线给接下来，我们暂时搞不来。人宁可少也不要多，人一多很多事情没法做。我之后做了很大的调整，把一些方向，比如 Flash 拆分到垂直产品线去了，现在只有 30 人。这么做的目的只有一个，就是为了个人和部门的长期利益。

我自己是很有激情去做好这个团队的，但很多人可能觉得我是一时兴起，也就干 3 个月热度吧。我希望给每个人一个舞台，团队平台做到足够大的影响力。一年过后，我可以告诉大家，今年团队的状态很好，已经不需要太多管理了。

你在这里面的角色是什么？

刘平川：我其实现在走的是M（管理），不是T（技术）。我的角色就是在各个负责人之间找我应该做的事情，为我们中长期的目标打算。比如我们团队的技术影响力，部门技术更长远的规划，我们明年做什么，怎么把部门做得更好。

去年底我们规范了运行机制，整体所有方向上包括技术规划和 Review 机制，还有各方向目标都公布出来。周报上面会写负责人是谁，衡量标准是什么，需要多少人力，什么 Level，在什么阶段交付，这个事情对产品线的价值是什么，都会写在上面。今年很多事情都比较上正轨，后面才考虑做技术品牌和技术规划。这件事情团队其他同学，比如多益和牛尧付出很多，我只是做一些顺水推舟的事。

今年我们的重点是在线化，包括很多内容：资源打包优化、全流程优化、数据监控，等等。也包括我们把 PC 端的一些复杂应用 Web 化，这也是今年的一个目标。在技术影响力上面，从我们的一些开源项目也好，跟业界的接触也好，我希望通过外部的资源和信息引入，推动内部更快地发展。

你们和产品线的关系如此紧密，你的压力是不是很大？

刘平川：我们各技术方向负责人压力确实会比较大，我们有机会可以接触到产品线里所有的人，产品线自然可以看到我们的每一个阶段。每季度或每半年，他们要看到我们的产出是什么，如果没有很合适的交代的话，会受到产品线的质疑。我们也曾经遭遇过做了几个技术项目都没有得到认可的情况。可以想象这就像内部创业一样，创业需要很多的尝试。我们做得好了，每个产品线都会多给点资源。但如果我们做不好，就什么都没有。

无论是否做成我一直坚信的是，只有没做好的事，没有做不好的人，态度是首要的。一个团队可以做很多事，一个人可能这个事情做不好，做另外一个事情就好了。一个人发光发热需要时间，也需要一个巧合。

技术能解决什么问题

你认为技术/工程师和产品的关系是什么样的？

刘平川：我曾和一个朋友讨论技术，他的一套理论让我哑口无言。他说，设计模式就是人想出来的，也是一种想法的抽象，你觉得设计模式做的就对了吗，我的代码乱是错的吗，如果我把技术问题解决了，你为什么要管我是怎么解决的呢，是否是你们对技术的评判标准有问题呢？后来我想，是不是我们对代码优雅这个问题已经形成了一些思维定式，对于代码杂乱和提供问题快速解决方法的人有种不屑一顾呢？

我的一个朋友创业，他团队中的某个工程师，一个人仅用了一个月的时间搭完产品上线了。虽然技术的可维护性几乎没有，那你说这个人的技术是好还是不好？这件事情没有办法用传统的思维来评判。原来的标准其实都是一种大公司式的评判标准。虽然他的代码别人无法维护，但是他做的事是有价值的，创造的经济价值比传统科班出身的人多得多。后来其他工程师维护起来说代码太乱，用了3、4 个月把代码改好。而这种能闯的人对创业公司其实更具有吸引力。

设计哲学这件事恐怕没有人能讲清楚。所以有些事不要太较真，要看这件事是为了什么。如果过两年这件事仍然对我们很重要，那就有价值，但是从大多数情况来看，一般过半年就不再重要了。

技术永远是一种手段，而不是目的。产品最终结果不在乎你技术有多牛，只在乎你能把产品带到什么高度，在这过程当中能解决多少技术问题。

为什么要工程师自己担任产品经理？

刘平川：我们没有产品经理，技术需求来源最主要从产品线来，我们需要了解工程师开发中的痛点，产品中的体验问题，找到合适的切入点开发出靠谱的技术方案。

现在每个技术方案负责人都是方案的产品经理。我要求团队的同学需要用这些做产品的思路来做技术，这样思考才会技术项目做得全面，系统，也更具有说服力。

一些比较具有前瞻性的项目我们可以先做原型，原型做完后再给到产品线中去，如果不回到产品线里去，我们肯定会做偏，技术会没有宿主。每个人都会有很多技术想法，如果你最后没有落实到产品线的话，就没有意义，所以我们做技术需要用产品的视角来做。

技术方案的推广上原来我们大多是强推着产品线工程师在用，甚至变成他们的 KPI，这是有问题的。强推还不成熟的技术反而会引起负面效果。后来我们分阶段对待，不用行政手段。把技术方案的使用广度作为一个阶段性的衡量标准，比如当某项技术方案质量做得足够好的时候，再去看一个周期内落地了多少产品线，这样的评价才更会有意义。负责人需要每个阶段都有相对明确的定义，让每个工程师都能理解这个目标。

技术人员身兼经理的必要性在哪？

刘平川：基础技术的团队与产品业务团队有很大的不同。以前我带过几个业务团队，我个人的感觉是产品业务团队的运行是由产品业务来驱动的，经理协调“人”的时间比较多。

而在基础技术团队，是技术驱动项目，用产品思路做事，没有职能体系之间的协调会影响效率的问题。我们很少开会，每周固定的会议只有部门例会。团队之间技术讨论是最多的，所以我们会议基本都是在技术讨论与评审，我也需要参加，还要拍板决策。

如果基础技术团队的经理只负责协调人而不管技术还会有一个问题。由于经理没有办法判断技术的趋势，缺乏技术创新，团队的技术视野会逐渐受限。这样的经理思维方式也不会跟一线工程师在一个频率上面，沟通不了。所以我认为基础技术团队的经理应该和高工有同样的职能，经理就是拥有行政权利的工程师。

您曾经提过技术的止盈止损这个概念，是指什么？

刘平川：技术既需要止损也需要止盈。很多技术项目可能当你做到一定程度之后，会发现它的意义已经不是那么大了，这个时候就应该果断地止盈或止损。

比如说编辑器，我们的 UEditor 编辑器在行业里面，至少在国内还算可以了，现在很多外部公司也都在用，我们每天都会收到问题反馈邮件。但我从去年就在考虑，我们这个组的方向不能只限于做编辑器，应该把这个组的视野拓宽一点。是不是可以将现有 PC 本地端有的东西，放在 Web 上面去试试，我们认为 Web 有这种能力，可以解决很多现有阶段 Web 的复杂功能。在今年，原来的富文本方向也转变成富应用方向，目前百度脑图、矢量可视化公式编辑也都是这个方向的产出。

止盈止损是经济学里的一个概念，即是适可而止。放在技术上大概的意思就是像编辑器那样的成熟项目，可以暂时减少人力放缓发展。把人力资源抽调配到目前更具有创新性的其他技术或虽不成熟但需要快速突破的方向上。我们可以一直抱着旧的东西不放，这块技术可以让我们活下去，但我一直认为，如果只做那一块技术而不愿意去扩展，其实就太小看我们自己了。

今年您参加了韩国举办的 WWW 年会，有什么见闻？

刘平川：今年 WWW 大会在韩国首尔，主要的赞助公司是 Naver，他们不仅有搜索引擎，还有一个叫 Line 的 App，就是微信的韩国版。在韩国 Naver 就是百度+腾迅的产品架构，国内很多大互联网公司都“抄”过这个公司的产品。

我们国家的互联网公司在国外的知名度还是不高，更谈不到影响。与会场的一些参会人聊天时发现，他们不太清楚中国的互联网情况，也不知道百度、淘宝。后来我们提到百度是本次赞助商之一，他们才知道百度。

在韩国找路线的时候没法用百度地图，只能用 Google。用它可以通过中文搜索酒店景点名字，包括公交路线也都能找到。如果没有 Google 地图的话，我们几个没有一个人能在首尔出行，这给我触动很大。真正做得好的技术可以利用到很多行业，影响到很多人。

FEX

您能简要介绍一下 FEX 正在从事的开源项目吗？

刘平川：开源在 FEX 是一种心态，接受 review 与 check，接受反馈，希望用 UGC 思路把技术项目做得更好。目前我们也是这么践行的，从项目代码到面试题，以及博客和 style
guide，都接受 Pull Request 和 Issue。

现在我们的开源技术项目大家熟知的有七八个，FIS、编辑器、脑图、公式、HTML5 上传组件、移动组件。暂时都是工具和组件类偏多，目前 star 总量有近 2000，fork 也有大几百。

KityMinder 是我们最新推出的项目，它是一个在线脑图编辑器，已经和百度云盘打通了。从技术角度来看，是因为之前我们有一定的矢量技术基础，所以初期脑图原型我们开发时间并不多，1 个人不到 1 个月的时间开发完成上线，现在也在接受反馈，不断迭代。

上线以后，从 Web 内容消费与创作的产品思路来看，云盘解决了文件存储的问题。而文件内容，例如办公系列，教育图形公式的一些内容创作，还有很大的可在线化空间。我们做的话，既能沉淀技术，还可以帮百度做很好的内容创作工具，落地到阅读、贴吧、知道、百科或云，甚至可以诞生出一个完整的创作平台。从对脑图的反馈来看，大家非常希望出现更多 Web 形式的全端在线查看、编辑与分享的工具。

FEX 上最受欢迎的项目 FIS，现在的发展状况怎么样？都有哪些公司在用？都有什么人在贡献代码？

刘平川： FIS 的使用人群可大致分成三类。

第一类是 百度内的工程师，随着产品线使用广度的不断扩宽，FIS 已成为公司大多产品线前端开发的标准。我们把技术服务做好，有问题第一时间解决；一旦有新产品线使用，我们会有同学跟进到产品线里进行培训。公司内反馈最多，我们也最为关注，我们会将他们的反馈抽象放到 FIS 上，慢慢积累，使得 FIS 从量变到质变。公司内其他团队为 FIS 贡献不少，比如即将上线的 NodeJS 框架，是与文库同学一同合作开发的，可以说 FIS 是在所有产品线的工程师帮助下才能走到今天。

第二类是 从百度离开后将 FIS 转而带到其他公司的工程师，这是对 FIS 的认可。他们认为它可以为新的环境创造价值，解决新环境的问题。现在至少 6 家公司都是这样，同时他们也会对 FIS 贡献部分代码。

最后是通过国内外的技术杂志、讲座上看到对 FIS 技术的介绍， 感兴趣并使用的工程师。这些工程师从了解到使用的周期相对会比较长，目前贡献的代码不多。但我们现在也很重视这样的人群，所以对文档不断维护，并持续更新，而官网最近也把 FIS 重新定位成前端工具和用工具及框架生成的解决方案，同时增加了使用解说视频，帮助大家更快地了解和使用 FIS。

FEX 名字的由来？

刘平川： FE 代表前端（front-end），X代表了每个人都能独当一面，不仅所有事都了解一些，而且还有一个专长。就像X战警一样，每个人都有自己独特的能力，但是作为团队可以一起把事情做得更好。

在网站上可以看到 FEX 的口号是“Best or nothing”，这看起来是一个比较有野心，也比较有风险的情况。你们怎么平衡跟现实之间的关系？

刘平川：最早我们自己也没想清楚怎么样定位自己。无论是基础技术组还是通用组，感觉都不能很好地体现我们的能力。去年经过半年时间，我们逐步精简后把“专业”作为我们的定位，所有的技术项目、文章与践行都围绕“专业”来做。

与产品线合作，我对团队同学有几个要求：第一，我们一定要在这个方面做得比他们更专业更全面；第二，别人能做到的我们也要能做到；第三，我们也要去做业务，不要说只做基础技术部分，业务基础一样要做专业。

你们团队里面的内部构成是什么样？

刘平川：目前一共是 4 个大的方向：

• 工程架构和流程优化，能力上可以理解为“全栈”。包括百度几乎所有产品线在用的 FIS、静态资源自动优化打包优化、持续集成、全流程优化等，同时也在一定程度上承载我们其他方向组件与工具的输出。

• 监控评估，包括现在几乎所有的前端数据的收集与监控，比如前端性能的监控，浏览器新特性的检测，异常的监控，XSS 检测。这其中还包括评估，也就是针对监控和产品核心指标的关系，以及我们自己的技术项目应用到产品线里的价值评估情况。

• Web 富应用，有编辑器，个性化的可视化展现，百度脑图，可视化的矢量公式编辑等。

• 还有就是 全端技术，比如 WebUploader 的快速上传组件、移动端的组件库 GMU 和之前在做的轻应用中的轻组件。

轻组件是怎么回事？

刘平川：原来的组件要么是原生客户端的一套组件，要么是 Web 的一套组件，我们认为轻组件就是这两套的综合。比如一个滑动的图像展示，如果你要在目前的 Web 上展示的话，它的流畅度不高，用原生的话就会很快。所以如果你用 JS 在我们提供的 API 上写代码，它会在不同的运行情况下用不同的方案。这就像 PC 时代 Flash 插件的思路，没有 Flash 插件就变成最原始的显示，有 Flash 运行时体验会更好。这就是一种轻组件的思维。

为什么你们需要的人是全栈工程师？

刘平川：我们在 FEX 博客上招聘要求全栈/全端工程师，还要求充分的自驱。在公司内部我们团队会维护自己的服务器和知识库的系统与机器。这些搭建都是我们自己完成的。虽然前端数据系统的 Hadoop 不是我们自己搭的，但是 MapReduce 的脚本都要自己写。

因为我们的工作不是狭隘的前端领域，也不局限于语言，需要涉及前后端。Web 服务器以前就叫前端，开发流程优化这些工作我们都做。而流程的优化像持续集成与前端的运维就涉及到传统的前端和后端，这就要求我们在技术上也要掌握这个方向。

基础团队对于整个公司的价值是什么？

刘平川：我们现在想得比较清楚，是因为也经历过迷茫。去年各方向的负责人曾坐在一起讨论过我们应该做什么业务，我们做的业务应该有什么样的特性，我们应该怎么样跟产品线合作，整个前端和后端怎么合作。讨论过后我们发现，基础团队做的事应该是业务团队“重要而不紧急”的事。

我们认为对于业务团队来说，基础技术可要，也可不要。没有我们业务团队也能招人做，但业务团队需要我们，是因为有我们他们能做得更快更好更专业。如果业务团队使用了你的技术，那么基础技术团队的水平就决定了业务团队开发的技术架构的平均水平，这体现在开发效率、开发质量、带宽利用与人力成本上。

带领 FEX 团队的过程中，你有什么感触？

刘平川：很多的触动都是这个团队的同学给我的。我认为他们很多人比我优秀，我在团队中的作用就是让大家同心协力，有一个目标感，一起把一个事情做好。

比如团队的多益，技术非常好，之前我一直觉得应当给他技术上挑战很大的事情去做。后来他主动去搭团队的 blog，把原来分散的代码仓库转移过来。而且他在博客上也发表了很多文章，也主动写了我们的开源面试题。我问他，你会不会期望做更多技术上有挑战的事，他回答说，他很希望能做这些帮团队扩展技术影响力的事情。很多技术能人可能比较喜欢独善其身，不愿意把个人与团队放在一起。我很幸运的是团队里都是既追求技术理想，也愿意配合团队目标的能人。团队有共同的价值观，每位工程师都希望把各自方向的技术做到极致。

百度最佳员工我们部门就有 5 个。我们还拿到公司级别的 2 个平台工具奖，1 个最高创新奖。其实大家心里面都希望未来能拿一个公司的最佳团队奖。我觉得既然大家都能这样想，那我也不怕有什么事情做不成了。

本文链接