大众点评资深前端工程师张颖：一站式的前端开发

如果你搜索 Github 的项目排行，JavaScript 一定排在最前面，现在前端工程师的开发工具越来越丰富，开发的流程也越来越规范，传统的持续集成、敏捷开发的理念也渗透其中，作为一个参与过大众点评前期所有前端项目的工程师，张颖总结了平时工作中遇到的问题，在公司所有技术团队 scrum 转型之际尝试对前端的开发流程做一个一致性的规范，把各种工具集合在一起，让后端的工程师也能“无痛”开发。在 11 月份的 QCon 上海上，他将会做“ Cortex: 基于 CommonJS 的 Web 开发环境介绍”的分享。

我们在此采访了大众点评的资深前端工程师张颖（ @kael ），听他谈谈一站式的开发理念。

InfoQ：简单的介绍一下自己目前负责的工作，以及自己在 JavaScript 领域做过哪些方面的工作，关注过什么？

张颖：负责的工作：目前在大众点评网负责前端架构相关的工作，已有的工作包括（这里先不谈架构师的职责和未来要做的事情吧）：各业务线的前端技能培训、关键指标的监控、基础框架的维护和升级（包括前端相关的 jar 包）、静态文件测试环境及上线发布工具（CI）、用户数据收集前端、部分规范的制定、以及部分业务项目。

JavaScript 领域：我是 neuron 的作者，neuron 是大众点评的一个 JavaScript 框架，自 2010 年底在第一个业务中上线以来，渐渐被几乎所有业务线所使用。不过由于没有时间推广，比较低调。之后也没有推广的计划，因为 neuron 新版本不是设计给人类来使用的。 目前我们的发布机，本地电脑，以及部分线上系统中，随处可见 node.js 的身影。平时画画的时候，给自己做过 photoshop 的插件，不过 adobe 的这个东西从设计上，基本上属于上个世纪的遗物，放弃。

关注过什么嘛，这个问题不好回答，各种乱七八糟的东西都有在关注吧…… 诚实的说，没有刻意关注某一个东西。

InfoQ： 你目前关注的重点是什么？

张颖：目前工作上关注的重点是

• 前端本地开发环境（以及测试环境的一键化）的搭建
• 通过培训，以及更好的系统，提升非前端工程师的参与度，并控制代码质量和多人开发的风险。

InfoQ：感觉在过去一年，自己接触到的、关注的领域发生了什么变化？

张颖：高兴地看到 Github 上 JavaScript 相关的项目比例越来越高。几年前刚开始写 node.js 项目的时候，基本上从头到尾都得自己来写，现在也渐渐有了不少好用和靠谱的模块。 另外就是标准的自然收束，和一统的趋势。

InfoQ：在 QCon 上海上，你将会分享“Cortex: 基于 CommonJS 的 Web 开发环境介绍”的话题，那么对这个话题你的看法是怎样的？

张颖：这些年来，在 Web 开发的工作占比中，前端有变得越来越重的趋势。有些应用开发的角色分工中，甚至不存在业务后端，业务逻辑及视图的展现全部交给前端来做。而前端工作量的加重，引发了以下的系列问题：

• 模块化在解耦的同时，也造成环境搭建（本地环境、以及自动创建新的测试环境），特别是配置的复杂化；
• 前端就是各种手动的工作；
• 前端工程师招聘难（大学不学啊，前端工程师都是半路出家）；
• 如果非前端工程师尝试写前端代码，上手难，要考虑的因素太多；

这应该是摆在不少公司面前的难题。

InfoQ： Cortex 的目的是在大众点评的 Scrum 转型中降低后端工程师的前端开发难度，对于它的具体定位和使用场景能否详细说明下？

张颖：我们主要的思路是，减少让工程师分心的点。相当多的情况下，做业务开发的后端工程师（即并不用太关心服务器部署和负载、分布式问题、底层、数据层等等问题的工程师，他们主要进行数据的业务逻辑处理）需要考虑的问题比日常前端开发要少得多。这也是由于 Java 生态圈发展比较成熟，框架类库以及周边的工具体系比较完善。

而前端开发从某种程度上说还是相当原始的，工程师需要从进行开发之始，直到上线的各个环节中考虑许多问题，比如需要非常了解 HTTP 协议，从而知道怎样更好的进行静态文件的版本控制；需要去纠结多个文件物理上如何组织；发布路径是如何的（更多的时候是在想怎么样更好）；如何搭建本地环境；

Cortex 的定位，是作为前端的本地开发环境，其中会包含包管理。由于本地开发环境从本质上，和测试环境无异，因此测试环境的机器上我们也是用的 cortex。

