Unity 專案程式碼管理(一)

前情提要

每個專案開發，都是由多個工程師來完成，就算只有一個人，隨著專案增量，你便會與過去的你面對面，這時候程式碼的可讀性高低就會成為左右你開發效率的一塊石頭，這篇就來說說幾個程式碼管理的小撇步。

Region

程式碼區塊，是最簡單可以把程式碼分類的方法，得益於各種 IDE 、編輯器都非常方便了，無論使用哪一種基本上都能將 region 區塊摺疊起來閱讀。

我是比較喜歡使用 VS Code

VS Code

Visual Studio

Early Return

這是很基本的程式碼撰寫風格，能有效解決一些波動拳 if-else 的問題。

有些更單純的賦值操作，應該用三元運算子、模式匹配來完成

不妨將條件反轉改成

Partial Class

很多人不知道可以使用 Partial 這個關鍵字將一個 class 分別寫在不同的腳本內，以此來達到程式碼的分類。

Summary

在多人協作中最常接其他人的方法來用，儘管方法名稱命名得很好了，有時候還是不太知道傳入的參數、回傳的值在做些甚麼事情。
同樣得益於編輯器進步，這時候有寫 summary 告訴其他人這個方法的用法就很重要。

在 Visual Studio 內預設就有/// 三撇生成 summary 的功能，而 VS Code 需要安裝插件。

有使用到泛型時，類型約束、回傳的類型最好要明確說明
C# 的 Summary 是使用 XML 來撰寫

VS Code

Visual Studio

Git Commit / Message

首先， commit 盡量不要包山包海，盡可能一個 commit 只做一個 feature 、修一個 bug 。

雖然協作時審 PR 很花時間（所以常常口頭上說一下就給勾勾了），但比起看 PR 內容，我更常用 commit 來知道這次的 PR 做了些啥。

硬性的撰寫格式要由團隊成員達成共識，比較有趣且好用的案例像是 GitMoji 。
Summary 的部分，我自己習慣的寫法是：

< Add / Fix / Remove > < Subject >

而 Body 的部分逃不開 Implement 、Refactor 等關鍵字。一個好的 commit message 通常包含了：

• 做了啥
• 為了啥
• 如何做到

但也要注意不要過長，如果為了一個 commit 花太長時間編輯 message 可就本末倒置了。

後記

對於這個專案程式碼管理的系列我想出個 2~3 篇，算是有感而發吧，近幾個專案都是接做一半的，而我也正在重構半年前開發到一半的遊戲，因為沒有做好程式碼的整理，導致讀程式碼壓縮了實作的時間。

離上次開方格子寫文章隔了半個月，這裡終於支援程式碼了！可能有越來越多跟程式設計相關的創作者加入了，目前支援的語言不多，我也還是用 gist 來寫示範以方便修正，但滿意外有支援 Rust 的。

另外有一篇關於 Unity Screen Space 的文章一直卡在那邊難產，應該會找時間把它完成......