我們在前面這樣說。
確定大架構(Module)。
將其細分為具體領域(Class)。
在其中定義實際行為(Method)。
這種方法顯然是有效的。
然而，讀者可能會有這種感覺。
"但是... 仍然覺得困難和沉重。"
"我還是不太明白應該如何實現整個系統。"
"我不知道應該如何分解細節功能。"
這是正常的。
因為Module-Class-Method是
"建立結構思維"，
現在需要的是
在這個結構中
"開始實際實現的思維"。
這裡涉及到兩個概念。
偽代碼(psuedo code)
TDD(測試驅動開發)
這兩者在進行開發時
極大地減輕了壓力。
1) 偽代碼 - 先將思維寫出來，而不是寫代碼
偽代碼字面上是
**"不是真正的代碼，但看起來像代碼的文字"。
我們不是直接寫出實際運行的代碼，
而是先這樣寫。
例如，如果要創建“登錄功能”：
用戶輸入電子郵件和密碼
在數據庫中查找具有該電子郵件的用戶
比較密碼是否正確
如果正確，創建登錄成功狀態
否則顯示錯誤消息
這不是Ruby也不是Python。
這只是"思維流程"。
然而，這一行一行
很快就成為Method，
成為Class，
並進入Module結構中。
只需按照大綱逐步記錄小操作，就已經解決了一半的問題。
這就是偽代碼的力量。
偽代碼的最大優勢
可以設計功能而不需要瞭解代碼
可以將複雜功能分解為簡單語句
消除了"應該從哪裡開始"的不安
減少了實際編碼時的錯誤
寫代碼好的人
不是寫代碼好的人，
而是在寫代碼之前能清晰解釋問題的人。
2) TDD(測試驅動開發) - 先寫測試，後填寫代碼
TDD是這樣開始的。
"首先用文字定義所需操作，
然後在以後編寫通過該操作的代碼。"
這是顛倒的順序。
例如，要創建“加兩個數字的功能”，
首先這樣寫測試。
expect(add(2, 3)).to eq(5)
這句話這樣說。
"應該有一個名為add的功能"
"放入2和3"
"結果應該是5"
這個測試當然一開始會失敗。
為什麼？因為沒有add函數。
然後現在為了解決這個失敗，
添加最少量的代碼。
def add(a, b)
a + b
end
然後測試變為綠色(成功)。
這個過程是將“將功能分解為小單位進行開發”的
方法自然地刻在大腦中。
TDD的強大效果
不需要一次創建大型功能
只需考慮小功能單元(Method級別)
思維變得清晰，錯誤大大減少
就像自動駕駛輔助系統一樣，幫助檢查“我做得好不好”
功能變得更複雜時，價值更大
換句話說，TDD是
將大問題拆分為小塊的最有效方法。
偽代碼 + TDD = 開發思維方式就像組裝樂高積木一樣
如果將這兩者結合起來，
問題將變得非常容易。
1. 使用偽代碼記錄整個流程
→ 想像製作樂高說明書。
2. 使用TDD逐步實現每個功能
→ 想像一塊一塊地拼裝樂高積木。
這種方法是
Module → Class → Method的結構
最穩定的實現工作流程。
編碼不可怕。
因為所有問題都是
分割成小塊
一個一個成功地完成這些塊
整個自然而然地形成
讀者在這裡獲得領悟
"啊...我一直試圖一次完成，所以覺得困難。"
"先用偽代碼解釋，然後一個一個成功地實現，
即使是複雜功能最終也能完成。""如果像樂高一樣組裝...
我也可以製作大型項目！"
一旦有了這種領悟，
讀者將不再在恐懼中開始開發。
取而代之的是擁有“分解和構建思維方式”。