对多活动页面的处理我也讲讲我自己的一些心得

[feiandxs]

看到标题进来的时候我是很激动的，因为我上一份工作中我也做过几百个活动页，而且作为这块的基建负责人，算是对这块有一些经验。

首先这东西肯定没什么标准答案可言，不同公司的发布方式，发布频率，使用的技术栈，包括部署模式等都不一样，没有标准。

不过就我而言，到后期也算是总结出来了一些自己的经验。

我们使用单仓库，从最开始坚持到最后，单仓库才便于协作。 最早期的版本中其实每个项目是独立的的在各个目录下，比如 /hd_1 /hd_2 /hd_3 等。这就涉及反复编辑处理 ignore ，复用的乱七八糟等很多问题。

后来使用了 webpack ，使用了统一入口，把手动配置的目录名房到了 config 里去做，毕竟同时开很多活动项目的可能性也不大，偶尔修改点老的，只要在配置里手动修改下对应的名称，就可以在加载的时候自动去对应的目录里去寻找源文件。

我们当时是基于 Vue 技术栈，封装了大量常用的组件，SDK，等，虽然组织的不是很好，但慢慢积累下来，效率还是明显提高。

巨大的单体应用这个概念在我这里不存在，因为每个项目开始前都要新建一个活动，每次 dev server 启动的时候只去一个目录加载，会无视其他的目录，启动速度还很好。但积累的公用组件多了后，每次快速找到自己需要的东西 import 过来就很烦，得靠人力。 有的时候人懒了，就会一次性引入很多东西，造成打包变慢，应用体积变大。

有段时间我尝试修改一个新的配置方式，通过新增一个简答的配置文件，确定这次我需要使用的东西，或者看有没有合理引入 tree shake 的方式来进行精简，但这个工作没做完，后来也被我砍掉了。写配置真的是一个反人类的方式，这样不好。

后面还有一些修改，但大的核心逻辑没变。 说是一个单体应用也行，但每次开启的时候都只是从一个 hd_xxx 启动，同时并行很多项目的可能也不大，还算是方便的。

有段时间我想取消手动建立活动名称 hd_xxx ，改用 hash 来创建，后来也还是改回来了。一个确定的名称，比如 179 号活动，是非常方便开发和运营人员进行沟通的。

部署的模式是完全信任前端，自己集成了一个 npm run deploy 命令，跑起来就是根据 env 打包，优化，图片发到cdn拿到地址后替换进来，然后deploy 到阿里云 oss ，每次添加一个 ?random_hash ，打印出来，供开发交付。

我至今觉得我这些年总结出来的这个方法还是挺有用的。因为做活动页的 fe 肯定都有近似的问题。 大量页面的组织管理是个问题，打包发布是个问题，集成是个问题，文件的有序组织，过往项目的归档，绕来绕去，真的是很头痛。我甚至可以肯定的说，比起写一个单一的中大型项目，几百个活动页组织下来的难度肯定是更高的。

反正我也和别人聊过，感觉大家还是有一些思路逐渐趋近的。比如说啥都得单仓库，巨大的单体应用绝不可行。但实现思路上又有分别，有的人是做的类似前端网关的模式，根据url hash 开始加载对应的内容，打包的时候也是类似的思路。有机会的话我也想看看这一方面是怎么做的。

[mebtte]

@ibegyourpardon 大量活动页面的维护确实很费精力, 从项目架构上能做的比较有限.
或者可以寄望于建站平台或者低代码平台的后续发展, 从代码角度的维护变成数据角度的维护.

[feiandxs]

这方面的尝试不是没有过，虽然要做出跨行业跨领域的低代码生成工具基本就是痴心妄想，但聚焦于前公司本行业内的我也有尝试过，后来发现其实还是不可行。
看起来减轻的工作量，并没有真正的解决对大量不同类型内容的管理问题，难点主要就是写活动页处理的不只是内容，还有内容之间的关系。
不是说完全没用，但我感觉更像是，比如说你家里乱糟糟的，找东西都不好找，于是你买了一堆箱子，把东西都塞进去，装起来，看起来家里好像变的整洁了，有走动的空间了，但其实对找东西的问题还是没有根本的解决好。

不管怎么说，对活动页的整理，收藏，恐怕不只是一个技术问题，也会是一个一直持续下去的，有趣的工程问题，甚至是生活理念问题。
我还蛮希望看到 fe 们对这方面有更多的讨论的。 XD