美团旅行前端技术体系的思考与实践

作者：叶俊星，美团前端工程师 原文：https://zhuanlan.zhihu.com/p/29373613

为什么要讲这个题目

前端圈是一个被技术圈的人称为娱乐圈的领域，很多做后端的、算法什么的，会经常来调侃前端圈，知乎上甚至有个问题问「前端架构是什么，前端有架构可谈吗？」，甚至前端圈自己也有很多人在自嘲。但实际上，这些年来，随着互联网的发展，前端也在迅猛地发展，前端的需求变得越来越复杂，前端团队也不断地变得庞大。在一个复杂的产品和规模比较大的团队当中，如果说没有架构，只能说是手工作坊式地生产，效率太低。所以说，我特意选了这么一个话题，来悍卫一下咱们前端的尊严：）

什么是技术架构？

技术架构是指社会中各种技术之间相互作用、相互联系、按一定目的、一定结构方式组成的技术整体。技术架构——或者说技术体系——归根结底是围绕业务发展、团队规模和团队特点量身打造的，它的最终目的是在确保线上的质量和稳定性的前提下，提升团队整体的研发效率。

既然说，技术架构是围绕业务发展、团队规模和团队特点来设计的，那我们就要先梳理一下我们的项目和团队背景是怎样的。我们美团点评酒旅的项目和团队背景分别有这些特点：

• 项目的特点：项目之间差异中有相同。比如说 B 端和 C 端项目虽然面向的对象不一样，但是同样是要做用构建、要做测试的；又比如 B 端页面虽然业务之间各不相同，但基本上都是查询、表单和图表这么三种页面。如果说每个项目我们都重新地去做这些东西，效率就很低。所以，我们需要提高项目之间的复用率。
• 团队的特点：规模大。光我们酒旅事业群前端就有一百多个人，并且还在不断规模化，也就是说人在变得越来越多。那么大家都知道，规模化就会导致沟通成本的提高，我们希望能尽可能地降低规模化带来的成本上升，尽可能地固定规模化的成本，从而实现规模效应。

标准化

那么基于这样的项目和团队的特点，我们可以很清晰的看到，我们最先需要做的，就是——标准化。标准化对团队的本质是，我们要把整个团队使用的各种技术进行约束，对选型进行划分和收窄。

这样的约束能够给我们带来很多好处。

对于项目来说，我们可以把各个项目可复用的部分抽离出来，通过标准化来提高它的复用率。

比如很常见的一点，就是把组件库抽离出来，使得这些组件可以在各个业务项目中复用；再比如说，我们把部署、监控等这些服务抽离出来，做成独立的服务，提供给各个业务线来使用。

所以说，标准化后的项目，我们不再需要做重复的技术选型工作，并且可以很方便地寻找各种公共服务来复用，最终实现最终提高效率的目的。

对于团队成员来说，在标准化之后，项目无论是从选型还是所使用的公共服务来说，都几乎是一样的，所以不同项目之间人员的流动在技术上几乎没有成本，仅需要熟悉业务。

还有，对于初、中级的同学来说，他们可以清楚地看到我们技术架构的全景图，有明确的、清晰的需要掌握的技术栈可以去学习，从公司的角度来说，团队在培训和招聘时能够也更能有针对性；对于高级人才来说，我们可以使得愿意思考、有能力的同学，有更多的空间加入到技术架构的思考和优化当中，把成果贡献到大团队里来，去影响更多的工程师和项目，从而获得更大的收益，最终结果可以用乘法来计算。

那么要实现标准化这个目标，我们就需要围绕着这个目标去做设计。

这个就是我们美团点评酒旅团队，在经过标准化之后，做出来的技术架构。我们可以看到，我们标准化的流程规范，会覆盖到整个从开发到构建、再到部署、最终运行的工作流程里面去。

自动化

那么有了标准化之后，我们就会发现到，有些环节它是机械重复的，我们是可以用工具、用机器去代替的。

比如，我们有代码规范，以及提交代码时要进行代码检查的流程，那么我们可以发现，进行代码检查这件事情，实际上是可以自动化的。我们用了 lint 工具，去做这种自动化的检查。

