为了防止业务敏感信息泄漏，本文将不涉及任何业务情况，项目结果数据，项目屏幕截图等。

19相遇

时间到2019年8月，那是我加入Cool Home的那一天。作为一个IC，我投资了凉爽的家庭用户成长团队。当时，该团队主要参与C促进业务，例如激励系统，彩票，酷登录和奖牌。

新业务

2019年10月，用户平台线建立了一个新的“设计圈”项目，该项目是业务的。目的是打开企业的内部设计岛，并允许内部设计师共享，建造和成长。后来，它被开玩笑地称为“小主站点”，也就是说，主站点的子功能被清除。

在此过程中，我统一了所有前端页面启动逻辑，并添加了中间件机制以启动。中间件机制也首次引入了页面启动过程中，这对于多页和统一场景至关重要。对于管理的后端，引入了更尖端的（即当前），并进行了业务定制封装，以简化形式，形式和其他场景的开发，此操作也提高了有效性。感谢阿里巴巴对开源的贡献。

反射：

对于多页应用程序，有一个控制全局逻辑的条目。有很多方法可以实现它：HTML入口/JS使用固定的引导逻辑均匀地使用，等等。

垂直字段可以使某些技术轮毂。例如：表单管理的背景方案需要垂直字段以提高效率，但基本组件还不够

作为在此过程中的SM，从全球角度反复考虑问题，并注意团队成员的任务和过程

20返回

2020年2月，一半的能源返回了用户成长团队，直到6月完全返回。

迷你程序平台

在2020年1月，该公司的内部迷你计划业务增加了，需要一定数量的基础设施来提高整体发展效率。前端团队的老板促进了由几个迷你计划业务团队同学组成的“迷你计划平台”的特殊虚拟小组（设计圈也拥有迷你计划业务），以及从基础团队转移的学生。

我主动负责CI/CD零件，连接到DEF（公司的前端统一CLI工具），以及完整的套件，建筑，部署和其他功能。当时，微信系数不支持CLI部署，并且只能在 /Mac上使用“微信 ”工具。该公司已经拥有与工程相关的基础设施，根本无法使用。因此，在虚拟机上安装了“微信系开发人员”工具，并启动了本地启动以与开发人员工具进行通信。然后，CLI打电话给本地以完成通信。

反射：

微信开发人员工具客户端等以UI形式提供给用户。他们对小型团队非常友好，对于想要集成到大型团队自己的工作流程的系统（幸运的是，微信现在都提供SDK以促进在现有系统中集成）

我只参加了不到半年的“迷你计划平台”，并且该平台变得越来越大：包括微信官方帐户管理，用户管理，甚至域名管理，人员管理，操作和维护中心，营销工具以及其他本身已经提供的功能软件包。我已经投入了很多人力，但我个人认为这太先进了。主要原因是：

Cool Home自己的商业迷你计划并没有增长太多

边缘功能太多，大多数场景根本无法使用。我知道只需要这些核心功能：模板分布多合物迷你程序，CI/CD，组件库和脚手架。

基础架构不应太先进，应优先考虑达到最核心和最有效的功能。

TMS

对于C的产品，用户的增长主要是当时由运营驱动的，它是由一些营销方法驱动的，以获取客户并促进保留率，并且大多数产品需求来自运营同学。有两种用于操作学生的工具：

TMS：模仿淘宝商店装饰的页面构建平台主要可以完成产品简介页面，营销页面和其他功能的构建；

：一个操作平台，核心应用程序方案，例如营销推动（SMS，官方帐户，电子邮件和现场消息），以供C用户，广告空间管理和其他方案。 JS完整的堆栈开发，包括直接调用持续层。

当构建TMS页面平台时，有一个巨大的痛苦点：所有模块（前端开发的自定义模块）都难以开发和发布，并且所有模块都在NPM软件包中混合在一起，因此开发模块的过程如下：

在TMS管理背景中创建一个模块，这意味着在元信息之后获得模块ID。

在mod中开发一个模块，其中包含用于显示场景和编辑场景的组件

将NPM软件包链接到TMS管理背景中的存储库

开始仓库的本地模式（体验很差）

开发阶段结束和释放阶段开始

发布NPM软件包

分别将其安装在存储库中以进行外部渲染和内部后端管理

单独释放外部和内部系统

