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

背景###

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

BUG分析###

主要代码BUG 如下所示：

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

反思###

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

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

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

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

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

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

避免###

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