很难理解么？

假如在原始社会，你一个人可能要5年才能凑够材料造一把菜刀，如果菜刀坏了轻易不可能扔。但现在别说坏了，钝了都可以扔掉再买一把。

复杂不复杂，是相对生产力而言的。你以前认为是复杂的东西，在ai时代可能就是很简单的事情
【 在 guizhidao 的大作中提到: 】
: 业务系统的复杂性，怎么能想推翻就推翻呀
: 除非微服务切分的好
--
FROM 116.233.45.*

淘宝的业务系统有啥复杂的？最多你可以说因为运行的规模大时间久，里面堆的屎比较多罢了。
说实话我早就对这种只是因为业务规模大就吹复杂的轮调看不惯了。

以12306为例，论qps压力它可以藐视任何系统。最高qps一天1500亿，是双11的三倍。它被喷上天之后只是在12年7-8月进行了一轮重构就解决了。当然12306你可以说业务非常简单。那么看pdd，2015年上线，2016年用户量过亿，2017年GMV破千亿，也就2年时间。

这种国民级应用，还有哪个在吹业务量大，并发访问难的？哪怕是在淘宝早期时代，基础设施没那么好，还需要解决这些问题的时代，全球这么多业务体量相当的案例，我想不出哪个因为并发没弄好，业务量太大，把自己搞砸的。
12306算是这里面底子最差的了，正常市场搏杀出来的案例就没有出现过被这个问题卡自己脖子的。

现在都2025年了，openai把月活破亿的记录刷到2个月了，生产力已经到了新的阶段了，复杂啥啊？你这个就好像在跟我讨论挖铁挖煤冶炼很复杂。它们再复杂，也已经是被解决的问题了，只是个工作量罢了，没有人care挖煤复杂不复杂。

【 在 guizhidao 的大作中提到: 】
: 如果是畅想，可以理解，未来一段时间后有可能实现
: 如果说现在，比如淘宝的业务系统复杂性不算啥复杂性，我是不信的
--
修改:lvsoft FROM 116.233.45.*
FROM 116.233.45.*

没空。我现在已经一个月开支超400刀了...

claude烂爆了，mmd我刚觉得它比以前有改观，最近一直在重度使用它，我还没开max呢就这么费钱...
关键是这货在给我代码里面埋了一个很深的坑，以至于我到很晚的时候才发现需要大规模重构...算了我还是回到gemini吧...

【 在 hgoldfish 的大作中提到: 】
: Dr.奢侈, augment 好用吗？
:


--
修改:lvsoft FROM 116.233.45.*
FROM 116.233.45.*

呵呵。

我见过一个数据库5万张表，每个表都是字段起步上百个（因为压根没人用join），字段还都是拼音首字母缩写。
这样的系统，没有人敢用别人的表，所有人都是开新表完成自己的业务，
然后找“领域专家”（就是知道上某个表里百个拼音首字母缩写的字段是什么意思的人）找到他要的数据，复制一份到自己新建的表里面，然后成为一个新的“领域专家”。
很多人还得意洋洋，因为别人请教它这个xxxx字段是什么意思是要付顾问费的。

这叫复杂性么？无法重构是技术问题么？是能力问题么？
屎山就是屎山，别给屎山贴金。

从你的回复来看，你就是这群拉了屎还扬扬自得的档次的人

【 在 gfkid 的大作中提到: 】
: 我觉得衡量业务复杂性，可以从数据库的字段多少来衡量。
: 就比如银行业，小银行的数据库中表就有几百个，字段几千。
: 业务发展过程中，很多json格式数据用来解决无法增加表字段的难题。
: ...................
--
修改:lvsoft FROM 116.233.45.*
FROM 116.233.45.*

字段衡量的是这个领域的信息差多少。而不是复杂度。

【 在 gfkid 的大作中提到: 】
: 我觉得衡量业务复杂性，可以从数据库的字段多少来衡量。
: 就比如银行业，小银行的数据库中表就有几百个，字段几千。
: 业务发展过程中，很多json格式数据用来解决无法增加表字段的难题。
: ...................
--
FROM 120.37.22.*