大家是如何重构已有项目的？怎么进行新的代码/架构设计？

[shinelamla]

马上要重构一个项目，但是涉及的点和业务方都不少，一时间不知道从哪里下手和规划。大佬们有什么重构的经验或者相关的书籍可以分享一下？也是可以代码技巧，代码设计，架构设计方面的分享对我也很重要！！

[HyperionX]

操作角度：重写子模块，切流，把旧模块饿死后下线。
子模块划分：简单业务后台，调用依赖低于两位数的按业务拆分就行，复杂系统按 DDD 思想基于领域拆好界限上下文，可以参考这个系列文章 https://tkstorm.com/2021/07/%E9%A1%B9%E7%9B%AE%E5%AE%9E%E8%B7%B5ddd%E5%90%8E%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%80%83/。项目结构组织按照顺手得来，不必非要照抄，数据格式转来转去徒增工作量，保持高内聚低耦合的代码设计思想，找个技术好的单兵做好通用 sdk 开发。
项目进度把控方面：不建议成立技术专项试图一次花半年全改，这样很难体现你的收益。列好要改的点，每次业务变更的时候多留点 buffer 做重构，做好里程碑奖励和组织激励工作。
最后推荐阅读《凤凰架构》，再好的架构最终都会腐化。接受会腐化的事实，做好防范工作（代码合入审查），保持组织人员流动健康和业务正常推进（不要 996push ），持续重构和优化。

[tianmalj0613]

1. 方法支持：
C4 架构、设计模式（比如服务适配、绞杀、CQRS 等）
2. 书籍参考
《重构 改善既有代码的设计》、《代码整洁之道》
3. 重构的工具和支持
最好项目有完善的冒烟用例和单元测试，如果有自动化用例，那就大胆重构。以便确定修改后的项目是符合原有的需求的
4. java 项目的代码质量检查工具
pmd 、checkstyle

[luzemin]

说下个人理解
1.梳理清楚原有业务
2.厘清原有实现和调用关系
3.从相对独立/简单/边缘功能的模块开始重构
4.基于现有业务和未来一段时间的预测，找出变化点，重构就是针对变化点进行重新设计实现，目标就是隔离变化，不变的部分甚至可以不用重构
5.朝着“可测试”的方向重构，起码自己重构的代码，写单元测试的时候不能骂人吧
6.反馈的时候不要说工作是“在重构”，要说重构了什么，带来了什么好处。不然这东西不好量化

[jones2000]

为什么要重构， 不要为了重构而重构。 先列出来重构的理由。然后一个一个解决。

[fewspider]

可以从这几方面入手：
1 、解耦，尽量做到只有数据的交互，没有业务的参杂
2 、重复功能封装
3 、多余代码精简，包括注释，该删的删，该补充的补充
4 、单元测试，方便验收，也方便后续维护

[MozzieW]

不知道从哪里下手、规划--》没有重构需求，不需要重构

知道从哪里下手，要解决什么问题--〉针对问题考虑代码设计、架构

[mydingyan]

我们公司的项目从 net 转到 java 重构了 1 年，全功能回归了 6 轮，比较苦逼

与预期不一样的是，原本想着功能分模块分批上限，最后 token 不能整两套而一次上线的

[murmur]

先把需求分析重做了，然后再谈架构问题

[shinelamla]

@HyperionX 凤凰架构这本书买了！准备先看看 《重构 改善既有代码的设计》

[shinelamla]

@luzemin 很有帮助

[shinelamla]

@jones2000 已经梳理出 30+优化项，重构有时候就是太多旧逻辑随着版本迭代而堆积，已经不适用

[shinelamla]

@murmur 需求分析重做也是个方向，架构基本上是沿用现在的，重构着重是代码逻辑的重构

[Chad0000]

我也在重构公司的屎山系统，我是这么搞的：
- 先抛出一个概念：独立服务/模块。即服务/模块不依赖于任何其他服务/模块。
- 然后通过设计保证这些服务/模块可以在任何地方运行（包括控制台里）
- 然后慢慢将屎山系统的代码迁移到一个个独立的服务/模块中，迁移完之前可以在旧系统继续调用新服务/模块
- 最终铲平屎山

[crazyTanuki]

用微服务概念,把服务一个个抽象出来,再慢慢重构

[lsk569937453]

如果非得重构一个屎山项目，其实还是很有风险的。

我们当时是完全接手一个老项目(.Net)，经常出问题，老大拍板决定重构(用 java 重构)。
我们组每个人都领一个子模块，同时还有 2 个核心模块的代码。每天就是读源代码，然后开会代码反讲。
对于不懂的地方，直接加日志，看下生产环境具体的值。

重构的顺序: 当时是经常出问题嘛，我们就定位到问题，优先重构有问题的模块。
验证: 当时是用流量回放进行验证的，每天都进行流量回放，验证了 7 天吧。

[stiangao]

重构过 n 个项目，其中一个超大项目，过来告诉你，不要重构 😂😂😂

[wangYQ]

能跑着就不要重构，除非必要。除非性能，功能实在没法满足得重构再说，要不然，看屎山代码确实脑袋疼，有得还没有文档传承，有得人都走了，问都没处问

[shinelamla]

@lsk569937453 流量回放也是我没考虑到的

[shinelamla]

@wangYQ 我现在就是有着这样的问题...文档过时，注释基本没有，有些业务类型已经不用了但是还是在，有些产品走了新产品上来又推翻，函数里面堆积了一大堆的逻辑最终演变成接近 1000 行的大函数

[shinelamla]

@Chad0000 总的来说，就是抽象隔离成独立的服务模块，互相先不影响，有点像#14 说的微服务概念，谢谢啦！