业务耦合性高，基本就是一坨屎，而且还是国内不入流的技术栈 c#, 现在要想重构，先从数据库迁移开始，之前没干过迁移这种事情， 这事情难度大吗，现在基本就让 AI 搞，也不知道最终会不会搞好。
人和库有一个能跑就行
人和库有一个能跑就行
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Supplement 1 · 23h 40m ago
另外说明一下背景：
本人之前干前端的，简历上也基本都是写前端项目，只有一个简单的的后端项目，
对 mysql 也基本停留在简单的 curd 上面，
这个 cto 每次问他问题都说让我掌控这个项目，说什么对我技术能力认可的，我 tm 才刚入职 2 月而已。
本人之前干前端的，简历上也基本都是写前端项目，只有一个简单的的后端项目，
对 mysql 也基本停留在简单的 curd 上面，
这个 cto 每次问他问题都说让我掌控这个项目，说什么对我技术能力认可的，我 tm 才刚入职 2 月而已。
Supplement 2 · 19h 15m ago
另外说一句，目前我只负责一块业务的解耦吧算是，20 个表，然后表里面有一些服务需要拆分的，通过 api 调用方式来交互，但是我心里也没底。虽然用 AI 已经迁移了表，但是各种服务要拆分出来，主要是心里没底
 |
101
IMengXin 7h 11m ago
同 C# ，同迁移数据库，最早是 SQLServer 迁移到 MySQL,屎山代码里全是拼接的 SQL 语句或者调用的存储过程，改成用 SqlSugar,基本完成，然后！老板不知道哪看来的人大金仓 SQLServer 版 + 国企要求信创，再次迁移到人大金仓 SQLServer 版 ，这才是痛苦的一匹
|
 |
102
JamesMackerel 7h 9m ago
除了设计复杂业务的高并发分布式场景的系统之外，最难的不就是重构和迁移了吗。
sql server + c-sharp 有啥不好的，是突然业务量要扩大几十倍吗，如果是那样的话重构还算合理，但是如果是有那么大的扩展，为什么资金投不到人力上来，就得你一个人干？ |
 |
103
mooyo 7h 7m ago
不大，但是比较繁琐。看你们要在线迁还是可以停机迁了。
之前在线迁过几张亿级的表 没啥问题。 |
 |
104
Felldeadbird 6h 58m ago
巨大。就算 ORM 加持，有一些特殊 SQL 你不知道有什么坑在里面。一不小心就炸了。
|
 |
105
tangmanger 6h 56m ago
本人之前干前端的，简历上也基本都是写前端项目，只有一个简单的的后端项目，
对 mysql 也基本停留在简单的 curd 上面， 建议别动如果 c#的完全用的 EFCore 迁移还行 单基于你后端经验一般情况下 别动框架 别动数据 |
 |
106
zgsi 6h 55m ago
重构不如重做
最麻烦的是数据库 |
 |
107
heftyMan 6h 55m ago
生产谁爱迁移谁迁。测试想咋迁就咋迁
|
 |
108
chandleryou 6h 53m ago
真 vibe 出来后，能用没问题皆大欢喜，一旦问题一段时间解决不掉 -> 大概率背锅 -> cto 以此为理由扩充后端团队
|
 |
109
chtcrack 6h 52m ago
怎么感觉这个 cto 是想找你背锅的啊?
|
 |
110
SchwarzeR 6h 52m ago
先把业务吃透了、把单元测试都补齐了再说
给个半瓶子水的后端纯做数据库迁移都能把主键索引迁没的，高风险还费力不讨好 |
 |
111
zh3256 6h 51m ago via Android
不用原地迁移，新建服务重写 API ，写完一个迁一个。各个地方多打点日志，没事观察一下，老项目其实很多功能是没用到的，没有日志就干掉。
数据库没到瓶颈没必要迁，强迫症作祟。 |
 |
112
dog82 6h 48m ago
要看系统复杂度，如果写了函数或过程，比较麻烦。
|
 |
113
zjcolvin 6h 45m ago
cto 不像正儿八经的人类，你也不要正儿八经的弄，评论区已经有很多人说这个事情有多难了，但是我觉得你拿来练手混项目经验没问题，只要不用担责和赔款就放心弄；但如果不是这样只推荐跑路
|
|
114
zjcolvin 6h 44m ago
哦对了，ai 润色过的：
不要把 CTO 当成一个成熟、规范的管理者来看待。这个项目本身难度和风险可能都不低，评论区也已经有人分析过了。如果只是把它当成练手、积累项目经验的机会，而且出了问题不用你承担责任或赔偿，那可以大胆尝试；但如果需要你背锅、承担风险，那更建议尽早离开。 |
 |
115
hjw45611 6h 40m ago
AI ？你信 AI ？？
老板让我们重构一个项目，说用 AI 一个月搞定，结果本来后端一个人，用 AI 弄了两周天天加班实在时间不够，后来加了两个人，AI 用了快一千刀，还超期完成 |
 |
