持续重构。没有第二条路。其他都是扯蛋。如果没有投入持续重构，动不动就是，这个功能稳定了，不能动，代码不能改。吧啦吧啦。。这必定成为一个新的 shit 山

都几亿数据了。你要说没备份库我是不信的

nas 啊。。。。再不济。。接个外置硬盘在 dp 口上。
真想不明白怎么可能有 500G 的数据经常要查看。。

说的轻轻松松是有前提条件的。仅仅是业务查询，非聚合查询。聚合分析别说上亿了，上千万，可能就得考虑上 olap 的分析工具了。

另一方面，你都上亿的数据了，还是需要分析的。4c 16G 是不太小了点。这个成本是可以计算的。

1.clickhouse 集群。4*16 集群 x3.
2.mysql 把硬件往上面拉三倍。

从哪个角度看都是 2 成本更低。除非你能做到 1 是动态的，但投入的隐形成本又是另一回事。

换句话说，我个人认为绝大多数的场景，堆机器就够了。除非有数据分析团队资源，全靠研发自己出方案，实在得不偿失

这倒是，有 gpt 加持，后端狗半天就会撸前端了

反正作为运维，每个新项目我都要怼一次后端开发 leader：不许给我搞微服务，你就单体。

单体也需要运维，都让研发搞就是逗闷子的。只是真不需要一堆运维了，我一直认为国内公司，90%有且只需要两个运维。搞微服务？那就看架构吹牛逼吹多大了。

我怼得最多的一句：高并发？你自己试过本地 mysql 1000 万数据集两到三层良好索引的 sql 效率吗？没有？没有你扯犊子的因为性能横向扩展？

如果有 apple vision 。那就只有这个。如果没有。憋着

组件是为需求服务的。。
你这相当于我要一个超级牛逼一统天下的组件库。等于没要求。

按回车按快了。。
另一方面肯定不是一蹴而就，前面网关做分离工作，迁移一批网管流转新流量过来一批。反正这么大的规模，就算是看起来是差不多的业务逻辑，但凡错一个，估计得祭天。

从写单元测试开始。上千的表。接口也差不多上千了。你怎么保证重构完了一摸一样的结果和逻辑？

折腾时间够买一个带云功能的血压计了。。

说到这个就来气。。。一哥们说 vue 很好用。一定要用 vue ，我说了 n 次，我公司 4-5 个前端，全是 react 。。这 vue 的屎山谁来吃？不行，那就是 vue 框架添加第一，硬要上。我就低头了，我就低头了，我就低头了。。恩。最后这坨屎山还是我来吃。我能说什么。。。

不算大佬。但是。当一个跟你一样想法的人放飞自我的去做了。擦屁股的大概率还是自己啊。。你骂骂咧咧拍拍屁股就走了。得，我还要在自己不熟悉的自己不熟悉的屎山里面翱翔。我自认自己拉的也是屎山，请问，既然都是屎山，我自己拉的和别人拉的，我就一定要为了顾及想法，捏着鼻子去吃别人拉的？

@prenwang 这就跟阿里云的 java 军规一个道理。先对齐颗粒度，打通底层逻辑。完全的无厘头限制。

这么说吧。。如果一个编辑器没有 vim 模式，那只有垃圾堆适合他

@seth19960929 这也是我的疑问。。1 台 256G+32C 的服务器的钱再加电钱。可不是一点点钱，除非是有几千人的大厂，用量大平摊成本。普通 100 来人，40-50 个研发的公司。真的需要 remote 开发？不过我刚和我们前端讨论了一下。。一句话就怼回来了：是工作不饱和吗？

@cndenis 这个我也能理解你的痛点，唯一办法，升级，让上一级的人要求。安全应该是红线

@kuanat 知道是一回事，团队用是另一回事。我前面也说了，我自己尝试过几次…实在没 GET 到点。当然拉，各位回复都是电脑不行。不过，我身边同事都是用自己电脑都是 32G 起步…so…这可能也是一部分原因吧。