原创内容未获授权禁止转载、转发、抄袭。SDD指的是Spec Driven Development 规格驱动开发它不是让团队多写文档。而是开发前先把规则写清楚。规则清楚了开发不容易写偏。规则清楚了测试也知道怎么验。普通开发的问题很多需求一开始是这样的用户可以取消订单。这句话太粗。开发会有疑问哪些订单能取消已支付订单能不能取消取消后库存要不要释放优惠券要不要返还支付回调晚到了怎么办如果这些没说清楚代码很容易只做表面逻辑。最后就变成页面提示取消成功但库存没释放。 订单取消了但优惠券没返还。 取消后支付回调来了订单又变成已支付。SDD 要解决的就是这种问题。什么是规格规格不是一句功能描述。比如用户可以取消订单。这不是规格。更像规格的是1. 待支付订单可以取消。 2. 已支付订单不能直接取消需要走退款。 3. 已取消订单不能重复取消。 4. 取消成功后订单状态变为已取消。 5. 取消成功后库存释放。 6. 使用过的优惠券需要返还。 7. 取消后如果收到支付成功回调订单不能改成已支付。这才是开发能实现、测试能验证的内容。实际例子订单取消开发前可以先把规格写成表格。场景规则验证方式待支付订单取消允许取消状态变为已取消查订单状态已支付订单取消不允许直接取消需要走退款返回明确提示已取消订单再次取消不允许重复取消订单状态不变取消后库存库存需要释放查库存数量取消后优惠券优惠券需要返还查用户券包取消后支付回调订单不能改回已支付查订单状态和回调日志这张表不复杂。但它能让产品、开发、测试先对齐。开发知道要处理哪些逻辑。测试知道要验证哪些结果。产品也能提前确认规则是否符合预期。测试要提前参与SDD 里测试不能等代码写完才进场。需求评审时就要问清楚哪些状态可以操作哪些状态不能操作操作后状态怎么变关联数据怎么处理重复操作怎么处理异常回调怎么处理比如看到用户可以退款。测试不能只记下来。要继续追问已发货能不能退款 是否支持部分退款 退款后优惠券是否返还 积分是否回滚 重复退款会不会重复打款 退款失败是否重试这些问题越早问后面返工越少。一个简单模板实际工作里可以直接用这个模板。模块 订单取消 业务规则 1. 待支付订单可以取消。 2. 已支付订单不能直接取消。 3. 已取消订单不能重复取消。 状态变化 待支付 - 已取消 关联数据 1. 库存释放。 2. 优惠券返还。 3. 操作日志记录。 异常场景 1. 重复取消。 2. 多端同时取消。 3. 取消后收到支付成功回调。 验收标准 1. 订单状态正确。 2. 库存正确。 3. 优惠券状态正确。 4. 日志可追踪。如果这些内容写不出来说明需求还没准备好进入开发。SDD 的关键点SDD 不是把文档写长。而是把下面几件事写清楚业务规则状态流转关联数据异常场景验收标准测试方式特别是订单、支付、退款、优惠券、权限这类功能。不能只写页面怎么展示。还要写清楚数据怎么变。总结SDD 的核心不是文档。而是共识。开发前先把规则写清楚。测试前先把验收标准写清楚。规格不清楚代码写得越快返工也可能越快。