這學期軟工小組的開發就快結束了，回想整個開發過程，感慨頗多。

首先是剛開學時的組隊和選題，我們各自提了好多項目，有的太簡單，有的沒有價值，有的又太不切實際，最終我們選定付千山同學在高中設計的遊戲作為題目，因為這既新穎又有前期調研，而且也比較有趣。

但其實，我之前從來沒有遊戲開發的經驗，組員們也只了解一兩門語言，幾乎沒有大型項目開發經驗。所以，這次項目從技術選型到開發都是一邊摸索一邊做。現在回過頭去看，有得有失。首先，Travis CI 的學習和使用是非常正確的決定，因為後端運行環境比較苛刻，不方便在組員自己的電腦上搭建。因此，我們需要快速部署更新的代碼，以方便測試和調試。如果按照我以前的方法手動更新，那麽效率將大大降低。這個問題還有一個解決方案，即配置一個 docker 鏡像，讓大家都能迅速搭建服務器。這個方案也很不錯，下次可以實踐一下；然而，技術選型就有些差強人意了。先說後端，後端的技術是 Scala + Java，效果並不如剛開始以為的那麽好，Scala 和 Java 的交互體驗並不是那麽友好，一是 Scala 的庫 Java 用起來很困難，二是 Scala 的常用寫法在 Java 沒法寫，三是 Scala 和 Java 的並行控制也不盡相同，尤其是在 Scala 中使用 Actor 時。不過慶幸的是，Java 部分的代碼大部分是無狀態的，這方便了單元測試，也方便了並發控制。再說前端，前端使用 Phaser 和 JavaScript，Phaser 有一些坑，比如輸入框和場景控制，而且 Phaser 框架整體較重，調試體驗並不好。JavaScript 是一門有諸多缺陷的腳本語言，作用域問題曾給我們帶來了痛苦的 debug 經歷。如果重新選擇技術棧，我可能前後端都選擇 TypeScript，或者前端 TS，後端純 Scala。在這次開發過程中，我也犯了好幾次錯誤，一是場景變換問題，之前我們使用的是網頁跳轉，這是很不好的，會導致資源重復加載，後來在了解到 Phaser 裏有場景變換後，我才花大力氣把它們重構了；二是前後端在遊戲中的交互，應該使用 Socket 直接交互的，我這次使用了 http，顯得有些笨重，但還好前後端交互流量不大。

在項目管理上，我的經驗是，在項目初期分工不必太明確，因為項目架構還沒完全建立起來，模塊的邊界還不清晰，所以大家可以參與整個項目的代碼 review，或者至少對項目各個部分是做什麽的有一些了解。以及，這個階段，我不認為應該投入很多人力，應該讓經驗豐富的工程師先完成項目架構的搭建，然後再進入下一步的開發。任務墻和 issue 是很好的東西，可以讓我們方便地記錄、討論和擬定開發計劃。另外，臟的代碼應該及時重構，或者明確標註，以限制其使用範圍，不然到了後期改起來會非常麻煩。

總之，這是一次非常寶貴的開發經驗。在這次項目開發中，我不僅學到了規範的軟件工程管理流程，也提高了自己的業務水平和與人溝通合作的能力。

軟工項目總結