寫一個功能應該從定義開始。
作為功能的實現者，對於實現細節的追求似乎刻在了骨子裡，我們追求性能優化，更有效的算法，更少的內存佔用，更可控的數據流行為…… 這些永遠是沒有錯的，人們總是追求更好的產品。但是開發一個新的產品的時候，這樣的思維慣性實際上會帶來一些困擾。
一個很愚蠢的惡循環是，我們想要一個很好的產品，於是我們使用更好的技術，在細節處精益求精，這導致我們永遠會發現更好的做法，於是我們永遠無法完成這個產品。更好一些的是，在一開始就敲定設計然後實裝。這是比較傳統的做法，適用於很多大型系統，而敏捷開發則是對這類做法的一種擴展，由於小型的系統對於細節設計的需求並不像大型系統那樣的高，修改也比較容易，所以設計工作和開發工作被整合，通過將傳統流程簡單化，多輪化，團隊得以用更快的速度交付產品並獲取反饋。這些年為了適應這樣的趨勢，市場上出現了許多的相關服務和工具。
有沒有一種模式，可以適應大規模開發的需求，同時提速到類敏捷開發的速度？幾年前我讀過關於領域驅動設計的幾本書，這是一種很好的開發模式，但是它對於團隊的要求比較高，換句話說，它依然是一個高成本的選擇，同時，如果不能快速磨合整個團隊，它的開發速度依舊是偏慢的。
現有的開發模式似乎總是要求人們去學習一些新的概念，有沒有通用的概念可以讓我們直接上手？其實是有的，因為這個領域的人們或多或少都得學點數學。
是的，數學，或許是這個世界上最多人使用的，最具有共識力的一種工具模型。我的父母或許不懂怎麼寫一個軟件統計和計算每月營業額，但是他們也能通過數學手段得到一樣的結果。當我們去查看我們的軟件的構造和邏輯的時候，它們只是一些數學理論的實際應用而已！在現代的許多設計理念裡可以看到數學的影子，或許是時候把概念引回純粹的數學領域了。
這些年函數式編程的日趨流行，似乎正是這種思想的一種實際體現。所以讓我們回到最開始的那句話：寫一個功能應該從定義開始。這句話其實是關於數學的，數學是關於定義的，嚴謹的定義帶來嚴密的證明，一個可供證明的定義才是可用的，安全的。集合論群論圈論拓撲學等諸多定義定理使得我們可以在這基礎上構建一個可供證明的安全的，可擴展的穩定系統架構，強大的限制性條件使得每一個功能都能嚴密統合，而不用去關注最底層的實現細節。