? 今天是 5 月 31 日，我們的遊戲的 alpha 版本的開發也快接近尾聲了，回望 5 月的開發經歷，我感慨頗多。我在團隊中處於比較核心的位置，可以毫不謙虛地說，我的工作對整個團隊工作的走向的影響是非常大的，因為我不僅是組長（負責管理），也是全棧開發人員（負責解決前後端和運維中的技術難點）。但我並不是項目經理，需求和產品設計的工作是付千山同學做的，我可能更像技術總監。

? 在寫這篇文章時，我先打開了 git ，看了看我們倉庫在 5.1 時候的狀態。幸好我們團隊一直是用 git 對規範地管理代碼，所以今天在總結時，我能清楚地知道這一個月來我們開發了哪些東西。5.1日時，dev 分支的 commit 數是103，5.31 日時 dev 分支的 commit 數是 284，這一個月我們提交的次數比3月和4月總和還要多。5.1 時，前端在 github 還只有一個測試頁面，後端對用戶的處理邏輯也還沒寫完。5.31 時，前端已經只剩遊戲界面和用戶界面了，後端只剩遊戲邏輯了。總的來說，這個月的開發進度還是推進得非常順利的。

? 我打算從兩個方面來談一談這個月我的心得體會。

先說技術，後端的技術難點有三個，第一個是遊戲邏輯的處理，第二個是郵件的處理，第三個是 scala 的 actor 和 java 的多線程模型的結合。第一個問題是 5 月快結束時解決的。在操作系統課和程序語言課的助力下，我成功找到了它的解決方案：前後端采取問答的方式進行數據交互，前端問後端：”我上一個問題的答案是xxx，下面我應該做什麽？“，後端回答前端：”上一個問題的反饋是xxx，你下面應該做xxx決策。“，這樣一問一答的模式可以方便地完成交互。前端只需通過 ajax 發送請求，並註冊回調函數，就可以做到在收到後端答復的時候再進行下一步操作，避免了輪詢。後端只需要通過異步編程，在適當的時候返回前端的請求的結果即可完成交互。後端的異步編程涉及到多線程共享狀態的訪問問題，因此應該謹慎地使用 Java 語言提供的 synchronized, wait, notifyAll 等函數進行多線程編程，在避免輪詢和忙等的情況下避免發生死鎖；第二個問題的解決步驟有三步，第一步是註冊一個可以開 smtp 的郵箱，第二步是去阿裏雲管理界面解封了 25 端口，第三步是修改了部分發郵件的代碼。這個問題的解決過程比較平凡。第三個難點是 Scala 的 actor 模型和 Java 多線程模型的結合，這個問題是我沒預料到的。一開始選擇 Scala 和 Java 混合編程，以為只需要解決混合編譯的問題就好了，現在發現，兩個語言在處理一些事情上的思路和模型不太一樣，這些東西也是需要仔細考慮的。最終我的解決方案是，Java 裏的 Checkers 模塊全是靜態的，沒有副作用，God 模塊的代碼需要保證線程安全，但自己並不處理線程的創建，Scala 裏的 akka http 框架會為每個請求創建一個隱式的 actor ，我們沒法控制這個 actor。但這個 actor 可以接收 Future，也就是說我們可以另外開線程來完成比較耗時的操作，而開線程這個過程我通過 Future 來完成。Future 需要一個執行環境，裏面有關於線程的調度的配置，這個配置可以用全局的默認配置，但更好的做法是使用 ActorSystem 的 dispatch 提供的配置。關於 Scala 的 actor 模型，有時間我還需要仔細了解一下。

前端的技術難點有兩個，一個是遊戲框架 phaser 提供的東西都是在 canvas 裏顯示的，而且沒有提供輸入框，選擇框等輸入控件。我先嘗試了第三方插件，但效果非常不理想，後來我找到了一個解決方案：把瀏覽器原生的 input 控件放在 phaser 畫布上，只需要把控件的 position 屬性設為 absolute 就可以做到了。前端的第二個技術難點是多個頁面之間的消息通信問題和多個頁面重復加載資源導致顯示不流暢的問題，這個比較簡單，只需要把所有控件放在同一個頁面上，然後每次顯示一部分，隱藏一部分。控件是通過 jQuery 提供的 show 和 hide 函數來實現的，畫布上的東西是通過 phaser 提供的 state 功能實現的。

下面就要說說管理了，五月初我發現前端進展非常緩慢，於是和朱池葦同學一起加入了前端的開發。前端原先是安排給吳同學和付同學來完成，因為吳同學基礎不夠好，付同學又主要在做產品方面的工作，導致前端進展非常緩慢。這個事情有我的責任，我沒能了解清楚大家的基礎，導致人手分配不均。吳同學一個人做前端，沒有人指導他，也沒有人幫他解決困難。他一個人花了很多時間，做了很多無用功，留下了許多不能用的半成品代碼，造成了資源的浪費，這是我作為管理者的失職。後來我和朱同學加入了前端，為前端開發鋪平了路，這時吳同學生產力就提高很多了。另外一個值得一提的是歐陽同學，我一開始給歐陽同學安排的任務是後端，他寫了一段時間，效果並不是特別理想，後來因為前端需要，我讓他畫了一些界面，結果發現他平面設計做得相當不錯，就讓他做了一些設計相關的工作，直到後來老師給我們請來了專門做設計的同學。然後我讓他去做前端了，又讓朱同學回來做後端，這其實有一點浪費，但確實是由於業務邏輯的需要，朱同學必須回來寫後端。前端人手又不夠，所以必須讓歐陽同學去寫前端。明明可以分工協作的，結果朱同學和歐陽同學都在前後端之間切換，導致開發周期變長，這也是我的責任。

另外我作為管理者，在績效這一塊也做得不是很好，沒有給組員及時的反饋。做得好的地方，應該表揚，做得不好的地方，應該批評。及時的反饋有助於調動開發的積極性。不過很好的是，我們團隊的整體氛圍是很歡快的，大家都很積極地參與開發，並沒有劃水的同學，所以績效考核這一塊的短板並沒有造成太大的影響。

管理中很重要的事情就是要讓大家在對的位置上發揮最好的效果，這也是我今後應該努力的方向。五月有收獲也有遺憾，希望今後的開發我能做得更好。

五月開發心得