116
Xwang 6h 39m ago
数据迁移和程序重构分开做，不要一起做
|
 |
117
horacegao 6h 38m ago
ai 迁数据库肯定出问题，老司机才能搞定的事情
|
 |
118
ElmerZhang 6h 37m ago
看你什么数据规模，数据越少风险越小。
曾经重构过公司核心数据库，峰值 qps 上万，所有表加起来百亿数据量，折腾了两三个月才重构完。 |
 |
119
ningxing 6h 28m ago
让 AI 参考你现在代码，重新设计一套，别改以前代码，不然肯定会炸，特别是自己不懂的话。让 AI 重新写也别指望一次性全部搞定，长时间或者一次性 AI 写出来的也是一坨屎，只有慢慢一个一个单功能完成人工校验没问题再继续下一个。
|
 |
120
whisper1225 6h 26m ago
@wangritian 大部分都是从 DB 迁移开始，CDC 同步，然后读灰度，然后写灰度，最终完全迁移
|
 |
121
tt67wq 6h 24m ago
换 DB 自古以来就是难题，要是业务不接受停机的话更难
|
|
122
whisper1225 6h 23m ago
@chutianyao 存量数据同步之后是不是要有个新存储读灰度
|
|
123
whisper1225 6h 21m ago
@qiaoqiao881100 其实搞搞挺好的，拿公司的资源练自己的手。当然如果啥资源都不给你，那就尬了
|
 |
124
qiaoqiao881100 OP 看评论学到不少知识
|
 |
125
Torpedo 6h 20m ago
@liuzhedash #2 虽然没搞过，但是见过很多次。都是双写，完善之后逐步切流
|
|
126
qiaoqiao881100 OP @whisper1225 说的对， 拿来练手涨经验，干不干的成都有收货应该是
|
 |
127
wengjin456123 6h 15m ago
ai 搞 数据库容易炸，不炸的前提是你特别懂
|
 |
128
esee 6h 13m ago via Android
重构是工作最多最繁琐，也是最没有收益的事情，我自己写的项目我自己去重构都很痛苦，能推就推了吧
|
 |
129
JiafuYuan 6h 11m ago
@qiaoqiao881100 #43 大厂出来的就喜欢搞这一套,技术能力没有,吹牛甩锅能力第一名,疯狂贬低老系统,给老板画饼,骗老板几个月跑路
|
 |
130
brazz 6h 6m ago
做过重构，建议分批重构，也要了解清楚 源数据库和新类型数据库的差异。按照业务批次分批迁移重构掉，不建议一步到位，也得配合代码同时进行，有很多业务是 历史毒瘤，可能不是因为你重构引起的也会归到你这边来，总之，任重道远
|
 |
131
liuzhedash 6h 6m ago
说双写的稳定以后切流的，这种只适用于重构期间不会做任何修改的系统，但是这样的系统本身也没有被重构的价值。
|
|
132
JiafuYuan 6h 3m ago
@JamesMackerel 肯定是领导给老板许了承诺,想证明自己,但自己没那个能力
|
 |
133
liqiuqiu 5h 58m ago
入职 2 个月你就敢背这么大口锅，况且你还是前端，胆子挺大啊
|
|
134
qiaoqiao881100 OP @liqiuqiu 不是我背锅，是现在他就给我派这个活，产品那压了半年的需求都还没做呢，没办法咯
|
 |
135
z1154505909 5h 29m ago
难度巨大无比，我以前维护一个 c#的站点，加功能都是用 python 拦截请求来实现，简直 mmp
|
 |
137
wtml 5h 5m ago
你们老板心真大，这么重大的重构不找个专业的直接让前端全权负责
|
 |
138
daqingzi 5h 4m ago
同种数据库迁移都需要经过各种测试，包炸的，有 ai 也包炸
|
 |
139
zhangli2946 4h 54m ago
0. 沟通重构要求 -> 确认重构原则\确认重构目标
1. 建立重构计划,明确里程碑目标 -> 向上管理用 2. 建立请求网关 -> 请求流量复制和响应内容比较\未来流量控制 3. 梳理现存业务 -> 沟通并识别原系统中的技术债务\明确现存数据模型\匹配迁移重构的附加要求 |
 |
140
NeoWalnut 4h 51m ago
重构火葬场
|
 |
141
aidchow 4h 50m ago
宁愿写胶水层，也不要迁移数据库，就没遇到过不炸的
|
 |
142
malusama 4h 45m ago
迁移后他妈以前的数据 bug 或者各种问题都是你的锅， 过去的问题也不会承认的
|
 |
143
chneqi 4h 3m ago
我赞同能跑不要动，改就是坑。但是，有人愿意付费给时间给你机会那 ai 练手这可是大好事啊，怎么会想着跑路
|
 |
