> 目前主要针对 sql 类开发 - 典型特征就是，一处错误就是大面积错误，严重一些的，所有关联指标都错误。 - 而业务研发，一处错误，也就是那么几个记录错误。其他正常的记录，正常跑。 - 无法测试。sql 的开发往往是为了计算指标，指标难以测试，只能使用 excel 手动算一遍来校正。除非开发一个测试数据集。但是这样的数据集制作的耗时可能更多。不如直接用业务数据开发，反正和业务系统隔离。开发完毕后，直接和业务的 excel 报表对数据。也不会有大问题。 - 无法应对 corner case。当上游系统放了一个意外的数据进来，数据系统只能接受被投毒。 - 实现设计规则拦截？挂一漏万，不仔细穷举可能性就不能设计规则。不如不拦截。万一把正常数据拦截了，也讨厌。 - 还不如直接放错误数据放到下游。业务敏感的会自己上门报 bug。 - 严格的数据测试投入成本过巨。 - 如果测试太好，稳定性盖过苦劳。 - 得暴露问题。否则吃力不讨好。 - 数据有错误，又是不数据研发的错。在没我们之前，你们的日子又不是不能过。 - 反向绑架业务。努力让他们斯德哥尔摩。 - 如果业务自己用这块数据不多，那么数据错了，影响也不大。如果业务自己用这块数据多，自己也会关注起数据的质量，数据研发捕捉到这种信号后，要及时在前几次无关痛痒的小错误里，把大错误都先监控起来。跑到他们前面去。出问题了，先告知，反而没大问题。这成本也就控住了。 - 难？累？诶，就这个命！