中台的解析
中台就是资本家对程序员进行压榨的核武器。
当下的大背景，互联网C端增速业务早已进入放缓的阶段，B端业务由于本身进展缓慢的特性，各大公司开始了痛苦的存量博弈，产品层面可以创新的突破点越来越少，对运营的依赖程度稍有提升。各种基础设施如电商、社交、搜索引擎也已经建设完毕，新的APP很难在众多寡头的围剿下成长为巨型独角兽。在盈利增长期望下降的情况下，降低成本支出的期望是资本家常用的企业管理手段。
而所谓中台，就是把公司技术、业务、组织中高频的、通用性强的、可系统化的部分抽离、固化到信息系统里，从而减少重复劳动，降低成本，提高公司的盈利。对于公司而言，中台做的是减法，开发中台所带来的收益虽然在短期内为负，但长期来讲大概率是正的；对于程序员而言却完全相反，虽然短期内有活儿干，有钱拿，但当中台建设完毕，程序员可以继续造的轮子就少了，公司对程序员的需求量就会缩减。
在巨头公司完成内部的中台建设后，很快又会进行中台的商业化，也就是把中台包装成产品，以SaaS（软件即服务）的形式对外向互联网中小企业和传统行业输出，进一步导致互联网中小企业和传统企业对人力的依赖程度也会跟着降低。在没有新的技术革命带来当前商业竞争格局的打破之前，程序员的内卷程度会越来越高，面试LeetCode Hard甚至ACM Regional难度指日可待。资本家将对没有利用价值的程序员进行无情的碾压，大批人会被作为高端人才向社会输送。
一些幼稚的程序员总是鄙视公司中的各种重复造轮子行为，殊不知，建造用来剔除重复劳动的中台系统很可能是自掘坟墓。到时候不止是程序员，恐怕在座的各位产品dog和运营dog也会受到影响，因为很多程序员会被迫转做产品和运营和你们抢饭碗。
互联网的产品变化较快，很多团队 / 企业在很多领域都有投入，那这些业务之间的一些共同技术建设，如能复用起来能降低业务冷启动成本，提升新业务研发效率。中台建设也是基于这个核心诉求，基于中台能力建设，能做到跨业务、跨领域技术复用，缩短新业务初创时间并节省资源。同时，复用的前提是解耦，能做到通用的能力和业务个性化能力完全解耦。解耦的架构设计，可以降低系统本身的维护成本，增强体统健壮性。解耦的设计能更好的业务之间复用。
大前端中台建设类似，问题存在就得用方案去解决，中台建设是其中一种方式(大中台、小前端)。中台不是万能的，不能解决所有问题。技术复用带来如何满足个性化诉求的问题，需要进一步思考如何更好地解决各个业务之间个性化能力。从火热到冷静也更能反映技术本身的演进，冷静并不是代表放弃，而是面临新的问题如何进一步解决。
前端中台的分层架构
回到前端工程化的能力，针对前端中台来说，一定程度上工程化就是在前端中台的事情。把前端通用的一些规范、工具、能力、组件统一化中台建设，提供不同的业务支持。
因此从设计上，应该包含基础层，统一网关，组件层，业务层。基础层提供基础的工具和能力支撑(诸如全链路监控基础工具)、统一网关(统一路由分发、业务个性化插件)、组件层(基础通用组件、组件二次开发体系、组件组装、智能研发)、业务层(业务逻辑与业务组件等)。
每一个环节都很关键，能够把我们业务开发的基础、插件、组件、业务完全隔离开来，尽可能做到不同复用。
中台的拆分与合并，我们该遵循怎样的原则
架构解耦和拆分工作，本身就是一个度的把握。原则上既要解决逻辑耦合，又不能过度设计，允许一定程度的冗余。在开发过程中，要看到实际业务之间可行的复用能力、模块、组件，而非理想情况下的复用。基于实际的复用诉求，进行业务提炼解耦，并做一定程度的超前思考(原则就是做有意义的拆分)。
前面提到的架构设计中，统一网关层插件、组件二次开发就是要解决这些问题。支撑不同业务自定义插件(或许这些插件之间存在部分重复，但不影响整理架构复用)、组件二次开发进行复用，能做到整体上架构一致和不用业务之间个性诉求。
前端中台的建设实践
上文已经提到了刘恒兵老师团队的前端中台方案和设计。那么其中遇到的问题主要还是怎么尽可能复用以及业务个性化诉求。我们经常会超前研发设计一些拆分与解耦，但后续实际过程中发现是一个伪需求。比如说组件，很多时候提炼的业务通用组件发现后续业务并不能直接复用，业务个性化诉求太多了。
方案上，通过组件二次开发体系建设，解决这类问题。我们发现虽然业务组件不能直接复用，但又能复用其中一部分，直接使用不满足诉求，重新开发浪费精力。其实这里核心的问题并不是复用，而是复用的效率，最后搭建二次研发体系方便研发能够快速二次开发，提升二次开发效率，达到复用的目的。
回顾与展望
2020 年，疫情下的“前端”
回顾 2020，我印象比较深的有三件事：一是 TypeScript 的大范围普及，二是工程化的发展，三是全栈深水区。
相比于 2019 年，2020 年 TypeScript 已经深入人心了，各前端框架对 TypeScript 的支持进一步推动了 TypeScript 的应用和普及，语言层面的发展能非常快速的促进一个领域的发展，正如 Node.js 促进前端领域发展一样。
2020 年的疫情给整个社会带来的新的挑战，企业对于研发效率的迫切需求进一步促进了工程化领域的发展。以前工程化对于很多研发人员仅为了解或者认知仅限于工程构建。疫情期间的工程化已经演变为对企业效率的诉求，各个领域都需要工程化体系帮助远程办公、移动办公提升效率。
2020 年，大前端全栈逐渐进入深水区，不再是仅仅满足基本的 SSR/BFF 等诉求。对 Node.js 新的期待逐渐变多，承担更多的场景。中台化后统一的服务、网关都是需要 Node.js 去承担，因此带来的服务质量、容灾等各方面诉求就对 Node.js 提出了新的要求，全链路监控、Serverless 服务质量 / 性能等都需要进一步建设和完善。当然，这些挑战也会进一步促进 Node.js 的生态发展。
2022 年，前端人如何成长?
以下三个方向都很值得关注：
Node.js 全栈，当进入深水区之后，大家要研究的就是如何进一步突破瓶颈，包含当前遇到的 Serverless 性能(冷启动、并发)的挑战。
云工程化 (含 IDE)，提升企业远程办公、移动办公效率。
智能研发，改变研发模式，对于业务基础的、通用的 UI 还原可以释放资源，让机器代替研发，提升效率。
前端从业者一直面临的挑战应该就是不断学习的能力，从历史来看，新的技术层出不穷，需要保持不断学习，那么明年或许一样，也会有新的技术诞生。对于我们自身来讲，保持客观的心态，认知每一个新的技术、领域的时候需要从问题着手去了解(解决了什么问题，对当前业务的帮助)，然后合理应用。
针对全栈领域进入深水区后，需要提出更高的质量标准要求，搭建工具并抽象解耦复用，提升服务质量。