144
qingyingwan 2h 55m ago via Android
我预测你半年到一年就会跑路，好好珍惜这段时间掌握他们的系统架构，做的事情哪些能写到简历上去。
|
 |
145
SenseHu 2h 52m ago
后端多少人啊, 听起来像要搞微服务? 那我只能说祝你们好运, 我们被坑惨了, 现在单体一把梭问题少多了
|
 |
146
seenthewind 2h 41m ago
迁移重构数据库比重新做难 10 倍不止，如果还要叠加新的业务功能，那么基本上等同于在找死。
为什么我这么清楚。。。因为我干过。。。反正所有数据，包括库从一个库拆 7 个库，实时和历史全部分层解耦合。 具体量化一下难到什么程度，这么说吧，当时我带 5 、6 个人干这个事情，干到最后人全跑了，只有我留下来，后面重新汇报，重新安排工作，再一次划分负责和范围，第二次搞的时候基本上把数据重构+解耦+新业务设计所有工作拆分到大概 100 人的团队中。 最终当然是顺利搞完了，要说收获嘛，有了点经验而已，后续的工作或者发展中，并不会有多少人记得当时发生了多大的事情，当时遇到了多大的困难。 |
 |
147
zzzzCore 2h 6m ago
做过从 sql server 迁移到 mongodb ，当然，项目规模并不大，3 个人做了一个多月。
具体做起来，就是从功能出发一个功能一个模块一点点做。 说清楚风险，管理好预期，有人支持就大胆搞就是了。 |
 |
148
happywind 1h 59m ago
哈哈，明显 CTO 让你做他不敢做的事，应该跟老板畅想未来了不少加 AI 好办事
方案成功了：你的功劳变他的（这是我提的方案） 方案失败了：你是“罪人” 跟我们公司这个没啥两样，老板也不懂技术， 让你去冒风险做新功能，他自己做复制 ，粘贴工作。。。 |
 |
149
cenbiq 1h 51m ago
你这个跟什么语言什么数据库都没关系，数据库可能还是反向升级，.net 跟 go 性能是一档的，除非你是 node/python 可能还能说一下语言平台性能问题，我猜你们项目性能差主要是数据库设计瞎搞了。一句话别搞什么重构了，想办法优化一下查询，哪怕问下 AI 看看结论也行啊
|
|
150
qiaoqiao881100 OP @cenbiq 这个我说了不算啊，重构是领导要求，
|
 |
151
livin2 1h 44m ago
重构的前提是，有着极其完善的测试 case ，能改一步 test 一步，不然你这不叫重构，就是重写
|
 |
152
javalaw2010 1h 34m ago
线上业务敢重构的，都是有种的。给你点赞。
|
|
153
qiaoqiao881100 OP @javalaw2010 看来这个公司估计实在是找不到 CTO 招来这么一个坑货过来了
|
 |
154
deepshe 1h 24m ago
数据库 sqlserver->mysql 不是反向升级嘛
|
 |
155
aw2350 1h 18m ago
.net 十个项目九个是 shi ，因为这个群体开发人员较少，高质量的代码以及方案示例较少，开发人员接触到的层次也较低，所以写的都很 shi
|
 |
156
burymme11 1h 17m ago
@qiaoqiao881100 看你描述，第一步处理数据库迁移，线上数据从 sql server 切到到 mysql ，第二步做代码重构，是串行还是并行？如果是串行的，还能试着搞搞，并行的话。。。。。。。
如果是串行，20 张表还行，重新包一层，新老双写，切流，数据对比，这套 AI 应该能搞定。 |
 |
157
shiloh595 1h 15m ago
重构不如重做，OP 赶紧溜溜球吧
|
 |
158
wikisu 1h 14m ago
让你掌控就行，我对 ai 也是这么说的（ doge
|
 |
159
fujizx 1h 8m ago
经历过重构，也经历过 sql server 迁移到 mysql 。
信心满满重构之后，项目很容易变成新的屎山，唯一开心的是搅自己的没有搅别人的那么臭。 sql server 迁 mysql 小坑蛮多的。。。不过是痛苦一次的事情。 |
 |
160
zsmile 1h 5m ago
都有 AI 了，让 AI 自己跑吧，包出事的。人和代码一个能跑就行了
|
|
161
zsmile 1h 4m ago
C#很多都爱 SQLSERVER ，而且 SQL SERVER 都喜欢用存储过程什么的，总得来说都是费时费事的
|
 |
162
abc0123xyz 59 mins ago
如果能保证出问题后不杀了我的话，那迁移相当简单，轻轻松松.
|
 |
163
xingzhi95 59 mins ago
其实根本不是数据库的问题，是遗留代码的复杂度和可读性的崩溃
|
 |
164
slation 48 mins ago
重构数据库，这可是一般人干不了的事情，万一有点错误
|
 |
165
gejigeji 7 mins ago
数据规模有多大？
|
Select Language