重構了一波代碼，聊聊後端也聊聊遊戲後端

最近遊戲開發業務少了，我就開啓了重構運營系統的行動了。先說一下背景，運營系統是個不少人接手過的項目，代碼風格迥異，由於團隊沒有review機制，之前後臺的同窗都是怎麼方便怎麼來，完成任務就萬事大吉了。

由於公司的業務，這裏不會貼上代碼，大體描述一下在代碼結構上主要存在的問題：

1. 代碼爲了複用而複用，沒有語義，沒有遵循單一責任原則。
2. 重複性代碼太多，相同邏輯的代碼直接copy修改。業務層接口粒度太大，有不少能夠進行垂直拆分的公共代碼。
3. 重複的、有更好替代的工具類/公共類太多。見過最經典的一個例子：一個IO流異常處理的代碼片斷直接放在一個工具類進行復用，而且只有兩三處調用。
4. 上帝類。一個公共類想作的事情太多就意味着引入了過多的依賴，修改依賴的代碼很容易影響已有的業務。

按照上面的問題，反推重構方案：

1. 將看到的沒有語義或不規範的api先進行inline處理，在按照實際狀況斷定是否進一步提取公共api。
2. 將業務層顯眼的公共代碼片斷按語義進行提取，遵循單一責任原則，對業務進行垂直劃分。
3. 將能夠用開源工具類（guava、common-utils、spring-utils）替代的直接刪除，用開源工具類替代，將業務無關而且簡單實現已經沒有調用的接口、工具類移除。
4. 將上帝類水平拆分，按照domain水平拆分到應有的位置，不能作拆分和過多依賴的服務，嘗試將服務下沉作公共服務。

由於只是代碼結構變化，並無修改業務的實現，經過現代的IDE是能夠直接進行操做的，可是須要逐步review和按模塊進行version control。

運營系統指責單一，業務量不大而且按照實際的業務狀況不須要作服務拆分和集羣，資源佔用太大的調度能夠單獨拆分出來，開多個實例處理。這個小型系統的形狀其實跟遊戲後端同樣，在宏觀上是十份內聚的。（目前研發的遊戲也是單一進程的）但從微觀上講，良好組織的代碼應該像組件化、服務化的服務同樣，對內聚合、對外鬆散。從宏觀上看，大型服務架構系統其實也應該這樣。每一個服務就像遊戲開發的組件、小型系統的模塊同樣，是獨立自治的。只不過業務的調度不會在一個進程、單機內，多是多點的、集羣的甚至多地的。得益於中間件技術，將這些服務按實際的商用業務串聯起來。在不一樣的角度，能夠說它們按結構來看是極度鬆散的，也能夠說他們高度內聚的。按宏觀上來看，後端開發實際上是類似的，只是面對實際要解決的問題各有各的不一樣，按實際狀況選擇最優解罷了。本人拙見，貽笑大方。