自动化往往能成倍地甚至无限地提升我们在某个环节上的效率。

在我们团队的技术架构图中可以发现有基础工具、自动化测试工具、部署平台、监控体系，这些工具和平台，这些都是我们在标准化之后发现可以用机器去取代人工而做出来的。

我们举两个更具体一点的项目，来让大家感受一下。

第一个例子的背景是，小程序慢慢开始普及，我们有非常多的小程序需求，而这些小程序的需求往往也有一套几乎一样的移动端页面，所以我们会发现我们在不同的平台做着同样的业务，这是我们出现的机械重复的工作。

于是我们投入了一些人力资源，去研究如何实现一套代码同时在移动端页面和小程序页面，甚至 Native 中运行。

那么考虑了我们团队整体是以 Vue.js 为主的，于是我们做了一个叫 mpVue 的工具，它做的事情就是，把 Vue 的语法转换成小程序的语法，实现移动端页面可以完美地转换到小程序的语法，实现了小程序的快速开发和多端复用，相比起之前我们需要工程师去学习小程序开发而言，有了这个工具之后，我们的工程师几乎不再需要学习小程序的开发，从而接近无限地降低了小程序的学习和开发成本。

在未来理想的状态，我们可以实现一套代码，直接在 Web 端、小程序端（包括微信和支付宝）以及 Native 端（借助 Weex）这样多端上运行，write once, run everywhere。

第二个例子的背景是，我们的 B 端需求对界面的要求并不高，仅仅需要满足的是核心功能，而这些页面的相似性非常高，通常就是三类：查询页、表单页或详情页，以及图表页。

这些需求虽然说每个业务都不同，但是实际上我们几乎都是在做同样的事情，我们在开发这些页面的时候，实际上都是直接在堆标签堆组件，无脑地去绑定数据，写 HTTP 请求。

那么我们就在想，对于这些简单机械的事情，我们是否能做得更快，甚至自动化？于是我们做了一个 IDE，这个 IDE 是基于 Vue 之上封装的一个图形化页面搭建工具，可以让工程师通过拖拽的方式，迅速地搭建前端页面，并且支持数据绑定。

使用这个 IDE 搭建页面是非常迅速的，我们这里收集到的数据是，一些原本需要 1-2pd 去写的页面，通过我们这个工具，只需要 1-2 个小时，提升了 30%~80% 的开发效率。

目前来说，我们已经能够使用这个 IDE 搭建一些对页面要求不是非常特别的页面了，拥有了一个基础的页面搭建能力。在这之后，我们会继续迭代我们的 IDE，提供那三类页面的模板，甚至根据 API 文档，自动地生成页面，使得工程师只需要做一些很小的改动，就能完成页面的开发，进一步提升我们的开发效率。

除了从标准化实现自动化的这些好处之外，我们还会发现，当我们实现了自动化之后，自动化又会反向地去促进标准化。

因为人的惰性或者能力的不足，有些同学可能会不愿意去按照或者偷偷地不按照标准化来做，比如说很多人就是不愿意按照代码规范，在等号左右加空格之类的。

那么我们有了自动化检查工具之后，如果说这些同学还这样做，就会通不过自动化工具的检查，通不过就无法提交代码，所以他必须得按照我们的标准化的代码规范去写代码，这样他才能成功提交代码。

所以我们说，自动化虽然说是来自于标准化，但是他又会反向地去促进标准化的执行，是一个良性的循环。

前端工程师如何成长？如何进阶成为美团点评中/高级工程师、技术专家？

那么关于架构的方法论咱们就聊到这里，接下来咱们来聊一下关于前端工程师成长的方法论。

我们说，其实我们做所有的事情，最后都会落到对人的影响上。打个比方，有一天我们做的项目的代码全部都丢了，包括服务器所有人电脑和 git 仓库都没了，但我们的人还在，我们其实是可以很快地把这个项目重新写出来的，而且会写得更好。

