这种情况导致的 bug，开发需要背锅吗

[falsemask]

比如这样一个场景，你们的系统对接了淘宝京东拼多多的订单，现在要对接抖音的订单，产品需求描述：8 开头的订单号都是抖音订单。 你按这个判断开发上线后发现，有一部分淘宝订单也是 8 开头，然后你查询历史数据发现数据库之前就存在 8 开头的订单是淘宝订单。 测试阶段也没人发现这个问题。这是 100%产品的锅吗？

[bzw875]

开复盘 [甩锅大会] ，让领导来决定

[markyun02]

开发是有责任的，没有思考业务逻辑是否合理的基本能力

[Tink]

产品和测试的锅呀

[make115]

先确定：8 开头的订单号都是抖音订单， 产品这个结论有何而来，

[bojackhorseman]

测试背锅

[calmlyman]

我觉得所有参与的人都有锅，大小的问题。如果我是你，开始的时候就会去先确认到底是不是只有抖音的订单号才是 8 开头的。

[falsemask]

@markyun02 开发应该怎么判断"8 开头的订单号都是抖音的"这个业务逻辑是否合理呢

[Mandyer]

OMS 系统，我们是系统自己产生一个订单号，然后三方平台的订单号存另一个字段叫原始订单号，这样即使平台之间订单号规则重复也不影响

[fffq]

> 为什么是你来做，其他人不能做吗？你需要有自己的判断力，而不是我说什么你就做什么。我希望看到你的思考，而不仅仅是进度。

[ilylx2008]

这产品真是个倒霉蛋，订单号逻辑竟然是产品定

[buyerhou]

我认为是产品的锅，啥 TM 都能让开发背锅是吧。开发啥都能干是吧？那还要其他人干嘛，都回家歇去吧！

[Jinnrry]

用 8 开头表示来源，这是人能想出来的方案？用脚指头想想也会冲突啊，实在不行，订单号前面加个[douyin]或者加个[taobao]这样的前缀也比你用数学区分好啊

[hokori]

产品的问题 谁提出 8 开头的订单号都是抖音订单的

[qwertyyb]

这应该是在需求评审阶段就合理性充分验证，如果产品侧一意执行，则需要充分告知风险点。

[liaohongxing]

开发有一定责任，如果只是简单的判断 8 开头的订单就是抖音订单， 埋雷而已， 你没有挡回去，现在只是爆发而已。

1. 如果是订单号前 1 位是枚举 8 代表抖音，7 代表淘宝， 如 80000000001 , 8 是你添加上去的，位数不足补 0, 重复的可能性较小

2. 暴力点 ，订单号直接字母拼接 ，DY0000000001, DY 代表抖音 ，TB0000000001, TB 代表淘宝， 重复的可能性较小

[fruitmonster]

产品 90%、开发 10%吧，

虽然开发不是主责，但是我个人代入了一下，我一定会问，是不是已经确定过了“8 开头”就一定是抖音订单，也一定会去库里查一下，因为出问题了要改的还是自己

其次，订单号以单独的某个数字来标识某个渠道，接到这个需求的时候，就会有疑问了，为什么要这么奇怪的定？

[loveour]

我觉得可以区分开责任和能力。这个事，我觉得开发背不了最大的责任。但是，即使开发不背责任，这个人的能力也会在我心理打一个大大的问号。
开发不能仅仅是实现产品的需求，还得有点自己的思考。以及，如果是那种产品话语权特别重的公司，那开发就更要留个心眼了，也要保护自己吧？

[whitefable]

参与的所有人都应该背锅+1 ，只是产品应该是最大的。作为开发，产品的这个应该算是很明显的不合理的需求，接到的时候最起码也应该去质疑一下确认一下。一般来说需求方能说服我的话我会照做，说服不了的话我会说清楚原因并且找上一级领导说明风险，不然出了事其实对大家都不好

[rocmax]

怎么还有自己找锅背的？需求说了开头 8 的订单，那就按这个开发，只要这个需求落在纸面上了就跟开发一毛钱关系没有。
还要开发怀疑为啥这么设计，有没有例外情况。那产品说的话是不是每句都不能信？每句话都重复确认三遍签字画押可好？

[duanxianze]

这种情况所有人都有锅+1 ，但开发肯定是小头

[ugpu]

8 开头 就一定是抖音订单 这是谁提出来的？
顶多说程序业务经验不足; 这关程序个屁事;

[main1234]

PM 方案不合理，RD 实现也不合理，都有责任

[3country]

产品需求描述：8 开头的订单号都是抖音订单

[3country]

产品大锅，研发小锅

[jay_chiu]

判断失误，开发需要背锅。

[imnpc]

订单接口都有来源渠道的，这么简单的问题换需要判断订单号？

[nanjingwuyanzu]

谁说的 8 开头都是抖音订单谁就背锅

[IamUNICODE]

这玩意不应该自己订个订单号然后用类型区分吗，一开始谁说 8 开头都是抖音，谁的锅

[wangritian]

虽然产品是主锅，但作为开发，看到这种需求没有质疑吗，不能一点脑子不过吧，甚至都没用历史订单号检验一下

[Jokesy]

我们公司：运维的锅，上线后没及时发现问题

[tonytonychopper]

都有责任，但是需要 PM 背锅

[qxmqh]

神 TM 8 开头的，这是怎么想出来的，这玩意又不是自己平台的，如何能控制的住，明天 其他平台的都是 8 开头的了，那你们咋办？何况已经有 8 开头的淘宝订单在库里面了，之前你们都不查看一下是否已经存在 8 开头的订单了吗。一个 sql 就能查出来的问题，太低级了。所有人都有锅。

[yhxx]

“产品需求描述：8 开头的订单号都是抖音订单”

有字据吗？有的话，如果我是开发，我一分的锅都不可能背
但是说实话自己心里还是得知道，这种还是有问题的，下次要注意

[EminemW]

这应该在开发前就提前告知这么做的风险，如果开发没有提出这个风险点，开发也得背锅

[cocomanber]

这个是产品的锅，需求如此，不是每个人都要深究需求的合理性。作为开发，我们也应该尽量根据自己的开发经验对需求提出异议。