一、純手工

　　公司主營的是直播業務，會很許多打榜活動，也就是按主播收到的禮物或收益進行排序，排在前面的會有相應獎勵。

　　純手工時代，每接到一個活動，就重新寫一份，第一次寫完。之後就是複製黏貼，再修改，每次活動，測試人員測試也蠻苦惱的。

　　雖然複製的是之前的程式碼，已經經歷過一輪測試，但手工操作難免會有這個那個的細節問題，都得重新測試一遍。

　　而且定時任務的測試成本還是蠻高的，因為每次測試就要修改時間，來模擬真實環境。測試環境各個組用的都是一套，改了伺服器時間有時候還會影響其他組的開發，所以測起來要快而準。

　　定時任務（node-schedule）需要三個引數：開始時間、結束時間和迴圈規則，在測試時這三個引數可能會與線上環境不同，榜單依賴的禮物ID、統計時間在正式和測試也有可能不同。

　　所以一開始的時候，測試環境測好後，在發到線上之前還要做一次引數的修改，這其中也有隱患，寫錯的話不但要修改程式碼，還要重新合程式碼，再發布，得走一整套流程。

二、引數配置化

　　像定時任務的引數、榜單的引數諸如快取key、禮物ID、統計時間等，都可配置化。

　　得益於之前開發了一套通用配置系統，可將這些引數以JSON格式寫到輸入庫中。

　　測試環境配置一套，正式環境也配置一套，程式碼可互不影響。

　　並且在更新引數後，不需要再合程式碼了，只要重新發布一次即可。

　　因為定時任務的規則只會在釋出時配置一次，後面引數更新後，若不釋出，新的引數就不會被執行。

　　雖然引數配置化後，省了合程式碼，但複製黏貼仍然還要做一次。

　　於是在分析運營的需求後，抽象出一套高度可配置化的榜單任務，在後臺管理系統中單獨開一選單，將動態的引數全部變得可配置。

　　得益於之前抽象出了一套通用模板元件，這個頁面只花了兩個半小時就搭建好了，包括後端介面和列表頁面，在列表頁面可控制活動的上下線。

　　資料來源有了之後，就要寫定時任務中的邏輯了，其實就是從資料庫中讀取欄位，將欄位作為引數傳遞給榜單方法。

　　當然，若有新活動上線，程式碼還是要重新發布一次的，這一步還沒做到自動化。

　　未來還有很大的優化空間，像程式碼釋出自動化，榜單前端頁面可配置化，目前每次都要重新做一份，其實也可以抽象出來做成可配置化，甚至可以做好頁面編輯器，自定義後直接釋出。