為什麼我推薦功能驅動的軟體設計方法？ - khalilstemmler

功能feature代表了軟體設計的基本複雜性。這是無法避免的複雜性。其他所有內容（語言，工具，模式等）都是意外複雜性的一種形式。因此，要編寫最簡單的程式碼（無論我們在堆疊的哪一側），都應該採用功能驅動feature-driven的方法。它影響我們構造專案，編寫測試，封裝模組和設計功能的方式。

偶然的複雜性

在大多數主流程式語言中，都存在狀態和序列的概念。根據本·莫斯利（Ben Moseley）的說法，狀態和序列是 意外複雜性的兩個主要原因：

• 狀態：“您是否嘗試過將其關閉然後再次開啟？” 以前有沒有人對你這麼說過？當系統最終處於非法狀態時，就會發生這種情況。維持狀態很難。我們必須跟蹤變數，例項等。
• 順序：首先，我們執行這個操作，然後才需要執行那個操作，但前提是發生這種情況”。我們大多數人都使用支援過程和條件的語言編寫。當我們必須確保事物按特定順序發生時，我們還將引入表面積，這樣就提高了複雜性。

偶然的複雜性是指我們面臨的複雜性實際上與問題的複雜性無關（例如基本問題-功能）。相反，意外的複雜性與我們解決問題的方式有關。

這意味著包含狀態和序列的語言或正規化會無意間引入意外的複雜性。

好吧，我們可以編寫沒有狀態和序列的程式碼嗎？

事實證明，我們可以。

通過函數語言程式設計減輕意外的複雜性

這是（純粹地）函數語言程式設計的亮點。Scott Wlaschin的《領域建模的功能》一書描述了一種通過使用最少的狀態或序列來對功能/用例（他稱為工作流）進行建模來儘可能接近基本複雜性的方法。

這是一種非常徹底的方法。我認為這太神奇了。但是，真正的純鐵上下的函數語言程式設計是不適合心臟虛弱。這是一些嚴格的程式設計。通過從頭開始對整個域建模，類似於我們從第一原理建立數學方程式的方法，這確實是使非法狀態無法表示的方法。

結構與開發人員的經驗-FP很難

在軟體設計中，需要在結構Structure和程式設計師經驗之間平衡。90年代的OOP員工發現了一種很棒的功能優先方式，可以始終如一，可靠且自信地編寫包含狀態和序列的程式碼。

使用功能優先的TDD馴服（狀態和序列）複雜性

測試驅動開發不僅僅是對React元件和類進行單元測試。

通過找出一種繼續新增和更改程式碼的方式，並確保我們應用程式的功能仍然有效，可以獲得最佳的投資回報。這就是我們大多數努力的地方-因為這些功能畢竟是必不可少的複雜性。

執行TDD的“功能優先”方法是執行Double Loop TDD。

功能優先的集合

我發現的一些最佳技術可以幫助我們與當前問題的本質保持一致，並消除噪音（技術堆疊，語言，範例等），這些技巧如下：

• 事件風暴
• 事件建模
• 用例驅動設計
• 驗收測試驅動開發（也稱為雙迴圈TDD）
• ...還有更多，待續

您可以在前端和後端體系結構上以功能驅動的方式工作。看看DDDForum的程式碼，DDDForum是我們在solidbook.io中構建的應用程式。後端遵循按用例組織的功能優先專案結構。