netabare

其实这个就是模块化、抽象和把复杂项目拆成很多小元件的本意。只可惜软件工程讲究的就是个叠床架屋，所以最后设计模式、架构一个比一个复杂搞得云里雾里，封装和抽象全往加 accidental complexity 去了。

op 这个做法算是用 AI 正本清源了。

其实也想到我自己前段时间工作上遇到的一个事情，但并不是 AI ，大概就是做的项目的 runtime 的 hypothesis 很不好控制，同时又要为 library 和框架的后续可扩展性思考，又要满足客户稀奇古怪的运行时要求，又不希望被客户的屎山业务倒灌把项目搞成 day 0 legacy 。

我那时候的思路倒不是拆 project （毕竟还是我自己在做），而是一个 repo 几个模块互相独立做，UI 和渲染都去掉了，直接在 vue 里写 TSX 打出 div 「看着表格假设他是个可视化组件」，响应式对上了再把渲染库插进来，然后立刻断网把缺的数据和实现全 fake 堵上，直接做出一个跟客户 app 对标的最小 app ，做完立刻把客户那坨狗屎接进来然后看看能不能把这个 app 换成「符合客户要求的最小 app 」。

全程我给我自己的要求是：不写任何「整合、修补、migrate 代码，尤其是对接不同的运行时和框架的，如果有一行，说明我写坏了」。然后就让 TS 类型体操来帮我把这一堆模块串起来。

然后就把去年两个团队定义了一大堆架构都搞不下来的任务一次性打通了。

所以我想，如果 op 那边能保持两个仓库之间有很强的隔离性质，其实这个思路还是蛮好，甚至可能都非常适合 AI 的。我这边那时候做那个项目做完整个人都不好了，要是那时候能让 AI 帮忙分担啥就好了（可惜不能）。