关于项目重构 怎么避免再次陷入shi山 重蹈覆辙？
老板嫌弃项目太笨重，开发效率低 订单啥的查询太慢
项目开发人员换过很多波 导致项目逻辑太臃肿（对，就是屎山）
开发改个功能很费劲
表结构都是你增几个 他加几个 导致表很大 订单表 商品表 等等
感觉老板都快不想干了 一直赔钱 现在开发成本太高
感觉快要滚蛋了
公司这个项目经历也挺喜人：
开始老板找的外包开发的第一版
因为需求改动频繁 经常跟外包吵架 闹得很不爽
后来这套系统被黑 ， 数据库被锁了 ，老板没给钱 ，
老板开始自己招人重新开发 ，
开发这个项目前后换了三四波人
我是最后一波人
最后关于重构有什么好的建议 感谢
关于 LearnKu
粤公网安备 44030502004330号
没有办法，业务经常变更就会变为屎山，因为会折磨程序员，除非代码审计很严格，否则变屎山会更快。
早点跑路吧
几乎无解，业务变更是屎山的重要来源。最优解是随便写，快速实现就行
这没啥招，不过你可以进行防御性编程，让别人看不懂你写的代码，这样老板就不会轻易开掉你了哈哈。
按照面向对象编程方法，合理的对功能模块进行拆解和设计， 处理好各个模块的版本依赖关系，确保单个的功能模块更新不会影响整个系统的稳定性。 然后做好版本控制，新需求进来时安排好版本更新计划，保证系统的更新迭代可控。这样就能解决软件随着规模的发展产生的无法维护问题。
这就好比中了毒箭一样，拔了，马上死，不拔，慢慢死。唯一能活下来的机会，就是赶紧先找解药，有了解药再考虑箭头拔不拔的问题。用《投名状》里陈大人对庞青云说的一句话来总结，就是：「要想有所作为，庞大人，你得好好活着，好好活着。」
鄙人不才，接手过好几个这种项目，简答来说就是： 1、原有系统保持正常运行不动 2、使用laravel新开项目，还是连原来的数据库 3、梳理好原来的业务，慢慢重构，做好一个接口，切一个接口 4、经过1-2年老的系统慢慢下线
用 dcat-plus admin重构吧，把数据表结构导进去，一键生成后台curd , 接口(管理端，用户端，商家端)，接口文档(管理端，用户端，商家端)
优势：数据表 ->（后台管理，接口，接口文档 ）-> AI开发前端( 把前端截图,接口响应的数据结构给AI, 自动完成前端页面和数据渲染)分批次把功能移出。
工资给够，让前端，后端，产品岗位的人一直不离职。可以减少屎山。只把关注点留在后端岗位，实现不了的。
合理运用设计模式去解耦（像工厂模式加观察者模式这种是很好处理这些订单流什么的），抽象公共处理逻辑，按不同逻辑去拆分类
重构不是推倒重建，而是局部不断迭代升级，凤凰架构里面说的，流水不腐，架构的迭代要像流水一样，不断的小步快跑，对腐败的地方不断的迭代更新，不要指望有一劳永逸的架构，软件工程没有银弹
重构=新屎山～
见过一个方法1000行的if-else嘛～ 正好家里有事，扭头就跑（建议重构过，不同意，后来听说重构了，重构后 用不了多久还会是屎山）
小范围重构，一个功能一个功能的重构，重构一个上线一个，最重要的是 review 代码