做代理, 維運真的就學不到東西嗎?

來到新的工作環境差不多2個多月, 工作內容是接手1個已經上架的遊戲應用程式 (目前只在台灣地區上架), 維護運營加上串接其他國家營運商的平台. 任誰想這都是個吃力不討好又不好玩的工作, 沒有創新的遊戲機制設計, 只有上萬行程式碼等著你去看.

記得當初面試上這間公司, 製作人也是滿臉問號的我為什麼選這間? 暫且不討論製作人是有多心虛, 我的話, 除了離家近真的沒甚麼想法了... 剛從博弈業離開, 回到遊戲業肯定有一堆東西等著我學, 不是新手, 也不是老手.

上萬行程式碼

我想, 進入維運團隊最大的好處莫過於看到一些歲月的痕跡. 程式碼會說話, 每一行, 每個 function, class, 流程, 結構都透漏著前人的思維, 寫作習慣. 運氣好的話, 看到以前沒想過的方法, 啟發啟發; 運氣不好的話, 看到髒亂的痕跡直直罵.

實際上呢, 伺服器端的結構遵循著控制與資料分離原則, 以最簡化的 Web Service 來說 (不需要顯示頁面), 使用者端透過 HTTP 協定呼叫介面接口 (API), 接口根據內容分發給不同的控制器 (Controller) 處理, 再去資料庫 (Data Base) 取資料, 計算後回到接口返回內容給使用者端. 流程很明確, 但隨著系統做大, 控制器之間的交互作用也會變得複雜, 還有資料模型量大需要考慮的優化問題.

至於前端我就只能笑呵呵了, 經手的人一多, 風格也就多變, 這邊一個 UI, 那邊一個 Controller, 再來個 Manager, 還有遍布整個專案的 Singleton, 最後你會被繼承了5-6層的 class 給搞死. 程式碼基本上不太共用, 只寫自己功能需要的, 管它會不會重複... 好不好維護... 這又是另一個開發上的問題了.

好修的 Bug 早就被修掉了

看著公司系統 Bug List 上條列的問題少少, 不要太開心, 這些留到最後的都是埋藏很深的問題. 有的是程式設計結構上的問題 (ex. 多執行緒情況下), 有的是資料面交互後產生的意外結果 (ex. 資料量大情況下). 這些問題, 光是要找到重現步驟就花了好幾天, 然後再決定要不要修掉它. 你沒聽錯, 確實是有些 bug 不修, 考量發生機率, 修改成本, 最後採用消極處理 (ex. 出事了再手動修改資料或是賠賠裡包道具).

敢不敢重構

為什麼需要重構呢? 程式碼太髒亂了不易閱讀? 可重複使用性太低嗎? 還是新的需求一加進來發現原有的結構無法擴充? 重構理由一大堆, 最後多半屈服於不重構, 因為, 代價太大了, 根本沒有測試程式碼可以確保重構的正確性. 重構的基本原則, 測試程式碼是最後的防線, 用以驗證重構後功能是否存在缺陷. 前期開發的倉促, 需求變動快, 昨天寫的測試程式碼, 今天就用不到了, 那誰還要寫測試程式碼? 如果這個維運的案子裡只剩下你自己 (前人都已離職...) 不如好好衡量重構成本再決定.

結論

維運團隊對我來說確實是個練手的好機會, 熟悉工具也訓練批判思維. 每件事情都有它的正反面, 同樣都需要花這些時間面對事情, 還不如選擇用積極的心態, 時間是最公平的! 祝我努力撐過3個月吧~