PHP工程师亲述：三年技术栈自动化重构之路

　　去年四月那会儿，老张在工位上摔了键盘——不是真摔，是键盘盖“啪”地合上，声音大得隔壁组都抬头。他盯着屏幕上的测试报告，嘴里念叨：“这破重构，重构了个寂寞。”我凑过去看，报告里红了一片，全是旧代码和新框架的兼容性问题。老张是团队里最坚持“渐进式重构”的，说白了就是缝缝补补，结果缝出个四不像。

　　我原以为“自动化重构”就是写几个脚本跑跑，结果发现根本不是那回事。第一周，我们用Composer把依赖全升了级，结果构建卡在百分之八十七——那数字在屏幕上停了二十分钟，像被按了暂停键。小李蹲在机房里查日志，冷风机的声音嗡嗡响，他回来时头发上全是水珠，说：“是某个小众库的版本冲突，作者三年前就弃坑了。”那天下午，全组人围在白板前，把依赖树画了半面墙，最后用“require-dev”绕过去的。

　　优胜劣汰这事儿，在代码里比自然界还残酷。我们有个十年前的模块，是上一任架构师手写的ORM，用全局变量传参，注释全是中文拼音。重构时，小王试着把它拆成服务层，结果发现它和二十多个老接口耦合，改一个动全身。最后我们咬咬牙，直接用Laravel的Eloquent替换——那模块在测试环境跑了三天，居然没出过一次错。老张当时盯着监控图，说：“这就像把老房子的承重墙拆了，结果发现它根本没承重。”

　　但自动化也不是万能的。有次我们写了个脚本，自动把PHP 5.6的代码转成7.4兼容格式，跑完一看，所有“list($a, $b) = array(1, 2)”都被改成了“[$a, $b] = [1, 2]”，结果老代码里有些地方用的是关联数组，脚本直接给转成了数字索引，线上报了五十多个“Undefined offset”错误。那天下午，全组人蹲在会议室里，对着日志一行行找问题，小李的外卖凉了都没顾上吃。

　　说到小李，他最近在跟测试组吵架。测试组坚持要用Selenium跑UI测试，说“自动化重构必须保证页面逻辑不变”，但Selenium在旧项目里跑得巨慢，一个测试用例要三分钟，全量跑完得两小时。小李写了套PHPUnit的单元测试，覆盖了所有核心逻辑，结果测试组说“单元测试不算数，必须看页面”。那天下午，小李在工位上接了个电话，是测试组主管打来的，他挂了电话后跟我说：“他们说，‘自动化重构不是为了写更少的测试，是为了写更可靠的测试’。”我听了直乐——这话说得没错，但问题是，旧项目的测试用例本来就不可靠啊。

文章配图，仅供参考

　　回到重构。我们花了三个月，把核心模块从原生PHP迁到了Laravel，但有个遗留问题一直没解决：旧系统的缓存用的是Memcached，新系统用的是Redis，数据格式不兼容。小王写了个迁移脚本，结果发现Memcached里存了大量序列化的PHP对象，Redis的序列化方式不一样，解出来全是乱码。最后我们用了个笨办法——在旧系统里加个接口，把缓存数据读出来，转成JSON，再存到Redis里。那接口跑了一周，每天凌晨三点执行，显示器右下角的时间一直没对，因为小王忘了改时区。

　　现在项目算是稳了，但有些细节还是让人后怕。比如，我们重构时没动数据库结构，结果发现旧表的字段类型和Eloquent的模型定义不一致，有些地方用“string”接了“int”，PHP 7.4会报类型错误，但5.6不会。线上跑了一周，突然有个接口报了“TypeError”，查日志发现是某个边缘功能触发了这个隐藏bug。那天全组人加班到十点，小李在工位上边改代码边念叨：“这就像拆炸弹，剪错一根线就全完。”

　　我敢打包票，自动化重构的核心不是工具，是取舍。有些十年前的代码，就像老房子里的旧家具，你舍不得扔，但留着又占地方。最后我们定了条规则：如果一段代码在三个月内没被修改过，且没有单元测试覆盖，重构时就直接删掉——反正线上也没人用。老张当时反对，说“万一以后用到呢”，结果到现在，那些被删的代码，连个报错的都没出现过。

　　现在说回“优胜劣汰”。重构完的项目，维护成本降了六成，新功能开发速度快了三倍。老板最近在考虑把另一个团队也拉过来，学我们的模式。但我知道，这模式不是谁都能复制的——你得有敢删旧代码的勇气，有能写自动化脚本的本事，还得有扛住线上事故的底气。就像老张说的：“重构不是为了证明自己多牛，是为了让代码活得比自己久。”

　　至于未来？我说不准。也许明年我们会用Swoole重构，也许会迁到云原生架构。但有一点我确定：只要业务还在变，代码就得跟着变。自动化重构不是终点，是让代码能跟上变化的起点。下周我们要开始重构支付模块，听说那边有个二十年前的加密函数，是用C写的，通过FFI调用的——这活儿，估计得掉不少头发。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!