写死的产品功能，早干嘛了呢

编者按：本文来自微信公众号“唐韧”（ID:RyanTang007），作者：唐韧，36氪经授权发布。

昨天在朋友圈看到一个做技术的朋友说自己背了口大锅，然后配了一张这样的图。

好奇之下我去问他怎么回事，结果差点没把我笑翻。

他们公司是做垂直领域电商产品的，策划了一场线上抢购低价商品活动。

为了营造一种紧迫感，在活动开始前设定了 60 秒的倒计时页面，倒计时结束后，用户就可以开始抢购。

倒计时逻辑是由程序控制的，数字在产品页面上也有展示。

原本以为万事俱备，没想到还是翻车了。

当倒计时开始后，正当办公室所有人准备 60 秒倒数时，结果页面上的数字直接从 2 开始倒数。

2 秒后，活动就开始了。

而此时，页面上方还提示着「活动倒计时 60 秒」。

当时领导也在场，所有的产品、研发、设计、测试也都在，现场一度尴尬。

当空气静止几秒后，产品经理立马跳出来说，需求里不是明确了倒计时 60 秒吗，怎么变成了 2 秒？

测试也说，测试时明明是 60 秒，怎么变成 2 秒了？

研发赶紧去查代码，这一查发现，线上代码里倒计时的数字写的就是 2。

仔细看提交记录发现，最后一次测试结束后，测试又提了一个修改问题。

某个研发小哥修复后上传了最终代码。

可是，研发小哥为了修改后快速走一遍流程，把原本的 60 秒倒计时设置改成了 2 秒，但提交最终代码时忘了改回来了。

测试最后也没走查。

就这样，一个被焊死的产品逻辑上线了。

我这朋友是他们团队的技术负责人，面对领导铁青的脸，连忙道歉，说是自己对代码 review 没有做好。

领导很生气，留下一句「早干嘛了呢！」然后拂袖而去。

这锅背的，也是让他哑口无言。

因为这个倒计时页面也就展示一次，也没有修复的必要了，直接定性成一次线上事故。

对技术稍微有一点了解的读者知道，在代码中有一个说法叫「写死」。

所谓的「写死」，就是将程序中一些原本应该用变量或者需要由后台控制的逻辑，改成用固定「常量」写到代码里。

比如上面控制倒计时的数字就是一个常量。

不管是 2 还是 60，这个不变量写到程序里以后，程序就会按照这个数字执行。

与常量对应的是「变量」。

当程序执行到逻辑点时，会从外部获取对应的值来做接下来的处理，这个可变化的值就是变量。

比如你购买商品时，用户可以选择商品的数量，最后订单金额会根据商品数量进行计算，这个可变的商品数量就是变量。

如果把本该是变量的值写成常量，那这个逻辑就被「写死」了。

还记得今年 3 月份淘宝 App 出的那场线上事故吗？

用户打开淘宝 App 后弹出一个对话框，提示内测版到期，然后提示用户更新最新版。

以至于很多用户好奇，原来自己一直用的内测版。

其实并不是，只是淘宝团队在发布 App 时，把一段写死的代码留在了安装包内。

到了一定的时间，这个逻辑就像定时炸弹一样被触发了，导致很多用户收到了这个提示。

实际上，就是一个写死的产品逻辑带来的锅。

解决逻辑被「写死」也不是没有办法，只不过都是体力活，很多人为了图方便，不愿意做。

就比如上面提到的 60 秒倒计时活动。

可以把这个参数写到一个单独的配置文件里，也可以把所有关于规则的变量控制都放在一起。

在上线前，测试和产品都可以去检查这个配置文件，检查对应的配置项是否正确。

技术在控制代码逻辑时，都从这个配置文件里去读取对应的变量，这样就可以将逻辑和变量控制解耦。

如果遇上需求调整或者问题出现，只需要调整配置文件里的配置项就可以了，程序代码不用动。

可很多时候就是为了省事，很多逻辑都被「写死」在了代码里。

这也是很多产品大锅的来源。

包括淘宝那次事故，其实把触发弹窗的逻辑控制放在后端而不是写死在前端就能解决问题。

可能就是技术为了方便，把这个逻辑写死在了前端，而且还不小心发布到了正式版本里。

产品功能和规则的变化可能是随时的，原本的限制可能会变成日后的需求。

所以，逻辑控制做得越灵活，后面越方便。

就比如现在的电影院买票产品。

以前的需求是禁止隔座选位置，现在却变成了只能隔座选。

如果这个限制是写死在前端交互逻辑里的，那实现新需求就得调整前端代码。

灵活一点的做法，可以让用户先自由选，提交选座申请后由后台来判断是否符合规则。

如果符合则正常提交订单，如果不符合则提示用户为什么不能这么选。

所以呀，宁愿事前多花点功夫，也总比写死后背锅强。

有些公司会因为赶进度或者图省事而一切从简，觉得先上吧，有问题再说。

可是，这恰恰是挖坑的开始。

需求范围、时间、资源、质量是一个铁三角，任何一个因素的变化都会引起其他条件的变化。

有时候需求方和老板的诉求和急迫心情能理解，但基本的物理规律也很难突破。

写在最后

把产品功能写死这件事，不是某一个人的锅，而是一个团队工作方法和流程的体现。

产品经理有必要把关键逻辑做特殊说明，把可变因素提前周知。

研发有必要养成让关键变量与代码逻辑分离的习惯，把不确定性隔离出去，使其可控。

测试有必要在产品上线前做最终全面的 checklist，哪怕只改了一个文案。

如果不想背「写死」的锅，准备工作还得提前且细致。

产品上线就像发射火箭，开弓没有回头箭！