AI搭把手，硬啃“屎山”代码那点事儿
最近接了个活儿，挺折腾人。甲方有个共享充电宝的应用，PHP写的，要换个IoT平台。他们自己没PHP的人，这活儿就砸我头上了。
说起PHP，我熟的是20多年前的PHP 4。那会儿用它写写网页，我还自己攒过一个MVC框架玩。现在的PHP 7可不一样了，语法像Java，架构思路又有点Python的影子，挺成熟，用起来也顺手。但问题是，面对这套新家伙和它背后的框架，我基本上就是个小白。好在，咱有AI编程助手Cursor能搭把手。
话是这么说，可拿到代码一看，我还是头皮发麻。代码拢共不到7000行，但那叫一个乱。这哪是换接口啊，简直就是在一座“屎山”里排雷。
一上来就给我个下马威
第一个坎就是开发环境。整个项目的路径，从脚本到日志，全写死在/data/iot这个目录下了。这下好了，我自个儿电脑上根本跑不起来，也就没法调试。咋办？只能“盲改”。在本地改完代码，传到服务器上，再瞪着眼睛看结果。一来一回，效率别提多低了，还特容易搞错。
代码里的“骚操作”也不少
往深了看，代码里各种奇怪的设计就更多了。
比如那个AMQP的消息订阅，放着好好的推送模式不用，非得用pull的方式，每0.001秒就去拉一次。CPU就这么呼呼地空转，也不知道图啥，估计是那个Workerman框架的特殊要求吧。我想把它改成阻塞的，结果服务直接起不来，只能又改了回去。
更逗的是，AMQP收到一条消息，它不直接处理，非要先拐个弯扔到Redis里，再让另一个脚本从Redis里读出来干活。我猜当初这么干，是怕业务逻辑太慢，把AMQP给堵了。可这么一折腾，直接给后面的一个大坑埋下了伏笔。
最头疼的还是解耦
要说最麻烦的，还得是HTTP接口那块。之前写代码那哥们儿，把第三方SDK的pubRequest、pubResponse这些东西直接用在了业务代码里，我数了数，足足35处。这么一来，代码和SDK绑得死死的，想换？门儿都没有。
这时候就体现出和AI合作的妙处了。Cursor这“小伙子”一开始挺楞，想直接一波流，在35个地方强行替换。我一看，这风险也太大了，万一哪儿没改对，查都没法查。我就跟它说：“咱们得这么干，自己先写两个同名的接口对象类，把原来那些方法包起来，然后一个一个地换，这样修改最小、最稳。” 它还挺聪明，马上就懂了我的意思，刷刷刷地就帮我把活儿干了。这么一来，总算是把业务和SDK给分开了。
按下葫芦浮起瓢
接口换完，代码也理顺了些，一测试，新问题又冒出来了。
先是发现指令发出去了，数据库里却没日志。查了半天，才发现是一个叫insertCommandLog的方法，因为命名空间的问题，根本就没被调用到，这在第一轮修改时给漏了。
行，把日志问题搞定。一转头，又发现设备回的消息，数据库里莫名其妙记了两条，时间就差一秒。这可把我折腾坏了。最后才定位到，就是那个“AMQP -> Redis”的骚操作惹的祸。因为这个绕来绕去的流程，一条消息被两个不同的地方给重复处理了。
最后唠叨几句
说实话，换在以前，这种“屎山”代码我瞅一眼都头大，打心底里不想碰。现在有AI在旁边搭把手，心里确实有底了，也敢去啃这种硬骨头了。我估摸着，再过一阵子，等这些大模型的记性（上下文窗口）再好点儿，干这种改代码的活儿会更顺手，到时候就真是咱们手里的神兵利器了。
所以说，AI会不会干掉程序员还不好讲，但你要是不用AI，那肯定先被会用AI的同行给挤兑得没活儿干。这是肯定的。
AI搭把手，硬啃“屎山”代码那点事儿
最近接了个活儿，挺折腾人。甲方有个共享充电宝的应用，PHP写的，要换个IoT平台。他们自己没PHP的人，这活儿就砸我头上了。
说起PHP，我熟的是20多年前的PHP 4。那会儿用它写写网页，我还自己攒过一个MVC框架玩。现在的PHP 7可不一样了，语法像Java，架构思路又有点Python的影子，挺成熟，用起来也顺手。但问题是，面对这套新家伙和它背后的框架，我基本上就是个小白。好在，咱有AI编程助手Cursor能搭把手。
话是这么说，可拿到代码一看，我还是头皮发麻。代码拢共不到7000行，但那叫一个乱。这哪是换接口啊，简直就是在一座“屎山”里排雷。
一上来就给我个下马威
第一个坎就是开发环境。整个项目的路径，从脚本到日志，全写死在
/data/iot这个目录下了。这下好了，我自个儿电脑上根本跑不起来，也就没法调试。咋办？只能“盲改”。在本地改完代码，传到服务器上，再瞪着眼睛看结果。一来一回，效率别提多低了，还特容易搞错。代码里的“骚操作”也不少
往深了看，代码里各种奇怪的设计就更多了。
比如那个AMQP的消息订阅，放着好好的推送模式不用，非得用
pull的方式，每0.001秒就去拉一次。CPU就这么呼呼地空转，也不知道图啥，估计是那个Workerman框架的特殊要求吧。我想把它改成阻塞的，结果服务直接起不来，只能又改了回去。更逗的是，AMQP收到一条消息，它不直接处理，非要先拐个弯扔到Redis里，再让另一个脚本从Redis里读出来干活。我猜当初这么干，是怕业务逻辑太慢，把AMQP给堵了。可这么一折腾，直接给后面的一个大坑埋下了伏笔。
最头疼的还是解耦
要说最麻烦的，还得是HTTP接口那块。之前写代码那哥们儿，把第三方SDK的
pubRequest、pubResponse这些东西直接用在了业务代码里，我数了数，足足35处。这么一来，代码和SDK绑得死死的，想换？门儿都没有。这时候就体现出和AI合作的妙处了。Cursor这“小伙子”一开始挺楞，想直接一波流，在35个地方强行替换。我一看，这风险也太大了，万一哪儿没改对，查都没法查。我就跟它说：“咱们得这么干，自己先写两个同名的接口对象类，把原来那些方法包起来，然后一个一个地换，这样修改最小、最稳。” 它还挺聪明，马上就懂了我的意思，刷刷刷地就帮我把活儿干了。这么一来，总算是把业务和SDK给分开了。
按下葫芦浮起瓢
接口换完，代码也理顺了些，一测试，新问题又冒出来了。
先是发现指令发出去了，数据库里却没日志。查了半天，才发现是一个叫
insertCommandLog的方法，因为命名空间的问题，根本就没被调用到，这在第一轮修改时给漏了。行，把日志问题搞定。一转头，又发现设备回的消息，数据库里莫名其妙记了两条，时间就差一秒。这可把我折腾坏了。最后才定位到，就是那个“AMQP -> Redis”的骚操作惹的祸。因为这个绕来绕去的流程，一条消息被两个不同的地方给重复处理了。
最后唠叨几句
说实话，换在以前，这种“屎山”代码我瞅一眼都头大，打心底里不想碰。现在有AI在旁边搭把手，心里确实有底了，也敢去啃这种硬骨头了。我估摸着，再过一阵子，等这些大模型的记性（上下文窗口）再好点儿，干这种改代码的活儿会更顺手，到时候就真是咱们手里的神兵利器了。
所以说，AI会不会干掉程序员还不好讲，但你要是不用AI，那肯定先被会用AI的同行给挤兑得没活儿干。这是肯定的。