模块化设计技术：乐高积木、微服务与你的屎山代码
上个月我重构一个老项目，三百行函数看得我头皮发麻。那不是代码，是意大利面，沾着陈年酱汁的那种。模块化设计技术？书上说得天花乱坠，什么高内聚低耦合，真落地时，全是坑。
模块化，说白了就是把大问题拆成小问题。 但怎么拆，拆多大，接口怎么定——这些才是艺术。不是科学，别信那些银弹。
人类大脑一次只能处理有限的信息。心理学家说过，工作记忆大概能同时 hold 住 5 到 9 个东西。一个模块几千行，看完开头忘了结尾，还怎么改？所以模块化首先是为人类认知减负。 至于复用、可维护性，那是附带的好处。
说实话，大学课本一上来就讲内聚耦合，什么功能内聚、顺序内聚，简直催眠。但真正写代码时，不知不觉就把所有逻辑塞进一个上帝类。为什么？因为省事啊。人都是懒的。创建一个新文件，想函数名，写接口文档，多费劲。直接把代码堆一起，Ctrl+C/V 多爽。爽完之后呢？三个月过去，自己都看不懂。这就是缺乏模块化的报应。
学术界对模块化研究得很深。比如 代码依赖结构矩阵（DSM），能可视化模块之间的依赖关系。一个理想的系统，依赖矩阵是个下三角，没有环。如果有环，就是循环依赖——你中有我，我中有你，解耦的噩梦。有些研究用遗传算法自动优化模块划分，试图找到最低耦合的方案。但这些工具在工业界用得不多，因为重写成本太高。
软件模块化依赖结构矩阵示意图
有一篇 2021 年的论文《Modularity in Software: A Systematic Mapping Study》梳理了模块化度量的各种指标：耦合性、内聚性、传播成本等等。有意思的是，他们发现没有一种度量能完全反映质量。模块化好，不代表系统就好。但模块化差，系统一定烂。就像健康饮食不一定让你长寿，但天天吃炸鸡肯定短命。
这几年微服务火得一塌糊涂。好像不分服务都不好意思出门。结果呢？服务拆太细，网络延迟，数据一致性，调试地狱。我有次追一个bug，横跨五个服务，日志看了一下午，最后发现是配置写错了。想骂人。
微服务本质是模块化思想在分布式系统中的延伸。每个服务是个模块，通过 API 通信。理论上，团队可以独立开发、部署、扩展。听着很美。但是，模块边界的代价是通信开销。 单体应用中，函数调用几乎零延迟；微服务里，一次 REST 调用可能几十毫秒。还有分布式事务，碰过的人都知道那有多酸爽。
微服务架构过度拆分导致复杂度增加的漫画
行业里开始反思了。这两年“微服务反模式”成了热门话题。有些公司开始合并微服务，回到适度粒度的模块化单体。比如 Segment 团队曾经声名狼藉地拆了 500 个微服务，后来痛定思痛缩减成十几二十个。这事告诉咱们，模块化不是越细越好。找到合适的边界，需要深入理解业务。领域驱动设计（DDD）又火了起来，因为它教你怎么划边界。上下文映射，聚合根，这些概念其实就是模块化在业务逻辑层面的落地。
另一个动向是 Serverless。函数即模块。每个 Lambda 函数做一件事，极致解耦。但问题也明显：冷启动，局部故障爆炸，监控困难。我试过用 Step Functions 编排一堆 Lambda，那个可视化工作流看起来像蛛网，看着就头大。说到底，模块化如果缺少统一的编排，就是一盘散沙。
前端模块化：从 script 标签到 ES Module 的二十年战争
前端模块化也是血泪史。刚学前端时，还写全局函数，然后命名冲突。后来有了RequireJS，AMD格式，再后来CommonJS，Node.js统一。现在ES Module终于标准了，但打包工具又让你等半天。我至今记得给一个老旧 jQuery 项目重构模块化，差点把自己送走。所以模块化不仅是后端的事，前端折腾更久。
JavaScript模块化演进历史时间线图
看看当下，Vite 和 Webpack 还在为如何更快打包打架。ES Module 原生支持不错，但 node_modules 黑洞依然恐怖。包管理，模块解析，版本冲突，这些破事消耗了多少头发。有时候我想，要是所有模块都像乐高一样严丝合缝该多好。
学术界永远比工业界跑得远。现在他们研究什么动态模块化，程序运行时，模块可以热插拔，像换汽车引擎。论文里满篇的图，OSGi 框架，还有用机器学习的。
比如 可重构软件系统，允许在不停止服务的情况下替换模块。这在电信和航空领域早有应用，但现在研究者想把它普及。有一篇 2022 年的论文《Dynamic Software Updating: A Systematic Mapping Study》回顾了相关技术。但说实话，这东西在普通业务系统里风险太大，搞不好线上事故分分钟。
另一个前沿是 基于机器学习的模块自动重构。通过分析代码历史、commits、bug 分布，用聚类算法建议模块拆分方案。这种工具现在开始出现了，比如 Google 的 Klocwork 或者一些 IDE 插件。我试过一个叫 CodeMR 的工具，它分析我项目，给出了模块化评分和改进建议。有些建议很合理，有些纯粹胡扯——它建议我把一个 20 行的工具类拆成三个模块，就为了降低所谓的“耦合传递”。人工智障的一面。
机器学习辅助代码模块化重构流程图
回到现实。不管学术多炫，写代码的依然是人。模块化设计技术不是工具，是思维习惯。它要求你时刻思考：这段代码的边界在哪里？和谁通信？未来可能怎么变？这需要经验，也需要克制。
克制是反人性的。 人总想快速交付，所以堆砌功能。但模块化的缺失，最终会让技术债务利息压垮整个项目。我见过太多项目，死于没有模块化的代码大盘。
所以下次写代码，当你想把所有东西塞进一个模块时，停三秒。想一下，这坨东西以后还有人能改吗？没有。就只有我和你，还有编译器。
模块化，说白了就是把大问题拆成小问题。 但怎么拆，拆多大，接口怎么定——这些才是艺术。不是科学，别信那些银弹。
模块化到底在解决什么问题？
人类大脑一次只能处理有限的信息。心理学家说过，工作记忆大概能同时 hold 住 5 到 9 个东西。一个模块几千行，看完开头忘了结尾，还怎么改？所以模块化首先是为人类认知减负。 至于复用、可维护性，那是附带的好处。
说实话，大学课本一上来就讲内聚耦合，什么功能内聚、顺序内聚，简直催眠。但真正写代码时，不知不觉就把所有逻辑塞进一个上帝类。为什么？因为省事啊。人都是懒的。创建一个新文件，想函数名，写接口文档，多费劲。直接把代码堆一起，Ctrl+C/V 多爽。爽完之后呢？三个月过去，自己都看不懂。这就是缺乏模块化的报应。
学术界对模块化研究得很深。比如 代码依赖结构矩阵（DSM），能可视化模块之间的依赖关系。一个理想的系统，依赖矩阵是个下三角，没有环。如果有环，就是循环依赖——你中有我，我中有你，解耦的噩梦。有些研究用遗传算法自动优化模块划分，试图找到最低耦合的方案。但这些工具在工业界用得不多，因为重写成本太高。
软件模块化依赖结构矩阵示意图
有一篇 2021 年的论文《Modularity in Software: A Systematic Mapping Study》梳理了模块化度量的各种指标：耦合性、内聚性、传播成本等等。有意思的是，他们发现没有一种度量能完全反映质量。模块化好，不代表系统就好。但模块化差，系统一定烂。就像健康饮食不一定让你长寿，但天天吃炸鸡肯定短命。
微服务：模块化的终极形态？
这几年微服务火得一塌糊涂。好像不分服务都不好意思出门。结果呢？服务拆太细，网络延迟，数据一致性，调试地狱。我有次追一个bug，横跨五个服务，日志看了一下午，最后发现是配置写错了。想骂人。
微服务本质是模块化思想在分布式系统中的延伸。每个服务是个模块，通过 API 通信。理论上，团队可以独立开发、部署、扩展。听着很美。但是，模块边界的代价是通信开销。 单体应用中，函数调用几乎零延迟；微服务里，一次 REST 调用可能几十毫秒。还有分布式事务，碰过的人都知道那有多酸爽。
微服务架构过度拆分导致复杂度增加的漫画
行业里开始反思了。这两年“微服务反模式”成了热门话题。有些公司开始合并微服务，回到适度粒度的模块化单体。比如 Segment 团队曾经声名狼藉地拆了 500 个微服务，后来痛定思痛缩减成十几二十个。这事告诉咱们，模块化不是越细越好。找到合适的边界，需要深入理解业务。领域驱动设计（DDD）又火了起来，因为它教你怎么划边界。上下文映射，聚合根，这些概念其实就是模块化在业务逻辑层面的落地。
另一个动向是 Serverless。函数即模块。每个 Lambda 函数做一件事，极致解耦。但问题也明显：冷启动，局部故障爆炸，监控困难。我试过用 Step Functions 编排一堆 Lambda，那个可视化工作流看起来像蛛网，看着就头大。说到底，模块化如果缺少统一的编排，就是一盘散沙。
前端模块化：从 script 标签到 ES Module 的二十年战争
前端模块化：从 script 标签到 ES Module 的二十年战争
前端模块化也是血泪史。刚学前端时，还写全局函数，然后命名冲突。后来有了RequireJS，AMD格式，再后来CommonJS，Node.js统一。现在ES Module终于标准了，但打包工具又让你等半天。我至今记得给一个老旧 jQuery 项目重构模块化，差点把自己送走。所以模块化不仅是后端的事，前端折腾更久。
JavaScript模块化演进历史时间线图
看看当下，Vite 和 Webpack 还在为如何更快打包打架。ES Module 原生支持不错，但 node_modules 黑洞依然恐怖。包管理，模块解析，版本冲突，这些破事消耗了多少头发。有时候我想，要是所有模块都像乐高一样严丝合缝该多好。
学术圈在搞什么？动态模块化与自适应
学术界永远比工业界跑得远。现在他们研究什么动态模块化，程序运行时，模块可以热插拔，像换汽车引擎。论文里满篇的图，OSGi 框架，还有用机器学习的。
比如 可重构软件系统，允许在不停止服务的情况下替换模块。这在电信和航空领域早有应用，但现在研究者想把它普及。有一篇 2022 年的论文《Dynamic Software Updating: A Systematic Mapping Study》回顾了相关技术。但说实话，这东西在普通业务系统里风险太大，搞不好线上事故分分钟。
另一个前沿是 基于机器学习的模块自动重构。通过分析代码历史、commits、bug 分布，用聚类算法建议模块拆分方案。这种工具现在开始出现了，比如 Google 的 Klocwork 或者一些 IDE 插件。我试过一个叫 CodeMR 的工具，它分析我项目，给出了模块化评分和改进建议。有些建议很合理，有些纯粹胡扯——它建议我把一个 20 行的工具类拆成三个模块，就为了降低所谓的“耦合传递”。人工智障的一面。
机器学习辅助代码模块化重构流程图
回到现实。不管学术多炫，写代码的依然是人。模块化设计技术不是工具，是思维习惯。它要求你时刻思考：这段代码的边界在哪里？和谁通信？未来可能怎么变？这需要经验，也需要克制。
克制是反人性的。 人总想快速交付，所以堆砌功能。但模块化的缺失，最终会让技术债务利息压垮整个项目。我见过太多项目，死于没有模块化的代码大盘。
所以下次写代码，当你想把所有东西塞进一个模块时，停三秒。想一下，这坨东西以后还有人能改吗？没有。就只有我和你，还有编译器。