程序员洪志道

十篇技术文章，三十多次提交。该停下来看看了。 做了什么 回头看，做的事情只有一件：一层一层地把复杂度放到它该在的地方。 骨架先理（第二篇）——命名、文件前缀、构建分离。看起来琐碎，但它定义了项目的身份

架构的手法不需要很多。真正有用的，一个就够——反复用。 这一篇做一件事：把 fetch 的复杂度从事件循环里搬回 fetch 自己手里。拆一个 529 行的文件，搬一堆不该在 loop 里的逻辑，切断

代码能跑，测试能过，功能正常——但总觉得哪里不对劲。 每次有这种感觉，深入去看，根源都一样：某个领域概念应该存在于代码中，但没有。 不是功能缺失——功能都在。是概念缺失——代码不知道自己在操作什么。

前几篇从底往上清理了三层。engine 有 js_engine.h，conn 有 js_conn.h，buffer 有 js_buf.h，timer 有 js_timer.h——每个模块都有自己的头文

前两篇打磨了引擎层——js_epoll_poll() 封装了事件分发，js_engine_t 组装了 epoll 和定时器。引擎层现在很干净。 但往上看一层，我发现了一个不对劲的东西。 连接结构体里有

上一篇把事件引擎封装成了一行 js_epoll_poll(100)。这一篇引入 jsbench 最核心的结构：工作引擎。 最终的结果是：一个叫 js_engine_t 的结构体——每个线程一个，同时拥

AI 写代码像盖楼。前几层盖得又快又稳——函数命名、逻辑实现、测试覆盖，都不错。但楼越往上，问题就来了。高层靠的不是砖头砌得多快，而是图纸画得对不对。图纸就是架构。 事件引擎是 jsbench 的地基

我写了十几年代码，在 nginx 团队工作。最近做了个实验：让 AI 从零写一个 HTTP 可编程压测工具。C + QuickJS，大概两千行，一天就能跑。 然后我花了几周，把它的架构重新做了一遍。

前几篇一直在修问题、改代码。这篇停下来想想：到底什么是好的架构。 如果让我用一句话回答"架构是什么"，我的理解是：架构是管理复杂度的方式。 管理复杂度 一个系统要做的事有多复杂，它就有多复杂——这是客