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

背景

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

BUG分析

主要代碼BUG 以下所示：

只是增長了一個 from 是否爲空的判斷。 看上去沒有問題，但是若是構造器裏初始化了 from ，再設置 page，那麼新的 page 就不會生效。

反思

爲何沒有檢測出這個BUG呢？

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

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

一個教訓是： 合併發佈也要講究節奏，不能隨便搭車。若是由於小的細節處理不當，影響了總體發佈，那真是無以言表。

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

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

避免

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