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

RT

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

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

组织架构也变臃肿了

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

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

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

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

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

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

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

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

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

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

降本增笑