前言
今日早读文章由美团
叶俊星授权分享。正文从这开始～
为什么要讲这个题目
前端圈是一个被技术圈的人称为娱乐圈的领域，很多做后端的、算法什么的，会经常来调侃前端圈，知乎上甚至有个问题问「前端架构是什么，前端有架构可谈吗？」，甚至前端圈自己也有很多人在自嘲。但实际上，这些年来，随着互联网的发展，前端也在迅猛地发展，前端的需求变得越来越复杂，前端团队也不断地变得庞大。在一个复杂的产品和规模比较大的团队当中，如果说没有架构，只能说是手工作坊式地生产，效率太低。所以说，我特意选了这么一个话题，来悍卫一下咱们前端的尊严：）
什么是技术架构？
技术架构是指社会中各种技术之间相互作用、相互联系、按一定目的、一定结构方式组成的技术整体。技术架构——或者说技术体系——归根结底是围绕业务发展、团队规模和团队特点量身打造的，它的最终目的是在确保线上的质量和稳定性的前提下，提升团队整体的研发效率。
既然说，技术架构是围绕业务发展、团队规模和团队特点来设计的，那我们就要先梳理一下我们的项目和团队背景是怎样的。我们美团点评酒旅的项目和团队背景分别有这些特点：
项目的特点：项目之间差异中有相同。比如说B端和C端项目虽然面向的对象不一样，但是同样是要做用构建、要做测试的；又比如B端页面虽然业务之间各不相同，但基本上都是查询、表单和图表这么三种页面。如果说每个项目我们都重新地去做这些东西，效率就很低。所以，我们需要提高项目之间的复用率。
团队的特点：规模大。光我们酒旅事业群前端就有一百多个人，并且还在不断规模化，也就是说人在变得越来越多。那么大家都知道，规模化就会导致沟通成本的提高，我们希望能尽可能地降低规模化带来的成本上升，尽可能地固定规模化的成本，从而实现规模效应。
标准化
那么基于这样的项目和团队的特点，我们可以很清晰的看到，我们最先需要做的，就是——标准化。标准化对团队的本质是，我们要把整个团队使用的各种技术进行约束，对选型进行划分和收窄。
这样的约束能够给我们带来很多好处。
对于项目来说，我们可以把各个项目可复用的部分抽离出来，通过标准化来提高它的复用率。比如很常见的一点，就是把组件库抽离出来，使得这些组件可以在各个业务项目中复用；再比如说，我们把部署、监控等这些服务抽离出来，做成独立的服务，提供给各个业务线来使用。所以说，标准化后的项目，我们不再需要做重复的技术选型工作，并且可以很方便地寻找各种公共服务来复用，最终实现最终提高效率的目的。
对于团队成员来说，在标准化之后，项目无论是从选型还是所使用的公共服务来说，都几乎是一样的，所以不同项目之间人员的流动在技术上几乎没有成本，仅需要熟悉业务。还有，对于初、中级的同学来说，他们可以清楚地看到我们技术架构的全景图，有明确的、清晰的需要掌握的技术栈可以去学习，从公司的角度来说，团队在培训和招聘时能够也更能有针对性；对于高级人才来说，我们可以使得愿意思考、有能力的同学，有更多的空间加入到技术架构的思考和优化当中，把成果贡献到大团队里来，去影响更多的工程师和项目，从而获得更大的收益，最终结果可以用乘法来计算。
那么要实现标准化这个目标，我们就需要围绕着这个目标去做设计。
这个就是我们美团点评酒旅团队，在经过标准化之后，做出来的技术架构。我们可以看到，我们标准化的流程规范，会覆盖到整个从开发到构建、再到部署、最终运行的工作流程里面去。
自动化
那么有了标准化之后，我们就会发现到，有些环节它是机械重复的，我们是可以用工具、用机器去代替的。比如，我们有代码规范，以及提交代码时要进行代码检查的流程，那么我们可以发现，进行代码检查这件事情，实际上是可以自动化的。我们用了lint工具，去做这种自动化的检查。
自动化往往能成倍地甚至无限地提升我们在某个环节上的效率。
在我们团队的技术架构图中可以发现有基础工具、自动化测试工具、部署平台、监控体系，这些工具和平台，这些都是我们在标准化之后发现可以用机器去取代人工而做出来的。我们举两个更具体一点的项目，来让大家感受一下。
第一个例子的背景是，小程序慢慢开始普及，我们有非常多的小程序需求，而这些小程序的需求往往也有一套几乎一样的移动端页面，所以我们会发现我们在不同的平台做着同样的业务，这是我们出现的机械重复的工作。于是我们投入了一些人力资源，去研究如何实现一套代码同时在移动端页面和小程序页面，甚至Native中运行。那么考虑了我们团队整体是以Vue.js为主的，于是我们做了一个叫mpVue的工具，它做的事情就是，把Vue的语法转换成小程序的语法，实现移动端页面可以完美地转换到小程序的语法，实现了小程序的快速开发和多端复用，相比起之前我们需要工程师去学习小程序开发而言，有了这个工具之后，我们的工程师几乎不再需要学习小程序的开发，从而接近无限地降低了小程序的学习和开发成本。在未来理想的状态，我们可以实现一套代码，直接在Web端、小程序端（包括