前言
今日早读文章由美菜@胖弟弟投稿分享。
@胖弟弟：4年开发经验，2014年毕业于北京大学智能科学系本科，曾就职美团、猫眼、有赞，现任美菜无线前端负责人。
正文从这开始～～
一、回顾美菜前端的发展历史
2008-2018年国内前端经历了改革开放般的短期巨变，十年时间，前端的职能颠覆，和其他开发岗位有巨大差异，然而很多公司对于前端的认识还停留在过去或存在延滞。
美菜前端伴随业务经历过4年磨砺，从前端团队的成立，到形成第一代架构，每两年左右会逐步形成下一代架构的雏形。2018年上半年，无线前端组诞生，统一承接移动端技术栈和混合应用开发人员体系，美菜的前端正式进入3.0阶段。
原始时代，1.0 阶段，2014-2016
行业级框架 React、Vue诞生，彼时 Angular、YUI 、BackBone 等框架流行，但业内对待框架的态度相比现在更保守。熟悉框架的优质程序员缺乏，大部分系统还需要后端参与前端代码维护，前后端未分离。进入2015年，美菜已经产出了一套基于 jQuery 的框架及UI 组件库，后期又封装了基于Antd的SpruceJs。前端框架设计思路传统，面向后端开发友好，部分解决了业务线剧增带来的效率问题和职能配比失调的问题。
同时期，原生端，应用开始研发。移动Web端，基于 Zepto，逐步在多业务线展开开发，早期对于UI、页面交互的标准不高，研发可以主导产品的功能、交互，快速迭代。
农耕时代，2.0 阶段，2016-2018
走向框架、走向前后端分离和模块化分级。
2015年 React 优先发力，很多团队已经跃跃欲试，卡在2016年入场选型的国内团队，不约而同地把目光聚焦到 Vue。借住 Vue 的东风，美菜前端的 PC Web 端及移动 Web 端的框架统一。
业务井喷，迫于开发的敏捷需求，移动端走向混合应用。B2B生鲜领域在线下业务繁重，对终端的使用体验提出了更高的要求，客户在 APP 端的操作不可避免地多线、复杂，销售人员也需要通过工具更快地触达商户，获取最有效率、价值的工作任务。。。前端整个架构体系逐步完善，到了这个阶段后期，框架选择已经次要， 主要矛盾转移到研发效率、项目稳定性、多平台业务复用上。
我们进入全面工程化的阶段，一线开发人员同时是技术类产出的主要对象，高频应对来自业务的直接压力，既刺激开发人员的成长，也推动工作模式的优化。
机械时代，3.0 阶段，2018
走出框架、走向业务，前端的思维突破，多端、平台化开发、一站式开发、业务模块化。
端的人力分配差异逐步扩大，小中台，强前台。PC 端的业务从人力密集型走向技术密集型，提升自动化。中后台的繁重业务通过模板系统解决。精细化运营诉求推动营销系统也从运营人力导向转向数据导向。
工程开发思想抹平框架差异，各种框架开发模式趋同化，过去大而全的前端框架的意识演化为前端体系的一部分。前端的架构模型，变成面包板模式（BreadBoard）。
前端开发更加专注到解决业务问题及平台问题。开发人员在日常开发中不必要花费太多精力去进行基础功能维护。团队统一规划专用、平台化的业务层，避免重复工作。对于之前的一些焦点问题，变被动为主动，进一步提升整个系统的反馈机制。
二、前端的早期表现
敏捷开发模式下诞生的团队，不会套用过多流程，看上去很简单，但是实际研发人员的精力非常分散。部门之间的规范是逐步形成的，对于一些线上 BUG，一般从老板、投诉、测试那里被动接收，系统在不断打补丁。
平台多样化过程中，对各个平台技术栈的健全以及开发人员对工作栈的掌握程度提出了更多要求。框架差异化带来极大的熟悉成本和人力成本是无意义的。本质上说，我们要明白的还是自己要解决什么问题，框架能解决什么问题。过去普遍的认识是前端工具链在不断变化，前端似乎需要不断学习新的工具使用，但是链路真的在变化吗？
前端要解决的问题是在变异，不过是相对潜移默化的，框架的升级应该是量变到质变。原始开发阶段的各类矛盾突出，一些“月经”场景：
场景分析
在工程化方面，我们要解决的，说到底都是效率和质量问题。
当下前端工程化的产出，一部分还是前端项目工程化，延续过去的路子，继续在单人、团队研发效率上钻研，产出表现为组件、开发工具，前端自己就能搞定，效率提升的的直接受益也是前端开发。另一部分综合服务，就需要多团队，或者多功能人才的推动，不仅能影响到更多团队，也能反哺业务效率。
到了现代，很多系统的上线，仅仅靠前端的研发能力和推动力已经很难落地。这也是为什么很多前端团队还长期停留在造一些小轮子，尤其是 UI 组件方面轮子的窘态。但我们没必要放弃驱动，我们关注是需要在架构的面包板上插入什么服务，而服务的上线，依靠的不仅仅是你的代码能力。
业务的不断迭代和补丁式的维护状态驱动着我们的开发模式进行进化。
三、BreadBoard模型
2014年以前，移动端的市场地位还在攀升阶段，我们遇到更多是浏览器端的兼容性、组件库的完备性、页面加载性能及 SSO 优化等问题。浏览器端虽然也会遇到差异性，但是开发模式相对统一，便于在公司内形成规范。而在移动互联网大爆炸的时代，各路平台的迅速兴起，带动了前端的裂变。多平台，不同的语境情况下，工程化要处理的问题更复杂。
美菜无线团队的职能覆盖了“供应链——销售——商城”，除了后台系统以外（我们也有后台需求），在业务链路上的精力已经被分散到9个端，多端复用的挑战有：差异化管理、基础服务复用、组件复用、页面复用。
团队框架的能力，已经脱离了大而全的时代，而进化到插件时代。过去我们可以用一套 Yeoman 解决问题，现在不同平台光模板就得准备几套。框架必须要升级的原因：
-
大而全的框架不可能满足所有团队的需求、灵活性差，个性化定制也不可避免；
-
传统框架想解决的问题过多，期望初始化一劳永逸，而团队的整个工作链路涉及到项目初始化的配置、开发过程、测试流程、上线发布，可插拔的功能件需求更多；
-
传统架构模式依赖前端框架，前端框架的选型决定前端团队架构模式，而目前的前端团队应对的场景是多端，多平台，前端框架退化/进化成团队框架的一部分，框架不能决定架构，架构来吸收框架；
-
开发要聚焦到核心业务逻辑，提升对核心业务逻辑的梳理能力。
框架理解
React、Vue 的争议短暂存在过，两年之前，团队在框架选型、业务项目的基础建设会浪费大量时间，项目之间的不可复用性极高。人员移动的学习成本极高。程序员对于 React、Vue 这些框架的定位认知有问题。现实是，如果不能更好地梳理项目的数据模型，不管使用 React还是Vue，项目最终还是会进入一个复杂的逻辑管理地狱（C 端）。所以引入框架，解决了部分问题，却不够根本。
整个团队架构的升级根本依赖于对框架认识的升级，团队的 MVVM 框架设计，基于对 Flux 的理解，React、Vue 的差异仅仅存在于 View 层面，以及所配套的一些生态链工具，他们所带来的框架差异应该控制到团队架构的一部分。
壳工具的理解要抹平平台之间的差异，同时在更小的范围内做更细粒度的区分。前端的精力聚拢之后，向两个方向分流，一部分是核心业务的理解和数据开发，一部分是工具链路的插件开发。
eg：基于ReactNative的新项目，过去的启动成本极高，需要了解基础的 iOS 项目启动、安卓项目启动，同时进行业务开发和公司服务接入。我们开发React Native壳工程，降低精力分散，接入方早期学习成本仅 React（如果是前端，已经是接近0成本），而由工程本生来对接公司的业务层逻辑和其他工具。业务层可以做哪些事情：
-
专用业务层：首页、订单、搜索等三方业务层、扫码、地图
-
平台业务层：跨终端标准化接口、登录、定位、地图、分享、通知
四、驱动模型
开发的关注点在哪儿？团队的核心是人，但是我们通常的观念是把关注点直接落到人的成长上。人在向公司，向团队，要求成长和薪资。虽然这也是积极的模型，但是不成熟。我认为个人和团队的成长，说到底都需要归结到具体的事情上，由事来驱动人，而你要做的事情，由驱动模型决定。
| 模型 | 特征 |
|---|---|
| 补丁型 | 无法实现判断，紧急处理问题、解决、防止 |
| 防守型 | 指定预防策略、应对策略 |
| 进击型 | 实施模拟对战，和演练，线上模拟、压力测试 |
补丁阶段，监控的数据来源是哪儿？反馈、自测、领导?线上 BUG 就像暗处的敌人，不断放冷枪。仅仅靠打补丁维护的系统，长期预期将会走向崩溃，所以要尽快进入防守型的状态。
我们需要完善整个防守的链路，这依赖于完备的监控体系。那监控到底要监控那些东西？
一个完整的链路需要包含监控、追溯、止损、预防。目前我们已经将流量导向不同的系统：
-
全量日志的系统（负责整体性指标，如网络可用性、埋点可用性）、
-
个体日志系统(提取个体用户的关键信息，正对性分析客诉问题)、
-
异常日志系统（采集异常问题Crash、错误日志）
一个防守雏形形成，但是做到完备的防守还有很长的路要走，目前能做到预警、能看到线上的 BUG，但是重现、定位、测试、上线的追踪回路过长，同时无法找到一个用户的行为路径，一个良好的线上行为分析，还需要包括路径分析：需要知道用户在出现问题的时候的操作路径、方法执行路径（自动获取）。因此我们还有一些工作：
-
主动测试
-
客服等多反馈系统的回流
-
动态监控的回流，可以 push 触及用户，做主动回捞
五、Brief Summary & Future
工作流水线，全面模块化、插件化，贯彻了我们的开发阶段。工程化的最大收益是精力的收敛，非聚焦模块托管+监控，同时最大限度提升灵活性。Everything is plugin，我们目前的插件化还仅仅是第一步。人力梯队同样采用面包板，职能分工，同时展开流动。
短期强前台、小中台，中台承担部分基础建设功能，但是不会垄断“架构”。我们未来的工作重点要转向更加高可用的框架体系：根据实际场景合理选型、预见以年为单位的架构挑战。
没有一劳永逸的架构，也没有完全通用的架构，更没有人叫架构师，每个成员都有架构的角色。过去前端发展，借力于互联网的发展红利，而现在这个红利期已经逐渐退散。前端是最贴近用户的端口，前端工作的天然属性，决定了大多数前端所在的公司不会直接重视前端岗位和团队产出。即使短暂地因为技术痛点而得到一些焦点，也无法持久。前端团队的出路在哪里？一个前端人员的职业发展轨迹是否经得住推敲？
三年以前，如果你是一个精通 React 的前端，在职场上非常吃香，而到了2018年，要求更多了，职业发展的要求更容易受到行业流行技术的影响，是因为门槛不高？是大多数的从业者缺少竞争壁垒。技术人员自身发展模式的改变，改变技术为单一载体。去伪存真，解决问题。
防守姿态的前端驱动模型已经无法支撑一个前端人、一个前端团队在未来的生存，因为工作效率的提升，不需要这么多低价值的前端，也不需要企业去养一个低价值的团队。一个进击的模型才能支撑未来一段时间的成长基础。
美菜无线前端团队：美菜大前端环路的一部分，团队职能覆盖“供应链——销售——商城”相关的核心业务范围，无线前端组是美菜前端开发实力和开发态度的代表。现阶段无线团队架构形成的开发范式，包含驱动模型和面包板结构。
关于本文作者：@胖弟弟原文：https://tech.meicai.cn/detail/55
最后，为你推荐