从设计上，我们希望在大多数的情况下，能够用最少的设置，和一两个命令，就可以满足日常的需要。

一旦 cortex 安装和简单的配置好，并且启动了，我们大部分时候只有在初始化新的项目，和安装依赖项的时候需要用到它。cortex 会自动创建服务，监听使用 cortex 创建的项目，完成必要的 build 工作，这些默认地大都是静默完成的。而上面提到的其他问题，会借助持续集成来完成。

一句话来说，只有两件事情是需要人来做的，写模块 和 源代码管理。

InfoQ：你还提到这次分享的目的之一是唤起大家对前端开发本身的思考，能先谈谈你的思考吗？

张颖：关于这个问题，可能我之前有些没有很准确的描述。

这些年我最主要的一个想法是：我们每做完一件事情，是为了之后可以不用再做，甚至可以完全不用去想。

在每次设计一个工具的、定立一个规范或者约定的时候，要想清楚哪些是需要我们在日常中需要每天都做，哪些内容可以完全集成到系统中而不需要普通开发者关心，同时，我们希望前者会尽量的少。 我们做工具，或者定立规范，都是为了解决某个问题，我们不希望为了解决某个问题，让我们人艰不拆的日常更加的繁忙。

举例来说，我认为 commonjs standards 之外的 proposals，都应当是系统和工具帮我们做的（这是 cortex 的存在原因之一），而不用人每天来做。

再者，我们对待 grunt 的策略，是将最主要的 tasks 仅在 CI 上来运行，而不会在每个项目中来定义（特别是对于多人开发的企业级项目）。 这个也会包含在话题里面。

InfoQ：目前 Cortex 已经在 github 上可以看到了，那么整个项目的运转情况是怎样的？对于开源项目的维护，你有怎样的看法？

张颖：目前在开发 cortex 这个 repo 本身的同学其实只有 2 个，github 上面的 master 是我们作为日常提交的分支（这只是个源代码管理策略的问题），而发布到 npm 上面的才是稳定的 release。 其实不止 cortex 这一个项目，而是多个项目配合起来形成了一个完整的系统。其中一些部分已经在公司内部运行了至少一年的时间，其他的部分，我们也正在或者有计划将其他业务一步步迁移过去，我们需要确保升级的平滑。

对于开源项目的维护是一个很有意思的问题，由于目前我的私人时间并不多，对于开源项目，基本上最初都是从公司的需求出发的。但是这种开源项目，经常容易遇到两个问题，一是项目在设计上带有过多的公司的影子；二是不愿意放手，其他开发者不容易参与进来。

第一个问题，是一个设计上的问题。个人觉得是由于在信息架构设计上没有站在更高或者更抽象的角度来思考，过快的跳入了业务的思维之中，没有想清楚什么该做、什么不该做、什么应当交给其他项目来做而产生的。另外，公司内部的项目在起初尝尝就没有考虑到今后会开源，然后突然有了开源的计划，结果生出一颗强扭的瓜。个人很崇尚抱着开源的心态来设计公司的项目，即便这个项目一开始不会开源。

第二个问题，公司总会有自己的目标，重点项目的评定，资源和人力的分配受到许多因素的影响；个人精力有限，兴趣点也会发生变化，从而使开源项目经常受到影响。社区因而变得越来越重要，这是我们目前非常不足的，之后相当长一段时间的重点会放在这个上面。

而过度的放手，可能会造成社区品质的参差不齐。仔细看过曾经 jQuery 插件（甚至 jQuery 本身）和 jQueryUI 的代码，就知道里面有多么糟糕，这也是不少大牛对其抱有一些鄙夷的态度的原因。先不评价集中之于自由的优劣，在起初，个人认为灵魂人物是很重要的，至少他可以把控整体的方向和思路，这是为用户负责。

这个世界，决定一个东西是否被大众接受的原因之中，它的品质仅仅只占据了很小的一个部分，人们是一种太容易被偶然的意外的东西影响的集合。然而社区和生态环境会大大提升布道者的基数。

InfoQ：介绍下这次大众点评的 Scrum 转型吧？

张颖： 可以说，大众点评所有的团队都转型为 scrum 团队了。转型的过程，简单来说，就是先外部 coach 重点带几个试点团队，其他团队自我学习同时培养内部 coach。 值得注意的是，scrum 本身的组织形式要求团队都是由一专多能的个体组成的，否则最容易发生的事情就是 前端 或者 QA 成为团队的瓶颈。这也是我们在向后端工程师做前端培训，以及让他们也写一部分前端代码的原因。

滕振宇（我们的 coach 之一）和唐灏（研发高级经理）也在 QCon 上海 的讲师和出品人名单里面，这个问题他们应该会详细地给大家分享。