Result Pattern 與軌道導向程式設計 (Railway Oriented Programming)
上一篇：Result Pattern 與錯誤處理 按照 Result Pattern 的概念，我們經常需要處理各種錯誤。但是為了適當的處理錯誤，程式碼總是會變得太長，導致不容易閱讀。像是以下的程式碼：
為何 Unity 的 Round() 是往偶數捨入？
首先，.NET 預設的 Round() 就是這樣，我想 Unity 官方其實也沒想那麼多，就只是把原本只支援 double 的 Math 類別改成支援 float 而已。 至於為什麼預設會使用 ToEven，是由於財經與統計方面的關係。
敏捷不該有重構階段
這是 Martin Fowler 在 2011 年的 Opportunistic Refactoring 其中的概念。 作為工程師，我們當然都經歷過，程式碼擴增到了某個時間點就會開始變得笨重，笨重到連新增一個理論上應該很簡單的功能都變得麻煩。如果你夠有責任感，你可能會想要花些時間整理程式碼，也就是所謂的「重構」。甚至，你可能會想要一個 sprint 來專門重構程式碼，我們姑且稱為「重構階段」好了。
Result Pattern 與錯誤處理
有些狀況下，我們會有個流程進行一系列的工作。但每一個步驟都有可能失敗，而且失敗的狀況還 不只一種。對於這種狀況，我們會想要明確的知道失敗的種類，讓我們安全的進行後續處理。
MVP 模式的職責區分 (2) - View 與 Presenter
※ 雖然此篇與 Unity 比較有關，但是概念適用於現代的 MVx 系列。 Presenter 的工作是站在 Model 與 View 中間協調兩邊的運作。一方面取得 Model 的資料與事件，根據展示需求傳達給 View；一方面接收使用者操作 View 的行為，決定如何與操作 Model 工作以及更進一步的展示。 但是 Presenter 和 View 的分界概念到底是什麼？