这是一贴迟到的推文了，小红书闪退已经是 7 月 26 的情况了。
不知道大家又没有遇到，反正不爱更新 app 的大树是没碰到😂
案发始末
从微博内容来看，小红书闪退的情况应该是 7 月 26 日 晚上开始出现的。
然后在 27 日 凌晨 02:47 ，小红书客服 发布微博建议："如果遇到小红书App 无法启动的情况，请删除 App（选择删除 App，而不是从主屏幕移除）重新安装，如果有需要保留未发布的作品草稿，请等待 App Store 的更新，我们将尽快发布新的 App 版本解决问题。"
我天，这真的能解决问题嘛😂？
开机重启还能重置下系统缓存， 你这卸了重装如果还是之前版本，不是什么都没变吗？
然后就出现了第一张图里，被”祭天“的开发。。。看微博下的回复，最终原因应该是客户端的数据结构崩了。
等等，被祭天的 竟然是开发？ 版本上线的一条链路里，我觉得测试的话语权是最大的（卡点不放，谁能上？）如果没有经过测试的环节，那研发要担自己的责任，但是版本更新这种变更，不得走一遍测试嘛？
再想想也可能是因为 现在 APP 的版本更新速度太快了，大家对它的重视也就下来了，事故率自然也就上升了。
感触
真的可以说是，现有的东西要小小心心的碰， 数据结构、接口，只要是现有的，就要格外小心。因为只要之前的开发离职了，这行代码就谁都不知道是如何被创造出来的。
对于一个程序员来说，线上代码和版本的变更是一项极其重要的任务，我们也需要谨慎对待，因为它直接影响到产品的稳定性、用户体验和业务流程。
-
变更线上代码和版本是一项责任重大的任务。作为程序员，我们肩负着保障系统稳定和可靠的责任。每次变更都必须经过谨慎的计划和评估，以确保新的改动不会破坏现有功能，避免引入新的问题或漏洞。因此，我们必须时刻保持高度的专注和警惕，对每个细节保持敏感，以确保变更的平稳进行。
-
小步快走是变更线上代码的一项重要策略。将复杂的变更拆解成小而稳定的部分，一次只引入有限的改动，这有助于更容易追踪问题的来源和解决方案。此外，小步快走也有助于缩小变更范围，减少潜在风险，并让团队更容易适应变化。不过多数时候，这个都比较难做到，大家为了效率有时候也会搭便车。
-
CodeReview 一定要做。目前来看，这件事儿在阿里做的还是可以的，也就是代码上线前，必须要有至少两个人看过这段代码。这样可以降低错误发生的概率，毕竟有时候自己看自己的代码是看不出来问题的。
-
在进行变更线上代码之前，必须进行全面的测试。测试是保证代码质量的关键步骤，包括单元测试、集成测试和端到端测试。 只有通过全面的测试， 我们才能确保新的改动不会对系统稳定性产生负面影响，并且能够正常地适应真实生产环境。
在代码上线前，我们要做好较为完整的计划，比如说线上问题了要如何处理，回滚能否解决。
同时，上线后我们必须时刻保持警惕，密切监控系统运行状态，注意报警并确保有足够的日志记录，以便快速定位和解决问题。如果出现严重问题，我们可以按照之前的预备方案进行回滚，确保能够迅速返回到稳定版本，以最小化对用户和业务的影响。
想想小红书事件，作为这么大的公司，他们应该也监控了 客户端打开率或者接口的调用率，但可能因为大家伙更新时间的比较分散，所以么有一下子爆出来吧。。。
如此看来，最重要的还是前置的：Code Review 和 测试环节 。毕竟不发生总好过发生了再去补救。
最后祝愿我们大家都职业生涯顺利、线上环节健康、不出 BUG！