因为我们在做项目的过程中，所经历的思考、所做的设计，最终都会成为人的经验，这个才是最宝贵的东西。所以说，作为公司，最看重的是对人的培养。

反过来说，作为工程师自己，其实最看重的，也是自身的成长。有很多工程师——包括以前的我——也会遇到这么一个阶段，对自我的认识是这样的：我能 hold 住所有的需求，我能够灵活地运用很多的 UI 框架、构建工具、测试工具等等，我会函数式编程，我会响应式编程；还有些工程师会说，我的经验比较多，业务比较熟练，我还带着几个人一起去做业务。

但是大家心里就还是有个问题，大家都意识到，在这个时候再深入挖掘技术，投入产出比并不高，比如我们可能可以花了很大的力气去把 V8 的工作原理完全搞懂，把源码全看过一遍，这样做对我们来说，可能根本不会对公司有什么帮助。但问题是，我们很迷茫，我们清晰地感觉到自己到达了一个瓶颈期，但是却不知道怎么突破这个瓶颈。

我自己当时在遇到这个问题的时候，我其实问了很多很多人，包括业界比较有名气的 @贺师俊、@顾轶灵 、@小爝、@小芋头君 等等，以及我的老大和我老大的老大等等，他们有的是走管理路线的，有的是走技术路线的，他们都从不同的角度给了我很多的经验和指导。那么接下来，我就分享一下，经过我思考和消化，结合我们美团的人才培养理念，关于工程师进阶到技术专家的方法论。

对于我们前端工程师，甚至包括客户端在内的终端工程师来说，要进阶到技术专家级别，主要是从这三个方面来入手：规划、复盘和视野。当然除了这三者之外，还有再高层次的一个领域就是商业思维，我这里说的商业思维指的是，我们对业务非常熟练，从最初的用技术支撑业务，到通过研究出一些更好的技术，来反向驱动业务的发展的能力。大家都很熟悉的一个例子就是人工智能。但这个能力在终端上并不是很容易做，所以我们主要关注的还是规划、复盘和视野这三个方面，它们是三个不同的方向。

做规划

规划是向前看，它是对未来整体性、长期性、基本性问题的思考和考量，设计未来整套行动的方案；用通俗的话说，就是实施总体目标的行动计划。

很多人并不注重规划，无论是对个人、团队，还是对项目。但是，没有规划实际上我们是没有办法结果导向地去工作的，也没有办法去衡量我们做的东西是否符合我们的预期，因为根本就没有预期。

很常见的情况就是，一些有想法的同学，可能会有时能想到一些不错的 idea，然后想让公司给予他机会去做，但大部分同学会出现这么一个问题就是：只把焦点关注在技术上怎么去实现它，没有一个清晰的规划，目标可能也只是最多说解决了一个什么样的问题。这样很多时候会做不出好的成绩，因为没有做规划。

那怎么做规划呢？

首先，我们在做规划的时候，要明确一个前提，就是我们是要围绕着业务去做的，要带着对业务的理解去做，我们不能脱离了业务。比如说你们公司的业务只有客户端，结果你提出了一个解决 PC 端性能问题的方案，那肯定是不能争取到资源去做的。

那么在结合业务的前提下，我们第一步首先是确定我们的目标收益，比如说我们解决了一个什么问题，它能给我们在哪个环节提高百分之多少的效率。

然后第二步，才是我们最容易关注到的具体的实现这个目标的设计方案，这个设计方案其实简单来说就是技术怎么去实现。

那么第三步就是落地路径，落地路径就是我们如何去实施这个设计方案的一个计划，比如说我们这个目标要花 3 个月去达成，那么我们每个月要或者每个星期，要交付什么样的东西。

这个有些人会把它称为里程碑。在设定里程碑时，有一个比较重要的一点，就是优先级的决定。优先级要思考和论证，明确了优先级，然后去设定里程碑。另外还有一点，就是我们要设定在什么情况下出现什么程度问题了，咱们要止损。

第四步就是衡量的标准，我们要制定一些可量化的客观的标准，使得我们要吧在交付的时候，有一个标准可以去衡量我们的收益，看是否符合我们最初设定的目标。

