项目末期慎改代码的完整表述
项目末期要慎改代码，特别是临近上线，任何微小的改动都可能引发未知的bug，影响整体稳定性和用户体验。
不过这个表述有点模糊，显得不让开发改代码是测试祖传的规矩，让我们来搞清晰一下，以便劝说别人的时候多少有那么“一奈奈”（奈=耐米）科学感
什么是未知bug
- 有一些bug复现的概率很小，黑盒测试几乎无法发现（最后一趴会举一个这样的例子）
- 所谓“任何微小的改动，都可能引起未知的bug”，未知bug主要就是指这类概率复现的bug。
- 发现概率复现bug的一个有效手段是code review（记住这个手段后边要考）
- 比cr更有效的手段是“灰度发布”，既让一部分用户试用，且灰度范围越大小概率事件越容易发生。
如何定义项目末期
- 看一个改动能不能改，关键是看改了以后还有没有机会发现bug。
- 灰度发布以后丧失了发现“未知bug”的最佳时机，因此灰度以后，尽量就不要改代码了。
- 非要改的话，至少要经过严格的code review和领导审批。不过在没有AI纯靠人来CR的时代，效果好不好很随机。
好了，现在让我们实操一下
假设，灰度发布已经结束，准备发布上线之前，开发要改一行代码，就改一行，请问，能让他改么？（有意思的是，这一行改动，是人工CR的结果哦，人工CR以后要求从1改2）
我们把改动交给大模型，让它帮我们做一下CR
帮我做一个CR，while ((message = map.get(key)) == null && System.currentTimeMillis() < timeoutTime) { wait(1000); } 改为 while ((message = map.get(key)) == null && System.currentTimeMillis() < timeoutTime) { wait(timeoutTime – System.currentTimeMillis()); }有风险吗？
大模型回复如下（风险1并非本文讨论重点，故忽略，感兴趣同学可以自行尝试）
也就是说，即便有上图中圆圈3这个判断条件(改动前后的代码都有3这个条件)，保证currenttime小于timeout才进入循环，执行wait操作。仍然有概率导致执行wait(timeout-currenttime)的时候，由于时间流逝，currenttime已经大于timeout了，导致wait一个负数甚至更极端，wait(0)。所以代码从1改为2，虽然只改了一行，却引入了一个“未知bug”，这个bug通过黑盒测试，在马前炮（我们现在是马后炮），且发布在即的情况下，是很难测出来的。所以项目末期改代码是真的很容埋雷。
所以，结论却是
- 项目末期慎改代码
- 非要改的话要经过严格的CR，但人工CR结果很随机
- 大模型帮了我们，不但提供了更可靠的CR结果，还提供优化方案
- 既然艺高了，人就更胆大了，所以我预计，大模型时代，项目末期，可能会有比原来更多的改动。
- 为什么非要在项目末期才想起来改？我儿子总是在临睡之前还要再检查一遍书包，这是心理学的范畴，有机会可以再写一篇文章探讨一下。如何使用心理学方法防范末期改代码。
备注：本文中举了一个“未知bug”的例子，如果对这个bug的背景感兴趣，可以看这篇文章