经验之谈

五年架构

动态前端页面项目，是一个生命周期相对较长，相对复杂的项目。最初定义的协议，在替换了制作平台和渲染平台，依然还在使用。

可见抽象协议的生命力。我所见证动态化落地页项目，从2018年至2023年，依然在迭代开发。

相对漫长生命周期，只有相对稳定的架构设计才能良好支撑迭代。中间也许会经历技术升级，繁杂的日常维护。

越抽象越稳定，越稳定越抽象。系统应当是建构在抽象之上。

底层架构的设计，和不断涌来的产品需求一样重要。随着用户数量的增加，场景的增加，问题的难度也会有质的变化。底层架构也会随时间的流逝，体现其价值。

也许为了赶进度，产品没有达到80分，但架构设计上，依然要保留将来达到80分，甚至90分的可能。

低代码平台的困境

全场景覆盖的低代码平台是条不归路。技术上的难度不是问题，反而是为了实现通用性而带来的产品设计和交互上的复杂度逐渐失控这一问题，才是这类通用低代码平台的无解难题。要么覆盖不了场景，要么覆盖了，概念和交互复杂度高到不如直接写代码来的简单。如果真的有人能够平衡好覆盖度和复杂度，那就平地惊雷起高楼不远了。

我没有抬杠的意思哈，我目前的观点是，限定场景下的低代码平台好实现，是因为在固定场景中我们可以通过穷举来屏蔽掉元数据中的复杂度。很多的细节的确是不需要在元数据中存在。但通用场景下，我们无法这么做。我们只能从组件或者元素的角度出发，尽可能将每个组件或元素拆解得足够小，以此来应对复杂的需求。这种情况下，你的元数据内信息量就会呈几何级数增长。在低代码平台本身上表现出来的，就是平台本身的交互越来越复杂，导致普通人不会用，会用的人直接去写代码了。所以我的观点是，低代码平台如果要落地，无论是通过限定低代码平台的场景范围，还是通过其他手段，最重要的一点是要做好这个平衡。然而目前我们也没看到除了限定场景外其他有效的手段。唉，路漫漫其修远兮，共勉吧。

log