立即登录 昨天刷朋友圈，看见一个做技术的朋友发了条动态，说自己替人背了个大锅，配图是张语塞的表情包。我好奇，跑去问他怎么回事。听完他讲的经过，我差点没笑出声，但硬是忍住了——毕竟这事儿搁谁身上，都挺窒息的。
他们公司是做垂直电商的，那天策划了一个低价抢购活动，想着用倒计时来制造紧迫感。活动页面上端写着“活动倒计时60秒”，下方数字区域也跟着同步显示倒计时。当时办公室里产品、研发、设计、测试全围在屏幕前，连领导都站在旁边等着看效果。结果倒计时一动，数字干脆利落地从2开始跳，两秒一到，活动直接开了。而页面上那句“活动倒计时60秒”还端端正正挂在上头，场面要多讽刺有多讽刺。
空气安静了几秒。产品经理第一个出声，说需求里明明写的是60秒，怎么变成2秒了？测试也跟着说，自己测的时候对着呢，一到线上就不对了。研发赶紧查代码，发现线上版本里倒计时的初始值就是2。翻提交记录才知道，最后一轮测试结束后，测试又提了一个别的修改，有个研发小哥为了快速验证，临时把倒计时从60秒改成了2秒。但改完他就忘了改回去，直接把带着2秒的代码提交了上去。而最终上线前，测试也没再核对这个数字。
朋友作为技术负责人，只能硬扛。领导脸色铁青，他赶紧道歉，说是自己代码 review 没做好。领导甩下一句“早点做什么去了”，转身就走了。朋友说，那一瞬间他真的哑口无言，因为页面只展示一次，连修复的机会都没有，直接就定性成了线上事故。
稍微懂点技术的人可能都听过一个词，叫“写死”。说白了，就是把一些本该灵活变化的逻辑，直接用固定值焊在代码里。比如倒计时那个60秒，如果它是个变量，可以从后台配置或者配置文件里读取，想改的时候改一下配置就行。但一旦你把它写死成2，那程序就只认2。跟“写死”相对的，就是“变量”——由外部数据决定的、可以变化的值，比如用户下单时选了几件商品，这个数量就是变量。如果把本应是变量的东西写成了常量，这个逻辑就算被“焊”死了。
可能很多人还记得今年3月淘宝App那次事故。不少用户打开淘宝，莫名其妙弹出一个对话框，提示“内测版到期”，让人更新最新版本。一时间好多人都怀疑自己是不是一直用着内测版。其实并不是，只是开发团队在发布安装包时，把一段到时触发的逻辑写死在了前端代码里。到了那个时间点，就像定时炸弹炸了一样，大批用户收到了提示。这也是典型的“写死”带来的锅。
要避免逻辑被写死，其实有办法，只是很多时候大家觉得麻烦，或者赶进度就不愿意做。还是拿60秒倒计时来说，正确的做法是把这个时间参数放在一个单独的配置文件里，或者放到后台系统里，上线前产品、测试可以去检查这个配置对不对。代码实际运行时，从配置里读取数值，这样逻辑和变量就解耦了。万一以后想改成30秒、10秒，只需要改一下配置，一行代码都不用动，更不会出现因为临时测试改了值而忘记回退的情况。淘宝那次也一样，如果触发弹窗的逻辑是后端控制，而不是写死在前端发布包里，就不会那么被动。
产品需求和规则总是在变，今天你觉得某个限制不会动，说不定明天就变成了新需求。把控制做得灵活一些，后面会省很多事。比如现在电影院选座，以前可能要求禁止隔座选，后来规则变了，又能隔座了。如果当初把“禁止隔座”的逻辑写死在前端交互里，那改规则就得动前端代码；但如果做得灵活一点，让用户先自由选，提交时后台去判断是否符合规则，符合就下单，不符合就提示，那调整起来就轻松得多。
所以，与其事后被“写死”背锅，不如提前多花点功夫。很多公司因为赶进度、图省事，总想着先上去再说，有问题再改。但上线那一刻，往往就是开弓没有回头箭，一个小小的写死，就可能让整个团队在领导面前颜面尽失。这不是某个人的锅，而是团队工作方法和流程的体现。产品经理需要把关键逻辑交代清楚，提前识别出哪些地方可能变；研发要有意识地把关键变量从代码里抽出来，隔离不确定性；测试则要把最终的检查当成一个硬性清单，哪怕只改了一句文案，也得把相关的数字、状态重新跑一遍。如果不想再背这种锅，准备工作还是得做到前面，细致一点，再细致一点。