關於動態配置表檢查工具 (討論帖)

拋磚引玉

配置表檢查工具在遊戲產業還是十分需要的，檢查節奏是理論每次發版本或者配置表有變更時都要做檢查，配置表填錯規則，不光是不生效，影響有：

普遍為客戶端崩潰，嚴重可伺服器當機和對應節點服務異常錯誤影響個別功能使用。
配置表檢查在網際網路來說這個名詞還是比較陌生的，不是那種配置中心 Yaml 檔案的那種。
略做解釋，一個遊戲展開後，配置表可能有幾十張甚至過百張，一個成熟的作品，資料整量過百 M。

遊戲配置表大多數是 csv，然後可以支援給客戶端/服務端讀（有些也會放美術配置，美術的主要還是給客戶端讀的），讀起來分為轉換 lua，載入記憶體，取不同 row 轉換一個結構體去讀，結構體可以理解成 go 語言的 struct。

足夠靈活和強大，配置表主要維護者是策劃（等同網際網路的產品，比他們更低的遊戲產業策劃比他們苦多了），我見過一家公司的配置表已經包含了不止是 OOP 還包含了時序，AOP，事件驅動，序列化資料結構 Pb 支援部分割槽域（注意不是 row 列那麼簡單），支援 SQL 語句和協議 ID，講道理，真是完全不出錯，起碼是使用同一套的熟練工。
然而不同公司又是不一樣的，這樣也導致配置表出錯機率不低。

不知道這裡是否有其他方案可以丟擲來聊聊。

靜態掃描

配置表檢查工具很多公司程會自己做，如果是開發自己做得載入後檢查，只能檢查登入載入資料，陣容，道具，貨幣，活動等，一些需要執行時的，只能透過標準規則去測試，也就是基於規則的靜態掃描。

• row 某些列資料包含幾個特殊字元，特殊字元分別含義，檢查這些列特殊字元沒有寫錯。
  
• 日期格式（yyyy/mm/dd 和 yyyy-mm-dd），不同策劃那邊沒統一 format，開啟後再儲存就翻車。
  諸如此類，都是可以透過不停新增規則，然後開多執行緒讓規則有順序關係的套規則去檢查，笨是笨了點，但檢查效率也不慢，靜態檢查本身還是以表做為參照物。

需要動態原因

如果設定到登陸後繫結了玩家資料（載入了公會資訊，揹包資料，活動資訊，戰鬥陣容，組隊狀態等等），不同玩家裡面資訊甚至檢查維度都是不一樣的，因為玩家資訊不同引發的動態。

• 玩家組隊狀態異常的去訪問了其他地圖，導致地圖拋錯。
  
• 玩家身上唯一道具在其他玩家身上因為掉落拾取後，導致揹包一直拋錯。
  

這些繫結了玩家資料後的，是無法用靜態規則的方式掃描出來的。

實現動態檢查的方式，還是先得建立檢查規則，再根據檢查規則進行排序，和靜態不同的是，透過介面測試和一些測試服資料庫欄位修改去模擬檢查規則，同時監聽伺服器對應執行單位的日誌是否有拋錯。

所以這裡包含了多個工具混合：介面協議支援，監聽服務端執行單位的日誌，資料庫自動修改欄位，mock 規則。

不知道這裡是否有其他方案可以丟擲來聊聊。