关于项目重构 怎么避免再次陷入shi山 重蹈覆辙？

没有办法，业务经常变更就会变为屎山，因为会折磨程序员，除非代码审计很严格，否则变屎山会更快。

早点跑路吧

几乎无解，业务变更是屎山的重要来源。最优解是随便写，快速实现就行

这没啥招，不过你可以进行防御性编程，让别人看不懂你写的代码，这样老板就不会轻易开掉你了哈哈。

按照面向对象编程方法，合理的对功能模块进行拆解和设计， 处理好各个模块的版本依赖关系，确保单个的功能模块更新不会影响整个系统的稳定性。 然后做好版本控制，新需求进来时安排好版本更新计划，保证系统的更新迭代可控。这样就能解决软件随着规模的发展产生的无法维护问题。

这就好比中了毒箭一样，拔了，马上死，不拔，慢慢死。唯一能活下来的机会，就是赶紧先找解药，有了解药再考虑箭头拔不拔的问题。用《投名状》里陈大人对庞青云说的一句话来总结，就是：「要想有所作为，庞大人，你得好好活着，好好活着。」

鄙人不才，接手过好几个这种项目，简答来说就是： 1、原有系统保持正常运行不动 2、使用laravel新开项目，还是连原来的数据库 3、梳理好原来的业务，慢慢重构，做好一个接口，切一个接口 4、经过1-2年老的系统慢慢下线

用 dcat-plus admin重构吧，把数据表结构导进去，一键生成后台curd , 接口(管理端，用户端，商家端)，接口文档(管理端，用户端，商家端)

优势：数据表 ->（后台管理，接口，接口文档 ）-> AI开发前端( 把前端截图,接口响应的数据结构给AI, 自动完成前端页面和数据渲染)

分批次把功能移出。

工资给够，让前端，后端，产品岗位的人一直不离职。可以减少屎山。只把关注点留在后端岗位，实现不了的。

合理运用设计模式去解耦（像工厂模式加观察者模式这种是很好处理这些订单流什么的），抽象公共处理逻辑，按不同逻辑去拆分类

重构不是推倒重建，而是局部不断迭代升级，凤凰架构里面说的，流水不腐，架构的迭代要像流水一样，不断的小步快跑，对腐败的地方不断的迭代更新，不要指望有一劳永逸的架构，软件工程没有银弹

• 自建数据库还是云数据库？
  • 如果是自建数据库的话，可以考虑改成云数据库，先买个高配1个月做个迁移，没多少钱，弄个测试环境，连云数据库后观察效果。大概率是能提升耗时的。
    • 算是速度最快的解决方式。有这1个月时间，再一个接口一个接口的优化，一个表一个表的优化，一个查询一个查询的优化。