整个过程非常长，这导致了业务发展学生，他们更愿意在0-1撰写静态页面，而不是开发TMS模块，这不会导致不多的业务模块，并且没有丰富的生态学。

在开发TMS模块时，我也感到非常痛苦，因此我改善了在此过程中“开发新模块”的过程。

总体原理是从主体中剥离模块的安装和加载，并将其从NPM软件包转换为浏览器运行时注入的模块。当时，已经有种子了。它是相对基本的，并在全球安装。这是一个运行时模块加载和管理器，可以简单地进行比较。通过维护模块密钥与JS/CSS CDN列表之间的映射关系，它可以确定如何加载模块，并且通过大型JSON保存该关系。

解决方案非常直观。您只需要保存TMS模块密钥和包装模块后的JS/CSS产品，以便可以将模块安装与TMS主系统完全隔离。

优化过程如下：

在TMS管理背景中创建一个模块，这意味着在元信息之后获得模块ID。

开发一个满足每个业务仓库某些要求的模块

（打开TMS测试环境，并直接将模块请求委托到当地）

开发阶段结束和释放阶段开始

每个业务仓库构建模块，生产JS/CSS并自动上传CDN，修改JSON以完成发布

本地调试具有良好的开发经验，因为只有当前的模块才能构建。

种子和微型应用

但是，种子也有自己的问题。 JSON与其他现有发布平台无关，并且没有灰度或回滚，这是稳定的巨大潜力。

当时，公司的基础设施（酒吧）最初是成立的，并且相对先进。核心是具有最低可发布粒度的一站式解决方案。第一个建议是页面单元，该单元可以将传统的存储库多页作为出版单元转换为独立页面作为发布单元，并在几秒钟内以几秒钟的速度发布。最初是当时形成的前端微型应用程序，其主要目的是将巨大的石材应用程序施加凉爽的家用工具并提高开发效率。

当时，主要网站继续使用种子。前端微应用和种子的目标实际上非常相似，核心是独立的开发和独立释放。目前，一个想法提出了“前端微型应用程序可以支持浏览器端运行时加载，以替换种子模块管理部件的能力”，以实现“ in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in of in of in。

此时，前端微型应用的输出模式是HTML片段，可以将其注入到页面中，最后将完整的页面HTML输出到浏览器，即剪接形式。页面和微型应用程序可以独立发布，并在统一node.js页面层的服务器端拼接，以组装成一个完整的应用程序，该应用程序可以由多个团队共同构建。

然后，方法非常清楚。有必要扩展仅支持在服务器上使用HTML缝合的微型应用程序，以支持浏览器运行时间，以动态获取- HTML片段并将其注入DOM，并解决如何以同步和有序的方式执行标签的问题。这产生了“ Pub微型申请装载机”。

目前，诸如水疗或之类的图书馆已经存在。独立发布的功能由每个人共享。不需要沙箱和路由链接之类的功能，因此没有提及这些开源库要实现。

在此阶段之后，我们将遵循趋势，以促进种子历史模块的全部迁移到酒吧微型应用。相对好处是：

拥抱相同的基础设施（CI/CD），灰头发和回滚机制

无需页面预设环境

分散的，微型申请加载器安装在每个微型应用或页面中，小于8K（未压缩）

TMS的新模块开发方法也已从种子模块过渡到使用Pub微型应用模块的使用。

公共包裹

基础设施相对成熟，但是主要现场业务的公共套餐一直很混乱，质量不高。 “锋利的刀不会延迟切碎木材”，工具库和业务组件库的重要性是不言而喻的。在过去的六个月中，也启动了公共图书馆的创建和规范：

：除以业务领域，定义商业常见类型单元，例如解决方案等。

：工具功能

RC：特定于商业的组件库

ETC...

大多数公司在这部分中也做类似的事情，因此我不会详细介绍。

反射

HTML是构成页面，使用它作为入口点的基本单元，可以做得超过JS。

跨团队协作，独立发行，低耦合是提高效率的最佳方法

开源产品可以解决一些常见的问题，工作流连接，并且必须独立设计整体架构。

释放和回滚几秒钟可以解决大多数稳定问题

释放卡点或批准是针对初学者的保护，也是退伍军人的束缚

H2的开头还带来了一些新的挑战：

如何快速建立一个新网站

如何重用类似的块，这是一个更好的选择吗？

21创新之星

基于2020年下半年在年初在业务中建立各种新站点所带来的全面挑战，我正在考虑“是否建立一个物质共享平台，整个公司共同建立和股票以打破团队之间的信息障碍。

