一、純手工
公司主營的是直播業務，會很許多打榜活動，也就是按主播收到的禮物或收益進行排序，排在前面的會有相應獎勵。
純手工時代，每接到一個活動，就重新寫一份，第一次寫完。之后就是復制黏貼，再修改，每次活動，測試人員測試也蠻苦惱的。
雖然復制的是之前的代碼，已經經歷過一輪測試，但手工操作難免會有這個那個的細節問題，都得重新測試一遍。
而且定時任務的測試成本還是蠻高的，因為每次測試就要修改時間，來模擬真實環境。測試環境各個組用的都是一套，改了服務器時間有時候還會影響其他組的開發，所以測起來要快而准。
定時任務（node-schedule）需要三個參數：開始時間、結束時間和循環規則，在測試時這三個參數可能會與線上環境不同，榜單依賴的禮物ID、統計時間在正式和測試也有可能不同。
所以一開始的時候，測試環境測好后，在發到線上之前還要做一次參數的修改，這其中也有隱患，寫錯的話不但要修改代碼，還要重新合代碼，再發布，得走一整套流程。
二、參數配置化
像定時任務的參數、榜單的參數諸如緩存key、禮物ID、統計時間等，都可配置化。
得益於之前開發了一套通用配置系統，可將這些參數以JSON格式寫到輸入庫中。
測試環境配置一套，正式環境也配置一套，代碼可互不影響。
並且在更新參數后，不需要再合代碼了，只要重新發布一次即可。
因為定時任務的規則只會在發布時配置一次，后面參數更新后，若不發布，新的參數就不會被執行。
三、定時任務配置化
雖然參數配置化后，省了合代碼，但復制黏貼仍然還要做一次。
於是在分析運營的需求后，抽象出一套高度可配置化的榜單任務，在后台管理系統中單獨開一菜單，將動態的參數全部變得可配置。
得益於之前抽象出了一套通用模板組件，這個頁面只花了兩個半小時就搭建好了，包括后端接口和列表頁面，在列表頁面可控制活動的上下線。
數據來源有了之后，就要寫定時任務中的邏輯了，其實就是從數據庫中讀取字段，將字段作為參數傳遞給榜單方法。
當然，若有新活動上線，代碼還是要重新發布一次的，這一步還沒做到自動化。
未來還有很大的優化空間，像代碼發布自動化，榜單前端頁面可配置化，目前每次都要重新做一份，其實也可以抽象出來做成可配置化，甚至可以做好頁面編輯器，自定義后直接發布。