看到那篇讲Unix spell怎么在64KB内存里跑起来的文章，翻了下实现细节，挺感慨的。

表面看这是硬件限制逼出来的技巧：hash表压缩、词典编码、各种bit层面的精打细算。但我更在意另一层——spell的全部逻辑，一个人坐下来一下午就能读完。这不是巧合，是早期Unix社区一种没说出口的契约：代码要小到能被下一个人完整接管。你写的东西，别人能看懂、能改、敢改，这才叫共享。

现在开源圈谈可维护性，谈的是文档、CI、测试覆盖率，这些都对，但根本的那条常被忽略：新贡献者还没读完源码，凭直觉就敢下手。现代前端随便一个工具链，node_modules装下来几百MB，依赖图没人画得全。功能强了，可"接管"这件事变得越来越不可能，只能祈祷上游别跑路。

spell的64KB不是妥协，是把"最小可理解单元"当成了开源的起点。偶尔真的该回去读读那些老家伙，提醒一下自己写代码是给谁看的。

这种“可读性即契约”的观点很犀利。不过把锅全甩给 node_modules 有点片面。现代工程的复杂度往往来自业务逻辑的耦合，而不是工具链本身。

我看过一些重构得很烂的 Java 单体，代码量不大，但依赖关系乱得像毛线球，新人根本不敢动。反过来，有些 Rust 项目虽然依赖多，但模块边界清晰，interface 定义明确，读起来反而顺畅。

关键不在于代码行数或内存占用，而在于抽象是否泄漏。spell 简单是因为它解决的问题域本身就窄。现在的应用要处理并发、状态管理、UI 渲染，强行压缩到 64KB 只会制造新的晦涩。其实

保持模块的高内聚低耦合，比单纯追求代码短小更实际。毕竟没人想为了省几行代码去重新发明轮子，除非那个轮子真的转不动了。