对于 PHP 老项目续命的思考

[zjsxwc]

比如 ecshop ( https://github.com/shopex/ecshop), 这种 每个 php 文件直接对应一个 url 地址, 依赖完全靠魔法全局变量传递, 不使用面向对象方式组织代码

这种老项目的特点是大部分时候都只是做 sql 手动拼接与简单 html 渲染; 代码里变量以 associative array 为主; 业务处理会混淆在 sql 与 php 代码之间; 规模一般不会太大, 一旦大了依赖复杂就玩崩, 最后难以维护, 所有续命必须要做的第一步就是把依赖关系理清, 然后才能使用我们熟悉的依赖注入容器等手段.

如何续命:

1. 原有的老代码保持原样, 不需要去改动

2. 从数据库表生成领域实体面向对象的 PHP 文件(比如用 symfony 的 doctrine orm 相关命令工具)

3. 业务分为老业务与新业务. 由于老业务代码不能改动, 我们需要通过写个代码转换器, 把老代码的每个 PHP 文件, 转换到新的面向对象的 PHP 类里面, 这样新老业务都是基于面向对象了. 这个代码转换器, 关键是要能够识别出老代码里使用的魔法全局变量, 把魔法全局变量写到生成类的构造函数里, 并替换老代码的魔法全局变量, 为类的属性, 以及把老代码里 function 改为类的 method, 实现把依赖都抽为类之间的依赖

4. 之后新老业务就可以通过依赖注入容器来相互调用了.

[sunsh2017]

什么狗屁东西

[ORZRRR]

@sunsh2017 楼主教你怎么续命呢

[sunding0308]

@sunsh2017 楼主教你怎么续命呢

[Moker]

现在就在维护类似的项目 太惨了

[chairuosen]

要插一个第 0 步，写测试

[picone]

改不动的，ecshop 2.7 一堆旧的写法，用 php5.6 跑一堆 notice。
除此之外还有页面渲染的链接，等等，太多要改了，没必要续命。

[sytnishizuiai]

牛，当初下个官网的 ecshop，全是 notice，改了我好久才能用，而且后续还会是不是出现

[mlkr]

还不如重新来过

[pqee]

5. 离职

我说真的。

[tongz]

续命？魔法？

[akira]

基本上整体重做会更快

[askfilm]

赞一个，虽然说的太笼统

[litter123]

@tongz 不不不，是膜法

[lsido]

掐死重生吧

[qianmeng]

想办法一点一点改造然后替换吧，否则很痛苦的

[onion83]

了解业务流程，搞清楚数据库结构和存储逻辑，兼容 URL，慢慢做切换流量。

老代码通常有历史包袱，跟着旧的思路很容易陷进去。