订单搜索分页失效的教训：怠惰必受惩罚

背景

2018年8月21日，订单搜索发布导致订单搜索分页失效。该发布有三个变更：1. 新增一个带详情的订单列表接口；2. 按照订单状态搜索的索引分流； 3. 支持自定义的from传参。 第三个变更只有一行代码，更像是搭了个顺风车， 但正是这行代码，导致搜索分页失效，整个发布失败，最终回滚。

BUG分析

主要代码BUG 如下所示：

只是增加了一个 from 是否为空的判断。 看上去没有问题，可是如果构造器里初始化了 from ，再设置 page，那么新的 page 就不会生效。

反思

为什么没有检测出这个BUG呢？

虽然我通过 curl 测试了 from 的自定义传参没有问题，可是正好绕过了Java构造器初始化的过程，没有测出来。

1. 这个单测没加；虽然我几次想加，可是不知有种神秘的力量阻止了我；可能嫌变更太微小。
2. 没有上预发去回归下分页能力。当时确实有点怠惰。
3. 测试带详情的列表接口和状态分流索引耗费我更大的精力，对这个重视不足。

一个教训是： 合并发布也要讲究节奏，不能随便搭车。如果因为小的细节处理不当，影响了整体发布，那真是无以言表。

更大的教训是： 怠惰省去了几分钟的测试和回归时间，结果却消耗了两个多小时用来发布、回滚、重新发布，得不偿失，还险些造成故障。正应了那句话：

怠惰必受罚， 勿以微小而不慎。

避免

1. 增加密集接口测试用例（主动检测）；
2. 增强预发环境的订单搜索对比引擎检查（被动检测）；
3. 合并发布要慎重，要有节奏和计划，不能随意搭车，尤其是项目发布；
4. 任何微小改动，都必须严格单测和接口测试，预发回归，不可轻忽怠惰。

原文地址：https://www.cnblogs.com/lovesqcc/p/9537542.html