在这个阶段，我已经成为敏捷小组的一个人，并且具有一定的影响力，因此每个人都愿意与我合作，包括隔壁的同学。目前，UED团队同学的想法是“设计材料共享”，因此他们将其击倒，前端有5个人 + 2个人设计，并在业余时间建立了一个虚拟组来创建：Star 。

平台概念大而完整：

开发材料：网端，插件，材料开发CLI；分为两个类别：块，页面模板

设计材料：网络终端，插件

在这里，我们主要讨论开发材料，块和页面模板都是从“ Fei Bing”的设计中引用的，并使用“复制”的手段来实现重复使用的目的。优点是它可以随意修改，并且由于不满足而无法使用或扩展。类似的视觉效果可以直接使用。

插件代码分别分配开源项目（似乎是），集成了自己的系统和材料库。

整个系统都是完全堆叠的TS开发，包括插件，服务器以++完成。

反射：

现在看来，重复使用块的方式不如组件好，也不有用

页面模板被用作初始化页面或微应用的规格，也是实施各种业务线路的平台。

设计材料和插件大量使用。与原始文件下载和分发相比，在插件的帮助下自动享受最新的设计材料更有效。

因此，就块而言，Star失败了，因此逐渐优化了它，并添加了对微型应用程序的访问，因为微型应用程序的用户必须需要阅读文档。 Star是整合微型应用文档的更好平台，直接与微型应用程序的唯一密钥相关联。

登录并注册

在此之前，我还是负责帐户系统（UIC）的前端人员。 Cool Home的帐户系统可能是互联网行业中最复杂的系统之一，其复杂性来自：

针对各种产品：到C，b

对于多种身份：设计师，所有者和从业者，下面有许多细分行业

登录注册链接也具有一定的复杂性：

注册链接非常长，三方绑定 - >手机验证 - >选择身份 - >建议设计师/所有者 - >分发奖励

登录格式：三方，扫描代码，弹出登录，登录页面

登录期间的风险控制拦截，图片验证，

C＆B登录过程中的多项绑定

等等..还有许多其他未列出的

挑战：

总体程序写作：您可以想到一个回调功能，它在内部写了很长的逻辑，并且会影响整个身体。

数据流和执行流之间的混淆：可能总是存在的状态，例如尚未执行的某个（），过程中的数据传输是混乱的，没有主线

以上的结果是估计在x2处估计涉及的登录注册的任务

延长米西亚人，模具袋和其他业务需要开放帐户系统并重复使用相同的登录和注册功能（但在同一页面上不接受SSO，这决定了后续的建筑模型）

基于此，登录和注册组件被完全重构：

更合理的层次结构：基本软件包（通用UIC逻辑），核心功能（支持配置以确定外部需要哪种登录和注册方法），酷家庭业务场景中的微型应用以及其他业务场景中的页面

插入式体系结构模式：在完成异步串行执行方案的帮助下，将在登录注册之前和之后添加10个以上的挂钩，为后续扩展和解决执行流问题奠定了基础

全局：解决数据流问题

将原始非核心链接的逻辑分为近10个插件来完成业务逻辑

结果：

可扩展性：最初的想法是至少3年不需要重构登录注册模块。目前，我认为至少5年没有问题。

R＆D效率的提高：统一群体下几乎所有业务线的登录和注册；在接下来的几年实用战斗中，登录和注册业务的各种主要需求并没有影响核心部分，并且可以通过插件来满足需求。

整体投资回报率仍然很高

反射：

优化核心业务的体系结构值得投资

插件不仅用于工程领域，还用于业务。可以考虑需要一定的可重复使用性和可伸缩性的方案。

该体系结构是为了防止复杂性的指数爆炸

发展效率和规格

在过去的21年中，公司基础设施或特定业务的发展效率和规格也在继续：

为了在多个仓库中共享代码，创建了CLI，定位是基于业务线级代码共享。

标准化业务领域的机制为单位，并且不分开终端（PC，H5，MINI程序）

标准化棉布/// TS，可以及时共享和更新

标准化所有页面的启动方法，也基于共享

标准化全球弹出窗口的经理，并支持优先队列机制

ETC...

基于基础架构功能，所有业务仓库共享相同的XXX和相同的业务启动逻辑。

但这也带来了一些困难的问题：

