編者按 讓遊戲研發敏捷起來，提升整體效率，應該是每個團隊都想做到的。本文作者根據自身經驗，總結分享了小團隊的研發敏捷效率之道，希望能給大家啟發。
文 | Highway
騰訊互動娛樂 後臺開發
筆者目前的團隊研發力量有3名客戶端開發以及兩名後臺開發，再加一名外包的管理端開發同學。目前客戶端僅需要支持安卓版本。大概一個月一個版本的研發節奏。其中，2個星期的研發時間 + 1個星期的bug 修復+ 1個星期的需求優化等。
技術選型：
小團隊的本身力量小，要懂得利用社區或者公司的力量，因此在技術選型上應該向生態更好，維護力量更強，社區發展更蓬勃的語言和技術上靠齊。
這樣，在出現問題的時候，就不會花費大量時間在各種網站上尋找解決方案，甚至需要自己研究源代碼，修改源代碼的情況。
以筆者的項目而言，繼承於合併前的兩大部門的歷史產物，包含mcp,lua,php,swoole,go等語言，而在部門產生變動之後，小團隊已經無法維護這麼多技術棧，因此對不需要變動的服務維持，對需要長期迭代的服務則用go語言進行重構，對服務也用go語言進行編寫。
他山之石，可以攻玉。小團隊更應該將更多的力量聚焦在業務的實際開發，而不是在框架上，工具上重複造輪子。
大系統小做，小系統大做
在小團隊裡，很容易有慣性思維，以自己小或者時機不成熟為由，將業務冗雜在一起。他們以為有時間可以以後慢慢拆分，但是往往就是最後想拆的時候，發現已經無法進行拆分。
服務拆分，應該是服務設計的時候就必須做的事情。它要求開發者高瞻遠矚，暫時的維護工作量，帶來的是將來無窮的方便和可複用性和可拓展性。
現在慢一些，是為了以後跑的更快一些。
另外系統拆分，對於系統的穩健性大有好處，不會遇到牽一髮動全身的災難。
完善的devops流程
得益於藍盾的發展，開發/編譯/部署 一站式流水線成為了可能。這將大大減輕開發人員在環境部署上花費的時間，自動化將開發代碼運行在測試環境。
同時藍盾上集成的代碼掃描功能，結合質量紅線，可以幫助開發者評估代碼質量，形成統一風格的代碼和優秀的編碼習慣，使得代碼的可讀性和可維護性大大加強。
完善的mock機制
由於客戶端和後臺往往是並行開發，非並行開發容易導致多餘的溝通和聯調成本。
因此，在需求確認之後，就開啟技術設計溝通會，會議會拆解協議，同時約束好名詞約束，定好協議規範。
後臺利用yapi 製作mock server，將所有約定的接口進行mock。
在並行開發期間，後臺按照約束的數據實現，客戶端按照mock server 定的協議開發。後臺開發完成之後，檢查協議返回數據一致即可完美匹配。
優秀的rpc通信機制
既然服務已經拆分為小服務，那麼服務之間的通信就是通過rpc來進行，利用grpc等通信機制，可以通過約束協議，自動生成客戶端代碼，方便調用者調用，減少溝通聯調成本。服務之間調用變成開箱即用的行為，而grpc等還有http2等優化行為，提高了調用效率。
良好的代碼管理習慣
一般可以按照主分支，dev分支，每個開發人員一個開發分支的開發行為進行管理。也可以按照MR的方式進行管理。在筆者的項目裡，採用了MR的方式，主要是工蜂將MR和CR進行了整合。方便互相進行代碼檢查。
堅持做系統設計文檔
不能因為人少就摒棄了軟件工程的重要環節。系統設計文檔不僅是認識系統的說明書，也是系統迭代的重要指導書。
堅持寫系統設計文檔，也是為了晉級答辯準備材料，系統設計文檔將系統裡可能遇到的問題，瓶頸，分析論證，可以很方便的抽象系統。為以後做類似的系統提供思路。
系統的容量和數據量的分析，也是系統擴容的重要依據。
以上總結的幾點思路是本人在帶領和參與小團隊研發過程的一點思考，大部分都屬於公共知識，踐行這些原則會浪費一些時間，但確實是一件投資未來的事情。
堅持做效率敏捷的優化，可以保持小步快跑，個人的工作效率和自我提升的時間也會越來越多。
對於自己和團隊這都是雙贏的事情。
