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