GIT机制会混淆回购历史记录，并与许多无关的记录混合。

提交更高版本的git时，一些学生总是无法推动它

随着时间的流逝，两年后，已经有超过2k的线路（某些学生不正确地带来中间线），从而导致了后期添加的机制和repo ，这又导致repo与业务repo不相容...

这些问题只能由熟悉它们的学生来处理，以达到正常的推动力。因此，将稍后再弃用并更改回NPM，但是将添加某些功能以使其保持常规更新。

反射：

它具有其局限性，我认为通过基础架构采用单个业务系列的最佳协作模型直接面临单个存储库的施工性能问题，并部署了效率问题。

对于业务线的开发团队而言，最优先的是制定规格，将规格实施到代码中，并及时更新规格，以实现开发人员的相同开发思想，这对于协作开发效率非常有用；

不要拆分目的，其他目的的发展成本远低于团队中多人的沟通成本；

22创新

我在22年底写了“ 2022年末摘要”，因此我尝试在这里更广泛地谈论它，并具有某些相似之处。

位置的变化，从21年中期开始为MGR，并在22年初成为正式的MGR。还将有一些管理思考，但本文不会涵盖它。

客户包装平台

没错，我们再次开始建立一个平台。背景是，Cool Home的主要用户位于PC侧，并且大多数使用客户端（基于他们），其他业务线也将开发自己的客户（例如）。

因此，除了重新使用一些基本的扩展功能外，还最好长期拥有工程平台，将一系列功能（例如构造，包装，出版和发行和分销）集成到集成的端端。这是“客户端包装平台”，也可以称为“客户端平台”。

我做了以下操作：

首先，需要一个包装环境，不仅要包装应用程序/Mac，还需要支持应用程序的包装。

其次，需要包装管理后端，包括：应用程序管理，构建管理，版本管理，发布管理和权限

最后，定义了一组访问规范，并以node.js脚本的形式访问。该脚本接收一些传入参数，并根据参数生成最终的安装程序包（固定目录）。平台上传并回电以更新CDN URL，版本和其他信息。

总体逻辑并不复杂。让我告诉您IT和网页发布之间的一些差异：

现有版本，在线版本片段

有一个复杂的更新机制和一种灰白色的机制

不同的安装软件包通过不同的渠道分布，以促进后续安装源统计

多个包装目标： /Mac /，将为不同的目标提供不同的包装环境

该平台仍然没有做很多事情，例如：数据板，版本发行等，但近年来就足够了。

有些学生可能不明白，IT和CI有什么区别？

借助CI，只能触发任务，并且任务需要特定的操作环境。另外：版本管理，白发和频道分布都是该平台的独特功能。

反射：

核心业务的基础设施中犯错误的可能性较小

SSR

在过去的几年中，随着基础架构的升级，旧的（Java）+逐渐更改为（node.js）+，然后更改为（node.js）+。在舞台上，服务器端直接页面键HTML（SSR）不再存在。结果是搜索引擎的流量逐渐下降，SEO对于冷静的家至关重要，并且是一个非常重要的交通窗口。为了节省SEO，SSR的一些尝试始于22年的上半年。

但是，要进行SSR，它将与行业中常用的解决方案不同：Next.js不用于使用全堆栈框架，因为这样的全栈框架带来的问题是每个企业都需要独立的Node.js服务，并且需要持续的观察稳定性。对于企业开发人员来说，问题非常困难，并且对开发人员的要求非常高。

因此，SSR服务需要实现的影响：

每个SSR页面都可以独立发布，即使它们在仓库中

创建SSR容器服务，SSR服务开发人员在不关心它的情况下管理服务的稳定性

所有SSR页面在此容器中运行

所有SSR页面都需要具有沙箱，运行上下文隔离

有降级到CSR的策略

除SSR服务本身外，它还需要具有外围工具链：

计划详细信息页面是要访问的第一页。在上网之前，它在工具的帮助下进行了测试。在线发布的结果也非常好。它将在22年中期推出。

在此阶段，仍然存在一些工程问题，需要与基础框架组一起解决并集成到酒吧系统中：

本地发展：支持SSR和CSR的同步开发，以及标准的本地开发呼叫链

构建：自动确定哪些页面需要通过SSR并完成构建

发布：发布后，对于页面信息更改，请在几秒钟内与PR和SSR同步，以完成应用程序的自动更新。