要注意的是，衡量标准是在做规划时就要做好的，很多人往往是在结束时才去衡量，这其实是本末倒置的。

做复盘

「衡量」这个事情其实就是复盘。

相对做规划是向前看，那么复盘我们可以说是向后看，它指的是我们从过去的经验和实际工作中进行学习，帮助大家有效地总结经验，提升能力的方式。比起不做规划的人，不做复盘的人甚至会很多。

很多人只盯着之后我们要怎么做，但是没有回过头来，回顾一下我们之前做的东西是怎样的，这样我们就没有办法知道我们其实做得怎么样。

那我们怎么做复盘呢？

做复盘首先，我们要回顾一下我们最初设定的目标；然后，我们要来评估我们做完之后所得到的结果；第三步，我们要分析一下目标和结果之间的差异；第四步的话，就是总结归纳一下，我们在复盘的过程中，发现了哪些东西我们做得不够好的，如果让我们再做一次，我们怎么做才能做得更好的事情；以及，我们在做这件事的过程中，有哪些经验可以总结下来，之后可以复用到别的地方去的。

那么在复盘当中，我们有可能会发现这么一些的问题。

比如说，最严重的，我们根本没有做规划，没有目标，又或者目标不清晰，又或者团队成员之间对目标缺乏共识，甚至我们目标跟计划是脱节的。这样的问题，我们就能够在第一个环节发现得到。

那么这样我们就能知道在这一个方面，我们是做得不够好的，我们得到一个教训，我们会知道，在下一次我们做项目之前，一定要先做好规划，要制定清晰的目标，并且确保所有项目成员对目标能够达成一致，以及我们的设计方案我们的计划是符合我们目标的。

又比如说，我们可能会在评估结果或者分析差异的这两个环节里面发现，我们最后得到的结果并没有达到我们预期的效果。

那么我们就要来分析，到底是哪一个环节出了问题，为什么会出现这样的问题，我们有什么办法比如说优化流程之类的，可以去规避这样的问题？

再比如说，我们可能会在这个项目中积累了一些经验，学习了某项技术或者说得到了哪些心得体会等等，那么我们就可以把它总结下来，我们再看看能不能在别的项目之中，再复用这样的经验，从而提高未来我们的团队的研发效率。

保持技术视野

我们刚刚说到，做规划是往前看，做复盘是往后看，但光这样做是一维的，我们还需要往外看，把我们能力模型变成一个二维的，使得我们做规划和复盘时，能够更有效地发现 idea 或者问题。那么这个往外看呢，就是保持视野。

视野是指我们的思想或者知识的领域。但是视野并不是一成不变的，因为世界在不断地变化，我们不能闭门造车，要拥抱变化，要以此来调整自己发展的方向。

比如我们在做规划的时候，就可以从别人的项目或者分享当中，提取出可以借鉴的地方，然后结合到我们自身的业务上，这样做出来的规划才会更好。所以说，保持我们的视野这很关键。

那怎么保持视野呢？

保持视野我们可以划三个圈，分别是核心关注圈、一般关注圈和扫盲关注圈。这三个圈划分的逻辑是依照团队业务、个人兴趣和业界热点来划分。

核心关注圈，就是我们在团队的业务当中可能会每天都用到的，或者说自己感兴趣的，又或者说在业界非常火的东西，我们要保持高度的关注。我们最好能知道，它的实现原理是什么，它或者它的生态每天都有哪些的变化。

一般关注圈，就是我们在团队的业务当中可能不常用到，但以后很有可能会用到的，或者说自己有点感兴趣的，又或者说我们能预判业界之后有可能会火的东西，我们要保持一定的关注度，我们要知道它大概是做什么的，解决了什么问题，业界怎么评价它，有多少公司在使用它，它的趋势是怎样的。当需要使用的时候，可以以较快的速度和和较低的成本接入。

扫盲关注圈，就是我们可能业务中不会用到，自己也不太感兴趣，业界可能也不太火的，我们不需要放太多的精力去关注它，只需要知道它大概是做什么的，解决了什么问题，就足够了。

