Unity 專案程式碼管理(二)

前言

這次要深入探討一些程式碼撰寫的習慣，不一定會減少程式碼量，但基本上能提高專案效率。

區域變數

多使用區域變數，減少使用成員變數、屬性，在方法行為單一職責化的情況下可以大幅降低程式碼的閱讀難度。
另外使用區域變數能夠讓方法的結果更容易預測，能更好寫出測試。

關注點分離

目標

關注點分離是很多語言框架實作的基礎，有實作過後端的同學應該不陌生。雖然 Unity 沒有特定說明程式碼撰寫風格，但將顯示與邏輯分離在多人協作時能提供很好的整合能力。

Unity ECS 其實變相地強迫使用者做到關注點分離

優點

1. 能夠在沒有顯示的情況下測試邏輯（pure C#）
2. 各個邏輯模組的進入點能夠被確認
3. 除錯時可以更快瞄準邏輯問題
4. 因為程式碼被細分了，版控比較不會有衝突的情況發生

缺點

1. 程式碼的量變多了
2. 響應事件，需要透過 event 或是 dispatch signal 等方式將顯示層的操作傳遞過去，會造成效能耗損（回呼地獄）
3. 相依性，這部分要多考慮使用 DI 工具
4. 除非有特別寫單元測試，否則原生 Unity 並不親和 pure C# ，有可能更難追蹤錯誤的地方

綜合以上優缺點，如果是小專案或是要快速產出 Mock 版的情況下不推薦使用。

撰寫習慣

微軟有為 CSharp 規範一套習慣。

在 Unity 裡面最常遇到需要指定物件參考，基於對物件的封裝欄位（Field）不應該公開，而能夠公開的會是屬性（Property）、方法（Method），但 Property 很難在 Editor 底下進行序列化，所以當一個類別的成員變多時，沒有系統的命名會疑惑程序猿。

另外值得一提的是換行習慣，由於 C# 不倚靠縮排來達成程式碼區塊，適時地換行是值得鼓勵的，我們來看下面這段 LINQ 程式碼：

userList.Where(user => user.isVip).Range(0, 20).SelectMany(user => user.Characters).ToList().Foreach(c => AddDLC(c));

應該很難直接看出這行到底做了啥，所以可以改成

userList
  .Where(user => user.isVip)
  .Range(0, 20)
  .SelectMany(user => user.Characters)
  .ToList()
  .Foreach(c => AddDLC(c.id));

就能清楚條列出這行程式碼要做的是給前 20 位 VIP 玩家的所有角色新增 DLC。_{雖然這是滿極端的案例就是了......}

最後提一下程式碼縮排跟括弧換行，基本上現在的 IDE 都提供相當優秀的程式碼格式化功能，但需要注意的是如果是接手其他人的程式碼，亂按格式化可能會導致版控衝突。

結語

這次說的內容比較偏概念，通過增加些許的程式碼量，進而提高效率，在多人協作時更能減輕交接時的困難。