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

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

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

产品和测试的锅呀

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

测试背锅

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

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

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

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

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

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

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

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

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

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

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

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

产品 90%、开发 10%吧，

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

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

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

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

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

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