总结

那么最后我们来把今天分享的内容做一个总结，也顺便回答一下前面一位朋友的提问。我们认为，一个高效的前端团队，会具有三个元素，分别是架构模式、基础设施和培养体系，这三个元素是不断地相互影响的。

我们有了标准化和自动化的方法论，得出了架构模式，同时衍生出了相应的基础设施，而基础设施同时又在反向地优化我们的架构。

与此同时，我们也有了我们的培养体系，我们可以针对不同级别的工程师进行不同的培养。对于低阶的工程师，我们可以对照着我们的架构和基础设施来有针对性的设计学习路径或技术全景图进行培训；对于高阶工程师，我们用工程师进阶的方法论，培养他们做规划、做复盘和保持视野的能力，从而反向地优化我们的架构模式和基础设施。

QA

想知道前端团队的效率如何衡量？一个成熟高效的前端团队有哪些元素？

这是一个很好的问题，那么对于后面的关于「一个成熟高效的前端团队有哪些元素」这个问题，在总结的时候我们已经聊过了，这里就不再赘述了。我们现在来聊一下前面这个「如何衡量前端团队的效率」这个问题。

效率这个事情，其实是看不见摸不着，但又是客观上实实在在存在的。那么概括性地来说的话，就是在固定的周期内能够完成任务量的规模。我们衡量效率可以用这么几个方法。一个是，对于相似的事情，我们可以衡量所消耗的成本的多少来进行衡量；又或者反过来，在相同的成本下，我们可以做多少事情。还有另外一个方向，就是假设我们要做一件事情，有多少东西是重新从零开发的，之前的积累（包括经验和基础设施），有多少可以复用？做同样的事情，我们可以做得快多少，工具、熟练程度。同样复杂度的需求，能少用多少人去实施。

想了解只有5个人内的前端团队怎么样的技术体系开发才最有效率？

这个也是一个不错的问题。

只有 5 个人的这种级别的团队，和我们上百个人的团队，其实是不同的，最大的区别在于，我们可以产生规模效应，我们可能花 100 个 pd 去做一个工具，每次为我们节省 50% 的人力，100 个人的团队可能就做两次需求就回本了；但是只有 5 个人的团队，可能得做 40 次才能回本。所以说小团队可以借鉴我们的模式，但不能完全一模一样地去套。可以考虑只做标准化，不自己造工具做自动化。

但是小团队其实跟我们有一点是不一样的，就是小团队很敏捷。敏捷意味着，你们切换技术栈、换工具其实成本是很低的，你们可以利用这种的敏捷性去快速试错，去复用业界成熟的方案来提升效率，尽快把事情先做起来。

团队怎么保持业务开发和技术提升的平衡？

我其实不认为业务开发和技术提升是两个矛盾的事情，相反，刚刚我们在聊如何做规划的时候，我们就提到过，我们在做规划的一个前提是，我们要围绕着业务针对业务痛点，优化用户体验，最终提高转化率。

高阶工程师的能力之一就是结合业务去思考技术上的方向，所以我会推荐同学针对业务去做技术上的提升。

刚从开发转到管理，有点不适应，应该如何顺答题卡转型？美团点评前端部门在面试时会主要考察哪些方面的能力？面试流程是怎样的？

从开发转到管理，是个人贡献者到团队贡献者的一个转变，两者的本质区别是：技术是自己直接去拿结果，管理是通过别人来拿结果。一开始的时候你会觉得很多事情通过别人来拿结果可能还不如自己来拿得快，但是你要适应这种转变，因为随着规模的扩大，随着你的辅导对别人的帮助，你的团队会逐渐产生规模效应。作为管理者，应该做的更多是更深入的规划，以及更深入复盘，无论是对自己还是对团队。

我们面试主要考察的能力：学习能力、解决问题能力、专业能力、已经经验、后续成长的潜力……

面试流程：两轮技术面、一轮综合面，上面要考察的能力基本可以从这三轮里体现出来。