关于野生架构、标准化、赚钱和我到底想成为什么样的人

关于“野生架构”、标准化、赚钱和我到底想成为什么样的人

今天在看微前端的知识体系，我想起了以前做过的一个类似微前端的项目，实现方式我用“野生”来形容。

按照标准的微前端架构，路由管理的原则是这样的：
1 主应用负责路由分发，决定哪个子应用在当前路径下渲染
2 子应用是独立的单页应用，内部路由自己管理
3 主应用对子应用的侵入性应该尽可能小

边界清晰，职责分明。但我那个项目不是这样，甚至相反，这就是我称之野生的原因。

子应用内部不是一个单页面，甚至没有自己的路由系统
主应用通过更改路由状态来渲染子应用里不同页面
后来为了本地开发提效，我在子应用里面加了套路由系统，为了兼容现状，方案是这样的：
3.1 路由页面外再包一层页面，里面维护一个路由状态管理页面
3.2 为了让url地址看上去正常，符合逻辑，要反过来根据路由状态的值mock一下路由的显示

好野啊。但是问题在于，这套设计能用，而且复杂度可控，维护成本可以算得上0。

这让我想到一个问题：怎么权衡设计？

一方面，确实有更标准的做法，标准的做法已经被大量真实的业务验证了可以有效降低项目的复杂度。原则来说，要像标准化靠拢。

但是问题是，你当前具体的业务和项目真的有这么高的复杂度需要你用这么标准的架构来管理吗？

如果没有，那我觉得野生的设计就可以维持，用标准化就是过度设计。

就着这个问题，我和何老师聊了会，让我有更多的视角和更大的疑惑。

有些技术决策会主动推动工程化升级、架构重构、标准化治理，尽管可能事实没有多少明显的信号说明需要做这些，但是为了做成绩、建影响力、拿绩效、升职加薪，甚至更高层面，为了组织运转。

这让我意识到一个很现实的问题：技术决策，很多时候不仅是技术问题，它还涉及利益结构。做“高维方案治理低维现状”的好处是，这个行为能带来筹码，能维护系统运转。

那我挺矛盾的：

以前在工程化文化很强的环境里，我的理念很单一：标准化是对的。后来到了一个完全不同阶段的团队，我发现：标准不一定适配。

而且，当你只有一个理念时，决策很快。当你有两个理念时，就开始左右打拳。

当你能看到三个以上的维度，技术合理性、现实收益、长期风险，决策就变得好难好难。

我纠结的不是微前端，不是架构设计，我纠结的是我想成为什么样的人？

每次想到这里，都是好兴奋又好痛苦，这种感觉就像我有超能力，但是不知道怎么用。如果没有生存压力，没有晋升焦虑，可能我会更偏向实事求是。但现实是我得先存活下来。

好在我的痛苦程度慢慢变少了，我意识到：

用系统一系统二的角度看，就好像是，我在骑车，有的时候我意识很清醒，我自己掌握方向，有的时候，我累了，我脚还是踩着踏板，但是我没有可以思考着去哪。

这篇就写到这里，没有结论。