一、本人踩坑记录
作为一个小电商的主程，主要使用Java语言，花了大概5个月的时间完成项目重构，业务逻辑不算很复杂，但还是踩了相当多的雷，在此记录一下，希望大家能引以为戒
1.1. DDD装逼失败
DDD领域模型很帅，想把新技术用在项目上，一个是可以装逼，再者可以摸透DDD领域模型，然而事与愿违，本身就对DDD不熟悉，花大量时间使用结果运行不起来，可能业务不适合或者本人技术不行，总之夭折了，我对DDD新的理解是"低调点"
1.2 一口吃不成胖子
重构内容很多，本人觉得自己技术还行，想一把梭哈，在短时间内遇到大量问题后，改为稳扎稳扎，你以为大刀阔斧的改代码拉轰，实际上原本的代码不规范之处有很多隐藏的雷，还有就是别把自己的技术想的过于强大
1.3 代码和人有一个能跑就行
3.代码可能永远达不到你想象中那么优雅，因为业务往往非常零散，开发以业务为主，而不是技术，所以我怎么改都觉得不好看，最后放弃折腾了， 人和代码有一个能跑就行，一般的小项目侧重于交付和使用，效率和优雅往往会被忽略，别太拉就行了，优雅没人看
二、重构建议
2.1.明确重构目标
重构的内容有哪些？
业务重构、技术重构、新增功能、旧数据迁移？
确认重构目标，明确以及每个阶段要交付的内容，根据紧要程度排期，切勿一股脑一起做，容易出现大量问题，重复改代码
2.2 确定重构顺序
重构按什么顺序排才能少走弯路？
切忌大刀阔斧的重构，每次重构一些就自测，《重构》这本书讲到：大刀阔斧的重构是新手美好的期望，老手选择稳扎稳打，循序渐进的方式
我个人推荐的重构顺序：先写好重构设计文档，让大局了然于胸，大部分的开发都不擅长写文档，觉得费事不如直接干，写文档其实是个整理思绪的过程，像重构如此庞大的工作量，不写好规划文档显然是不行的，也不好给项目交待（主要是领导）
代码初步调整
1.代码结构调整
2.规范命名，消除魔法值，合并函数
业务重构
1.设计表结构，务必考虑业务重构后旧数据兼容问题
2.业务影响估算，根据模块修改代码
数据兼容
1.设置表字段标志位，可以用程序+sql脚本的方式跑数据
2.一定要做好脚本的记录，因为会多次调试，反复跑数据
3.重构启动新服务前做好数据备份
PS：以上每一步完成之后，都要经过测试才走下一步，以保证没有修改错误
三、可能出现的问题以及如何解决
3.1 分支管理
大家都懂但我还是提一下，重构时间较久中途可能出现当前版本临时增加功能，修复bug等问题，规范分支管理，不要手忙脚乱
3.2 数据库管理
重构后的数据库肯定要跟当前库区分开的，想必没人放在同一个库操作
3.3 业务更改造成的问题
详细记录好业务更改前后不一致的地方，比如业务设定等等，新增或删除表，表字段更改也做好记录。同步数据一定要检查数据是否有遗漏，业务含义是否一致
一时半会儿就想到这些，快下班了，大家可以评论区补充一些
