忙到飛起卻進展緩慢？聊聊小團隊提升遊戲研發效率的方法

筆者目前的團隊研發力量有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進行了整合。方便互相進行程式碼檢查。

堅持做系統設計文件

不能因為人少就摒棄了軟體工程的重要環節。系統設計文件不僅是認識系統的說明書，也是系統迭代的重要指導書。

堅持寫系統設計文件，也是為了晉級答辯準備材料，系統設計文件將系統裡可能遇到的問題，瓶頸，分析論證，可以很方便的抽象系統。為以後做類似的系統提供思路。

系統的容量和資料量的分析，也是系統擴容的重要依據。

以上總結的幾點思路是本人在帶領和參與小團隊研發過程的一點思考，大部分都屬於公共知識，踐行這些原則會浪費一些時間，但確實是一件投資未來的事情。

堅持做效率敏捷的優化，可以保持小步快跑，個人的工作效率和自我提升的時間也會越來越多。

對於自己和團隊這都是雙贏的事情。


騰訊互動娛樂 後臺開發
來源：騰訊GWB遊戲無界
原文：https://mp.weixin.qq.com/s/LytUQfeEKf-YdqennDyZ1Q