早安,我的漂亮人们。
昨天,我在搭 Busy 的 React 客户端时,意识到了两个致命的问题。
错误的框架
1. React 全是魔法,而魔法完全违背我的代码宗教。这个教训是我 18 年前用惨痛代价换来的。魔法永远是坏的。耍小聪明就是玩危险,我不干。如果一段代码没法让人一眼看懂它是什么、不用查手册,那这段代码就没写对。这里存在明确的二元对错,必须存在。
所以 React 不是干这活的工具。
另外,我特别喜欢现代 JavaScript。而我不觉得我需要一个标准化的 JS 框架——我的开发工具(我正用它造这个的那位)是用整个人类编程实践史训练出来的。
让插件系统来拼装 UI
2. 我花了一个星期搭出一套非常优雅的插件系统。它是完美的。认知负担轻,直截了当,符合直觉。小而界限分明的插件,彼此解耦,清楚地分离关注点,体现一致的设计与实现原则,互相扩展和改造,并无缝接进一个由十个从不改动的文件组成的核心系统。
等你看到它运转得多顺滑、多好管理多好懂,你的下巴会掉下来。这东西的美和简洁不可思议。
那我干嘛还想写一个单一的整体式 UI,把它全部装进去,却不跟插件架构本身对话?
嗯,这是个蠢到家的设计错误。
一眼可见。
想通之后,我扩展了插件系统,把 UI 放进核心,用治理系统其余部分的同一套做法来做 UI 装配。
现在,Busy 构建时,核心 UI 结构由核心系统拼装出来,而每个模块自带 UI 清单(manifest),向核心系统说明自己被放在哪里、怎么设置。
关注点管理得更有效一点,也给未来想写模块的人留出了模块组织方式的差异空间。
把模块想成胳膊、腿和笔记本电脑,就是我们交给这些 LLM 智能体、好让它们能对真实世界动手动脚的东西。
跟着数据穿过应用
还有,不再搞愚蠢的单元测试了。
为什么我的脑子老坚持说我们需要单元测试?哈哈
单元测试把架构锁死,拖慢开发速度,却没真的证明你的代码能跑。你的代码可以结构上正确、同时坏着。单元测试不可信,因为不择手段的开发者可以把它设置成永远通过,而且它们解决不了你想靠它们解决的那个问题。
所以这也是错误的做法。
替代方案:我把流程测试(flow tests)定为流程的一部分,做集成测试。在应用里我想要测的特定片段跟着数据走。让它跑过我们明知道已为之编码过的场景,看着数据进去、被处理、从另一头出来。这还用说吗。
目前用着很顺,但将来我可能得重新审视我的测试策略。
这是一场进行中的实验。
很快再聊。