## 一、純手工   公司主營的是直播業務，會很許多打榜活動，也就是按主播收到的禮物或收益進行排序，排在前面的會有相應獎勵。   純手工時代，每接到一個活動，就重新寫一份，第一次寫完。之后就是復制黏貼，再修改，每次活動，測試人員測試也蠻苦惱的。   雖然復制的是之前的代碼，已經經歷過一輪測試，但手工操作難免會有這個那個的細節問題，都得重新測試一遍。   而且定時任務的測試成本還是蠻高的，因為每次測試就要修改時間，來模擬真實環境。測試環境各個組用的都是一套，改了服務器時間有時候還會影響其他組的開發，所以測起來要快而準。   定時任務（[node-schedule](https://github.com/node-schedule/node-schedule)）需要三個參數：開始時間、結束時間和循環規則，在測試時這三個參數可能會與線上環境不同，榜單依賴的禮物ID、統計時間在正式和測試也有可能不同。   所以一開始的時候，測試環境測好后，在發到線上之前還要做一次參數的修改，這其中也有隱患，寫錯的話不但要修改代碼，還要重新合代碼，再發布，得走一整套流程。 ## 二、參數配置化   像定時任務的參數、榜單的參數諸如緩存key、禮物ID、統計時間等，都可配置化。   得益于之前開發了一套通用配置系統，可將這些參數以JSON格式寫到輸入庫中。 :-:    測試環境配置一套，正式環境也配置一套，代碼可互不影響。   并且在更新參數后，不需要再合代碼了，只要重新發布一次即可。   因為定時任務的規則只會在發布時配置一次，后面參數更新后，若不發布，新的參數就不會被執行。 ## 三、定時任務配置化   雖然參數配置化后，省了合代碼，但復制黏貼仍然還要做一次。   于是在分析運營的需求后，抽象出一套高度可配置化的榜單任務，在后臺管理系統中單獨開一菜單，將動態的參數全部變得可配置。 :-:    得益于之前抽象出了一套通用[模板組件](https://github.com/pwstrick/shin-admin/blob/main/docs/template.md)，這個頁面只花了兩個半小時就搭建好了，包括后端接口和列表頁面，在列表頁面可控制活動的上下線。 :-:    數據來源有了之后，就要寫定時任務中的邏輯了，其實就是從數據庫中讀取字段，將字段作為參數傳遞給榜單方法。   當然，若有新活動上線，代碼還是要重新發布一次的，這一步還沒做到自動化。   未來還有很大的優化空間，像代碼發布自動化，榜單前端頁面可配置化，目前每次都要重新做一份，其實也可以抽象出來做成可配置化，甚至可以做好頁面編輯器，自定義后直接發布。 ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。