PHP项目老旧代码如何逐步现代化改造升级

本文目录导读：

1. 第一阶段：准备与评估（不要急于改代码）
2. 第二阶段：低风险、高收益的快速胜利（即刻提升可维护性）
3. 第三阶段：架构解耦与核心重构（难度升级）
4. 第四阶段：现代化工具与生态
5. 第五阶段：持续改进与组织保障
6. 避坑指南（血泪教训）
7. 一个可执行的年度行动计划

针对PHP老旧代码的现代化改造，这是一个系统性的工程，不能一蹴而就，核心策略是：在不中断业务的前提下，采用“绞杀者模式”（Strangler Pattern）或“修补者模式”（Bubble Context）逐步替换或重构。

以下是一套分步执行、由浅入深的改造方案：

第一阶段：准备与评估（不要急于改代码）

1. 建立自动化测试保护网（最关键）

   • 原因：没有测试，任何重构都是“盲人摸象”和“定时炸弹”。
   • 做法：
     • 对核心业务逻辑（支付、结算、用户登录等）添加集成测试或端到端测试。
     • 对高风险或即将改造的函数/方法添加单元测试。
     • 工具推荐：PHPUnit、Codeception、Behat。

2. 引入CI/CD与代码质量管理

   • 使用 Git（很可能已经在用）。
   • 配置静态代码分析工具：PHPStan 或 Psalm（设为level 1或最高级别，强制修复所有潜在bug和类型错误）。
   • 使用 PHP CS Fixer 或 Easy Coding Standard 统一代码风格。

3. 代码现状可视化

   • 安装并运行 Deptrac：分析代码的依赖关系，识别“上帝类”（God Class）和调用链混乱的地方。
   • 圈复杂度分析：找出最复杂、最值得优先重构的函数。

第二阶段：低风险、高收益的快速胜利（即刻提升可维护性）

这些改动风险极低，效果立竿见影,适合作为改造的起点：

1. 依赖管理现代化

   • 告别手动引入：移除所有 require_once、include_once，全面引入 Composer。
   • 分步走：把老代码放在 src/ 目录下，通过 autoload 的 files 或 classmap 方式加载，然后逐步将类改为 PSR-4 命名空间。
   • 锁定版本：使用 composer.lock,确保环境一致。

2. 消除全局状态与原生函数

   • 将所有的 mysql_* 函数替换为 PDO 或 mysqli（准备升级到ORM）。
   • 将 error_reporting(0) 等开关，替换为统一的错误处理类（Exception Handler）。
   • 检查 global $db、$smarty 等全局变量，开始用依赖注入的思想，通过 setter 或构造函数传入。

3. 引入现代PHP语法（在保持兼容性的前提下）

   • 类型提示：给函数参数和返回值添加 int、string、array、?string 等，PHP 7.0+ 支持标量类型。
   • 严格模式：在每个文件顶部加 declare(strict_types=1);（先从新改写的文件开始）。
   • 合并运算符：$a ?? 'default' 替换 isset($a) ? $a : 'default'。

第三阶段：架构解耦与核心重构（难度升级）

1. 数据库层重构（非常重要）

   • 目标：从原生SQL/ActiveRecord模式，升级到 Repository 模式 + ORM（如 Doctrine/Eloquent）。
   • 步骤：
     1. 为每个核心表创建 *Repository 接口（Interface）。
     2. 实现一个 “老代码适配器”：该适配器内部仍然调用旧的SQL函数,但对外暴露接口。
     3. 编写使用 Eloquent 或 Doctrine 的第二个实现。
     4. 逐步将调用点从旧SQL改为 Repository 接口。
     5. 最终：移除旧SQL实现,只保留ORM实现。

2. 模板引擎现代化

   • 从原生PHP混编（如 <h1><?=$title?></h1>）转向 Twig 或 Blade。
   • 分步：不要一次性改所有模板，先选一个不常维护的模块（如“关于我们”页面），用Twig重写，观察效果,然后推广。

3. 路由与请求处理

   • 目标：告别 $_GET['action'] + switch 模式。
   • 做法：引入一个轻量级的PSR-7/PSR-15兼容的路由器（如 FastRoute，或 Symfony Routing）。
   • 将所有URL映射到 Controller类的方法 上（单个文件不再处理多个路由）。

4. 引入服务层

   • 定义 UserService、OrderService 等。
   • 将控制器中过于复杂的业务逻辑（超过10行）抽离到对应的Service中。

第四阶段：现代化工具与生态

1. PHP版本升级

   • 目标：跳过中间版本，直接升级到当前主流支持的版本（如 8.0/8.1/8.2/8.3）。
   • 工具：使用 Rector（一个自动化代码升级工具），它能自动完成大量语法迁移（如 each() 改为 foreach，<<<EOT 改为 <<<'EOT'）。

2. 现代组件引入

   • 使用 PHP-DI 或易于依赖注入容器。
   • 引入 Monolog 日志系统，替换 error_log()。
   • 引入 PHPdotenv 管理环境变量（.env 文件）。

3. API化暴露业务能力

   • 将旧代码中的核心功能（如“生成报告”、“计算价格”）封装成独立的微服务或 API接口。
   • 旧代码通过HTTP请求调用新服务，而不是直接调用老函数，这是“绞杀者模式”的典型应用。

第五阶段：持续改进与组织保障

1. 技术债务看板：使用 Jira/Trello 等工具，将每次发现的“坏味道”列为Task。
2. 结对编程：安排了解新技术的同事与熟悉老业务的同事一起工作。
3. 设立“重构日”：每两周一个下午，只做重构（不引入新功能）。
4. 监控与告警：重构后，必须观察性能指标（响应时间、错误率）的变化。

避坑指南（血泪教训）

• 不要试图一次性重写：99%的“重写计划”都以失败告终，必须边改边跑。
• 不要手动大规模替换：使用 IDE 的重构功能（重命名、提取方法、提取接口）。
• 让旧代码“认输”：当新代码（如新API）准备就绪后，通过功能开关（Feature Flag）或反向代理 将流量逐渐从旧代码切换到新代码,而不是直接修改旧代码的逻辑。
• 保持小的提交频率：一次只改一件事，如果修改了100个文件,很难排查引入的bug。

一个可执行的年度行动计划

老代码不会一夜之间消失，但通过上述步骤，你的项目会在运行稳定的前提下，逐步变得可维护、可测试、可扩展。