架构复杂度增加是不是导致了稳定性下降？最近动不动就是谷歌崩了、微信崩了、淘宝崩了、网易崩了，以前都没这么多事件

[drymonfidelia]

[yjxjn]

@sagaxu #12 接触过一些日本的程序员，除了少部分优秀的，其余大部分都是菜。测试居然是 Happy Path Test

[YVAN7123]

降本，没有主备系统了呗

[Foxkeh]

感觉像游戏一样停机维护还更直接更靠谱一些

[dif]

一方面：系统大了就会这样，我以前参与的项目十几个人一起开发，经常有雷。
另一方面：我经历过的都是快速迭代，有坑再填。实际上老板要求填坑也不能影响迭代，所以，慢工出细活还是有些道理的。

[jhdxr]

@jim9606 #17 推特裁员也从来没精准过吧。裁完以后既没有少崩，也没少嘲笑马斯克啊

[Perry]

听离职推特的朋友说的，推特裁员把很多高水平的逼到主动辞职（离职包裹给的还行），留下来的都是等绿卡的外籍程序员（印度为主）

[DOLLOR]

@sagaxu
日本今年还有角川 niconico 网站关停两个月，数据泄露，实在叹为观止

[512357301]

本质上还是用户量太大了，用户量涨一个数量级，硬件成本不能也涨一个数量级啊，而且机器多了，运维成本也高了。
功能多，用的人多了，代码量自然也就大了，为了快速迭代，提升开发速度，自然架构就复杂了，专人专岗是效率最高的方式。
说到底所谓的互联网大厂，本质上就是一个个开发工厂。特别是那些外包公司，更是血汗工厂。

[james122333]

所以简单的东西才是王道 刻意复杂化的东西没有不垃圾的 不论使用还是学习
现在流行的大多是垃圾东西

[guanhui07]

降本增笑

[james122333]

如何简单精妙实现一样的效果才是吾辈追求

[smlcgx]

人类总是乐观看待风险和高估自身能力
能抵抗百年不遇的洪水
闯一个红灯没关系的
把老员工都裁了不会有问题的，系统很成熟了

[scienhub]

@lujiaxing "目前已知的唯一一个极其复杂但没有任何 BUG 的系统就是物理": 很有意思的点。

但是物理系统之所以没有 bug ，可能是因为我们意识里就觉得物理世界是对的，如果没有按我们理解的运行，那肯定是我们理解有问题。比如光地双缝干涉这种，你可以认为这是物理世界的 bug ，但是绝大部分人，都认为这是物理世界的规则，只是我们没有理解透彻。

[laminux29]

这并不是什么裁到大动脉，而是老板、项目经理不愿意付出时间成本，来给员工预留写文档与读文档的时间，导致员工踩坑。

团队协作的场景，为了确保软件质量，为了减少坑，每个员工，在做实现之前，必须要写详细的设计文档，交接工作时必须要读完前任写的文档。但只要你去打听，在国内，无论大小厂，无论体制内外，极少听说老板与项目经理，预留足够时间，让员工去读写文档。

不写文档，不读文档，自然会容易踩坑。

你问问你自己，你的上级，给你预留写文档与读文档的时间了吗？

[GoLand]

多方面原因因素：
1. 复杂度确实增加了，迭代时间越久，加上各种砍一刀、优惠券乱七八糟的功能，系统肯定变得更复杂了，相对应的稳定性必然会下降。
2. 使用的人多了，同样复杂度的系统，要做到可用性 99.99%，100QPS 和 1 万 QPS 难度差很多很多。
3. 迭代变快了，以前竞争没这么激烈，需求迭代也比较慢，变更引入的事故也少。
....

[iovekkk]

我司之前裁了一个外包都裁了出问题了你敢信不？
原因就是这个外包不知是有意还是无意反正非常注重防御性编程，代码一坨屎但是能勉强运行
他在职的时候就属他的模块 bug 最多但是他愿意加班维护，不会太拖延整体进度
他离职之后其他人都不想接手他的代码，迫于无奈，领导从其他项目里要了一个人过来
结果新来的人搞了快两周还没熟悉他的代码，bug 改不过来新需求完全做不了
于是现在又把他重新招回来了，降本增效又一经典案例

[p1gd0g]

以前也不少吧？可能以前信息流不那么顺畅，出事未免会成为热点

[satoru]

组织架构也变臃肿了

[coderxy]

@iovekkk 防御性编程成功案例？

[opengps]

你既然要说以前，可得知道那时候都是停机更新。各种功能融合在一起，甚至一个错别字都得中断几秒钟