接手一个5年前的PHP项目，我踩的坑和学到的教训

第一天：跑都跑不起来

去年公司接了一个二手项目维护，5年前的Laravel 5.2项目，PHP版本锁在5.6。我拿到代码的第一天，在本机搭环境就花了一整天。composer install报了一堆依赖冲突，因为有几个包在Packagist上已经下架了。最后是在GitHub上找到那些包的fork版本，手动改composer.json指向fork仓库才装上。当时我就意识到，这项目的坑会比预想的多得多。

代码质量：没有最差只有更差

花了一周读代码，越读越崩溃。控制器里直接写SQL，还是拼接的，没有任何参数绑定。Model里没有relation，全用手动join。视图文件里有数据库查询。有个订单处理的逻辑散落在四个不同的文件里，没有任何注释。最离谱的是一个支付回调接口，成功和失败的处理写在一起，靠一个if判断区分。后来发现线上跑了一年多，这个判断条件是反的——支付成功的订单被标记为失败，客服手动处理的。我的教训是：别一上来就想重构。你根本不了解业务逻辑，也不知道哪些看起来蠢的代码其实是在修某个历史bug。先加测试，哪怕只测核心流程，有了安全网再动手。

数据库的惊喜

跑了一遍数据库，发现user表有四个看起来差不多的邮箱字段：email、user_email、contact_email、login_email。查了代码发现不同的注册入口填了不同的字段，而且没有一个索引。更头疼的是没有migration文件，数据库结构是手动改的，本地和生产已经不一致了。我在本地跑测试没问题，上生产直接崩了三次。花了两周把数据库结构整理成migration，把数据合并到统一字段。这个过程必须在线做，不能停服。写了好几个批处理脚本，凌晨两点跑，每次处理五千条，跑了四天才把几百万用户数据迁完。

最大的收获不是技术

接老项目最重要的不是技术能力，是耐心和做事顺序。别看到屎山就想推平重建——先理解业务、加测试覆盖、小步重构、逐步上线。还有就是文档一定要补。我花了一周写了份部署文档和架构说明，后来新同事入职两天就能上手了。如果你也在接手老项目，记住一句话：活着的东西，哪怕再丑，也有它活着的理由。先搞清楚为什么活着，再决定怎么让它活得更好。

标签： 经验分享 PHP开发 项目维护 代码重构