运行：集成的请求链接浏览器 - > pr-> SSR，自动降级功能；并连接酒吧配置软件包，语言软件包和其他功能的功能

这个阶段将在22年的下半年完成。完成后，对于业务开发人员而言，开发SSR页面与CSR一样简单。它不仅是SEO的改进，而且对主屏幕优化也有效。

在此过程中遇到了各种问题：

在实施时，一些两方软件包在实现节点侧操作方案中不考虑。例如，使用了许多浏览器端的全局变量，并且它们被用来将它们注入每个页面的上下文中（但他们也提出了意外的问题，请参见3）

OOM问题：随着SSR流量的增加，有一天触发了代码的一端的临界点，也就是说，在运行几天后，内存溢出，并且该服务由K8S POD自动重新启动；故障排除后，它是一个非常基本的监视模块。并发HTTP链接达到一定数量后，它进入另一个分支。该分支在清洁缓存方面存在问题，导致记忆的持续增长未被回收。

GC经常导致CPU增加：根本原因是页面已使用 - 库来管理头部信息并使用 - 侧面 - 处理由变化引起的副作用。这个问题发生在我们的模拟/和其他信息中，这使得库错误地认为当前的运行环境在浏览器侧，然后将不应具有副作用的处理转化为DOM处理，这增加了New node.js中的空间，从而导致频繁的GC。

可以看出，当前的SSR解决方案不是完美的。尽管它是由沙箱制成的，但它们基本上是在同一线程中运行的，共享相同的CPU资源和内存资源。当由GC引起的CPU问题或OOM引起的问题发生时，它将导致总体上无法获得。

因此，解决这些问题的方法是仅执行多个过程。页面的SSR启动了一个独立的过程，主过程控制数据分布和应用程序更新。这可以充分利用多核CPU，并避免引起整体雪崩的页面错误。

反射：

我之前创建的平台更有效地研发，SSR可以解决某些业务问题

最完美的解决方案不一定是开始，最好保留某些可扩展性。

其他

在22年中，还有一些优化的优化：

23优化

在23年内，它主要优化了现有系统，在年中，它也从主站转移到了国际站。

SSR＆Star＆

国际电台的技术积累基本上等同于3年前的主站，因此仍然有许多问题需要解决，并且不使用一些效率改进工具，这与大多数业务线路有些不匹配。

国际电台具有良好的特征：多语言，多货币，多群集和许多三方依赖性也不同，例如登录和付款方案。以上所有内容都与前端密切相关，并且与开发方法非常紧密相关的是多语言。

至于多语言，该公司的基础架构相对完整：语言软件包CDN +配置背景 +项目粒状管理 +插件效率提高。但是，这也涉及许多问题：治理困难，例如如何清理一些无用的条目；验证困难，例如如何验证其他语言的有效性等。我还没有想到更好的解决方案。

MAGI配置平台

此外，配置页面的能力对于操作快速尝试各种增长方法也至关重要。目前，该操作将使用上面提到的TMS来构建一些营销页面和产品简介页面。但是有些不满足需求：SEO，性能，多语言等。

除SEO外，还可以通过优化TMS来解决其他两个项目。因为TMS的整体体系结构确定很难支持SSR，更不用说内置或两党组件了。除了页面安排要求外，还有这些要求：

开发人员编写的页面还需要具有配置功能，并且为特定功能开发特定的后端非常昂贵。

页面配置需要根据国家和人口维度的不同显示

子站点，例如不同国家的不同站点

为了满足上述需求，它计划构建一个低代码配置平台和低代码引擎。它仍处于很早的阶段，只有整体建筑设计和某些核心和逻辑的写作才完成。

总结

在这一点上，Cool Home的旅程已经结束。

在此旅程中，关于研发效率和质量的大量工作，这也使人类效率提高到其他职位（UED，运营和市场）。我相信，每项努力和效率的提高都会使您的家庭装修变得有些凉爽，这使我们在这个竞争激烈的市场中获得了更多胜利的机会。我在这里获得了很多收益，我希望集团核心技术将来会变得越来越好！

让我谈谈我对辞职的看法。由于同事的辞职并决定离开，我们经常看到一些同学在心中震惊。我曾经这样。但是，在加入凉爽的家之前，请告诉自己面对自己的心，不要关心别人的住宿或离开。只要您确定自己可以成长，增长并与计划一致，就足够了。鼓励他们在一起。