背景

2018年8月21日，訂單搜索發布導致訂單搜索分頁失效。該發布有三個變更：1. 新增一個帶詳情的訂單列表接口；2. 按照訂單狀態搜索的索引分流； 3. 支持自定義的from傳參。 第三個變更只有一行代碼，更像是搭了個順風車， 但正是這行代碼，導致搜索分頁失效，整個發布失敗，最終回滾。

BUG分析

主要代碼BUG 如下所示：

只是增加了一個 from 是否為空的判斷。 看上去沒有問題，可是如果構造器裏初始化了 from ，再設置 page，那麽新的 page 就不會生效。

反思

為什麽沒有檢測出這個BUG呢？

雖然我通過 curl 測試了 from 的自定義傳參沒有問題，可是正好繞過了Java構造器初始化的過程，沒有測出來。

1. 這個單測沒加；雖然我幾次想加，可是不知有種神秘的力量阻止了我；可能嫌變更太微小。
2. 沒有上預發去回歸下分頁能力。當時確實有點怠惰。
3. 測試帶詳情的列表接口和狀態分流索引耗費我更大的精力，對這個重視不足。

一個教訓是： 合並發布也要講究節奏，不能隨便搭車。如果因為小的細節處理不當，影響了整體發布，那真是無以言表。

更大的教訓是： 怠惰省去了幾分鐘的測試和回歸時間，結果卻消耗了兩個多小時用來發布、回滾、重新發布，得不償失，還險些造成故障。正應了那句話：

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

避免

1. 增加密集接口測試用例（主動檢測）；
2. 增強預發環境的訂單搜索對比引擎檢查（被動檢測）；
3. 合並發布要慎重，要有節奏和計劃，不能隨意搭車，尤其是項目發布；
4. 任何微小改動，都必須嚴格單測和接口測試，預發回歸，不可輕忽怠惰。

訂單搜索分頁失效的教訓：怠惰必受懲罰