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

背景

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

BUG分析

主要代码BUG 以下所示：

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

反思

为何没有检测出这个BUG呢？

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

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

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

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

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

避免

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