程式設計社群最近熱議一個引人深思的案例研究，它揭示了僵化開發方法論的根本侷限性。這個故事圍繞構建數獨求解器的兩種截然不同的方法展開，突出說明了為什麼沒有任何單一程式設計技術能夠解決所有問題。
兩個數獨求解器的故事
測試驅動開發（TDD）的著名倡導者 Ron Jeffries 嘗試使用他偏愛的方法論來構建數獨求解器。儘管寫了多篇部落格文章並在20年間付出了大量努力，他的方法卻難以產生優雅的解決方案。與此同時， Google 研究主管和人工智慧專家 Peter Norvig 用大約20行簡潔、系統化的程式碼就解決了同樣的問題。
對比十分鮮明。 Jeffries 採用增量式方法，先編寫測試，然後逐步構建功能。然而，這種方法讓他走上了複雜的道路，卻沒有清楚理解底層問題結構。另一方面， Norvig 首先分析了高層問題，將其識別為約束滿足問題，並應用了適當的演算法工具。
約束滿足問題（CSP）：一種數學問題，需要為變數找到滿足特定規則或約束的值。
程式設計方法比較：
- Ron Jeffries（TDD）：多篇部落格文章，20多年的迭代，複雜的增量方法，難以達到優雅的解決方案
- Peter Norvig（領域知識）：約20行程式碼，系統性分析，約束滿足方法，簡潔有效的解決方案
系統化方法的根本問題
社群討論揭示了一個更深層的哲學問題。許多開發者都遇到過類似情況，僵化地遵循某種方法論實際上阻礙了問題解決，而不是幫助解決問題。問題不在於 TDD 本身有缺陷，而在於它被應用到了一個需要搜尋演算法領域知識比測試方法論更重要的問題上。
「如果你不知道如何處理問題，你就不會得到解決方案。」
這個洞察觸及了程式設計中的一個基本真理：方法論是工具，不是魔法解決方案。當你已經理解問題領域並能應用適當技術時，它們效果最佳。當 Jeffries 在數獨問題上遇到困難時，這不是因為 TDD 作為概念失敗了，而是因為他缺乏問題所需的搜尋演算法和約束滿足方面的特定知識。
通用問題解決的不可能性
討論將這個實際例子與計算機科學中更深層的理論概念聯絡起來。判定問題（Entscheidungsproblem）在數學上證明了不存在通用演算法來確定任何給定陳述是否可以從一組規則中得到證明。這對程式設計方法論有著深遠的影響。
如果我們甚至無法在所有情況下確定程式是否解決了特定任務，我們當然無法建立一種通用方法來編寫解決任何給定任務的程式。這意味著一刀切開發方法論的夢想在數學上是不可能的。
判定問題（Entscheidungsproblem）：數理邏輯中的一個著名問題，詢問是否存在演算法來確定任何數學陳述是否可證明。
關鍵技術概念：
- 約束滿足問題（CSP）：用於處理變數必須滿足特定規則的問題的數學框架
- 判定問題（Entscheidungsproblem）：證明不存在通用演算法來確定數學命題可證明性的理論證明
- 測試驅動開發（TDD）：在實現程式碼之前先編寫測試的方法論
實踐中真正有效的方法
成功的程式設計師不是依賴單一方法論，而是構建多樣化的工具包。他們學習針對不同型別問題的不同方法，並培養關於何時應用每種工具的直覺。對於像數獨這樣的演算法問題，理解搜尋技術和約束滿足至關重要。對於業務應用程式， TDD 可能更有價值，因為需求往往不明確且經常變化。
社群已經識別出幾種在不同問題領域中往往有效的實用方法：與經驗豐富的開發者共事、透過形成假設並測試它們來進行科學思考、退後一步獲得新視角，以及簡單地編寫大量程式碼來建立模式識別能力。
社群推薦的問題解決工具：
- 與經驗豐富的從業者共度時光
- 運用科學思維（假設 → 測試 → 迭代）
- 退後一步獲得新的視角
- 編寫程式碼來建立模式識別能力
- 與他人討論想法
- 在有幫助的情況下使用合適的工具，如 LLM
更大的圖景
這個案例研究提醒我們，程式設計仍然既是藝術也是科學。雖然我們有強大的工具和方法論，但它們需要人類判斷才能有效應用。最成功的開發者不是那些遵循僵化流程的人，而是那些理解何時以及如何使用不同方法的人。
數獨事件最終表明，專業知識來自於構建豐富的技術工具包，並培養知道哪種工具適合每種情況的智慧。無論多麼善意的方法論，都無法取代對問題領域的深度理解和在需要時調整方法的靈活性。
參考：Reflections on Sudoku, Or the Impossibility of Systematizing Thought