优化老代码的渐进式方法：以网络模块治理为例

Posted on

在软件开发过程中，随着业务的不断演进，老模块往往会面临代码膨胀、耦合严重、维护成本高等问题。本文以网络模块的治理为例，探讨如何通过解耦、抽象和自动化手段优化架构，提高可维护性和扩展性。我们从网络层与业务层的分离入手，分析当前架构的问题，并提出动态库拆分、API 设计优化、自动化代码生成等解决方案。最终，我们通过实践验证了这些改进措施的有效性，为老模块的治理提供了一套可行的方法论。

在这篇文章中，我想分享一些关于治理老模块代码的经验和想法。

我们负责的几个业务模块中，一个是与网络相关的，另一个是所有业务的中转站，类似于业务的“容器”，还有一个是数据库相关的模块。这篇文章主要聚焦在网络模块的治理。

早期设计的问题

最初设计这个网络模块时，用户量较小，业务场景也相对单一。当时的实现方式是将业务代码与网络层代码混在一起，每次新增一个业务请求，就需要修改大量接口、添加中转代码，并且网络请求的构造逻辑也都写在这个模块里。最开始这样做没有太大问题，但随着应用程序的发展，现在已有十几个业务，每个版本都会新增大量接口，导致这个模块逐渐演变成一个“公共模块”，甚至被我们戏称为“公交车”——所有人都在这里修改代码。

由此引发了几个问题：

  1. 频繁的构建错误：由于许多团队同时修改该模块，导致 build error 的情况时有发生。
  2. 代码膨胀：模块代码不断增长，大量业务逻辑与网络通信代码交织在一起，使得维护变得困难。
  3. 稳定性隐患：业务代码与核心网络代码混杂，任何改动都有可能影响其他业务，引发潜在的风险。

面对这些问题，我们意识到，首先需要做的就是分离业务代码和核心网络代码。其次，我们需要重新设计更合理的接口，使业务代码的编写更加轻松，同时在保持业务逻辑不变、尽量降低回归风险的前提下，完成模块重构。

分析问题与挑战

这个网络模块最早的设计并没有考虑到今天的业务规模扩展，因此所有业务代码和网络核心库的代码都混合在一个公共模块里，并对外提供了一个庞大的“全量接口”。每当有新的业务API需要增加时，所有团队都必须修改这个公共接口文件。

问题逐渐显现：

  1. 代码耦合严重：业务代码与网络通信逻辑混在一起，影响了整体的稳定性。某些业务团队在新增请求API时，不慎修改了核心网络库代码，带来了安全隐患和回归风险。
  2. 包体积急剧增长：模块中充斥着重复的业务代码，比如网络请求的组装、解析等逻辑，导致整体代码量迅速膨胀。
  3. 维护困难：所有人都在修改同一个大接口文件，导致代码冲突频发，构建错误不断增加，甚至还可能引发资源冲突等问题。

解决方案：逐步拆分与重构

我们的目标很明确：

  • 解耦核心网络库代码与业务代码，让业务代码能够独立管理，避免相互干扰。
  • 减少对公共模块的依赖，业务团队可以在自己的代码仓库中管理自己的网络请求逻辑。
  • 优化模块复用方式，减少不必要的代码编译，降低包大小。

但直接从公共模块剥离业务代码的方式难度极大，因为对外的公共接口已经广泛被使用，如果直接修改，可能会影响多个业务的开发，同时带来巨大的回归风险。我们尝试了几种策略，但最初几次都失败了。

最终，我们借助一个新的业务场景找到了突破口：某个独立 APP 需要一个轻量级的网络库。于是，我们采取了一种折中方案：保持现有模块不变，同时抽取核心网络库，形成一个新的独立模块。

这个新的网络库（我们称之为 zNet）不包含任何业务请求逻辑，只有最纯粹的网络通信功能，并将其编译为一个独立的动态库供该 APP 使用。这种方式不仅满足了该 APP 的需求，同时也为我们提供了一个“试水”机会——先验证抽取出的网络库是否稳定，再逐步推广到现有模块的底层替换。这样做的好处是：

  1. 不会影响现有业务开发：原有模块保持不变，业务团队不需要修改代码，避免了回归风险。
  2. 模块拆分的可行性验证：先在独立 APP 上验证 zNet 的稳定性，再逐步替换现有模块中的网络代码，实现平滑迁移。

进一步优化：业务请求的抽象

完成核心网络库的拆分后，我们又面临另一个问题：如何让业务代码更清晰地组织，并减少重复代码？

原本的业务请求代码是所有人共用的，构造 HTTP 请求、处理响应的逻辑都写在一个大文件里，每个业务请求都得手写参数构造、请求封装、响应解析，导致大量重复代码。因此，我们对业务请求的方式进行了抽象：

  • 定义请求实体对象：每个 HTTP 请求都可以抽象为一个 Request 对象，它包含请求的参数（如 Headers、Body、Method 等）以及相关的安全以及连接策略等。
  • 统一解析响应：构造请求和解析响应的逻辑被提取成通用的方法，业务方只需创建一个 Request 实例即可发起请求。

有了这个改进，我们可以进一步实现业务代码的自动生成：

  • 与服务端团队定义好请求参数格式后，可以用脚本解析这些参数，自动生成请求代码，避免重复手写。
  • 代码生成时可以自动添加安全检查，例如：
    • 域名检测，防止错误请求泄露敏感数据。
    • 统一的安全策略校验，减少人为失误。
    • 代码风格一致性检查，提升可维护性。

这套自动化方案不仅提升了开发效率，还提升了安全性和代码质量，因此我们还为此申请了一项专利。

结论

通过这次网络模块的重构，我们总结出了一套较为通用的老模块治理方法：

  1. 先分析痛点，找到业务扩展遇到的核心问题。
  2. 制定渐进式的改造方案，避免影响现有业务，降低回归风险。
  3. 利用新的业务需求作为突破口，验证新的架构设计。
  4. 通过合理的抽象和自动化工具，减少重复代码，提高开发效率。

这次网络模块的拆分和优化，让我们的架构更加清晰、维护成本降低，同时也为未来的业务扩展做好了准备。希望这些经验能对大家有所启发！