PHP重构

重构，一个熟悉又陌生的词汇。
很早就有了。也有相关的专业书籍。

为什么还是很少看到招聘信息上特别要求呢？

因为，重构的前提，是一套完整的、完善的，正常运行中的产品。

很多正常运行中的产品，出现问题，第一时间考虑的是修改bug，而不是重构。

更多的产品，是挨不到重构那一天，就已经停止了。

因此，需要重构的场景和产品，不多。甚至可以说很少。

其次，重构的过程。需要有真正重构经验的人来推进。

很多人对重构的理解是非常浅层的。
比如：重构所花费的时间。
很多人感叹没有时间重构。却不知道，重构是可以随时开始、随时结束的。随时的意思，就是小于五分钟。

很多人错误的把重写架构，或者重写代码，或者重换框架，理解成了重构。
这样的理解，不一定说是错误的，但可以说是不太贴切的。

这也造成了重构成功的案例，并不多。
很多时候，都是拖延到一定时候，要么全部重写。要么改换语言。

而PHP重构，更是难上加难。

因为PHP动态语言的特性，类的属性，或者变量的类型可以经常变化。导致更加难以重构。

但这并不是开发语言的问题，一般都是因为业务逻辑与框架混淆造成的。
比如：接口的传参是一段json，而json中有的是字符、有的是数字。于是开放接口后，很容易出错。

实际上，这里的接口传参，就混淆了业务逻辑中的变量，以及框架中的传递变量的方式。

当然，更多的PHP产品，是倒在了重构前。

能通过PHP的短平快开发，获得一定成绩的产品。
更有必要早考虑重构，早实施重构。

而现实是，要么一直拖延问题，最后爆发的，造成产品失败，又或者是全面推翻，造成之前积累的经验和技术团队全部浪费。

那么采用PHP的产品应该怎样进行重构呢？

一、先使用跟踪工具，埋点跟踪已有的函数、接口。
这样才好定位瓶颈。

二、确认瓶颈后，针对瓶颈相关的函数、接口。
进行针对数据库执行sql的排查。
一般是需要查看mysql的所有日志。

三、优化mysql，增加缓存。
缓存可以采用redis。

四、针对关键接口，进行压测。
可以采用wrk等压测工具。

五、与原有接口，进行并行运行。
对比差异，并保证接口业务逻辑正确。

六、本次重构完成。

当然，这只是很初步的一个流程。
之后，就是不断的迭代循环。

重构相关的东西还是比较多的。
不断的学习、实践和积累。