《如何解題》（《how to solve it》）是波利亞的經典著作，列舉了很多數學問題，總結了解決問題的主要思路和步驟，即定義問題，設計方案、實現、驗證。雖然全書主要是以數學問題為例，但其思路適用於生活和學習的其他方面。比如在軟體開發領域，我們通常也是按照這四步。首先收集客戶需求、找到客戶的痛點和要解決的問題，然後進行產品設計、架構設計和每個模組的詳細設計，接下來就是編碼實現和最終測試驗證了。
這四步法的確非常有效，然而很多時候，現實世界的問題與純粹的數學問題還是有很大差別的。最近讀了一些其他這方面的書，也自己思考了很多，發現其實有三點是可以補充的。
以前我也曾有過類似得想法，就是感覺科學家與我們的工作有很大不同。比如我們在寫**時本質上是在「建立世界」，我們指定這個世界的一切結構、執行規律。但科學家本質上卻是在做「逆向工程」，就像在用反彙編解構世界一樣。在《conceptual blockbusting》一書中，作者提到了類似的觀念。
所以其實，有時我們解決問題時並不是像解決數學問題一樣直接，一開始就知道自己面對的問題。我們經常是從現象（result）出發，要先分析出到底**有問題（cause）。而且經常我們一開始發現的並不是根本原因（root cause），要順著因果關係的鏈條一直找下去。
現實世界往往不像數學問題那樣純粹，做一道數學題可能只是為了好玩、鍛鍊大腦、打發時間，但也可能是為了應付老師和考試。現實世界也是一樣的，我們要解決的問題背後，都是有乙個最終目的的。這個目的可能很明顯，也可能是隱含的。但最重要的一點就是，不要以為要解決的問題就是最終目標。
定義好問題後，往往解決問題的路有很多條，現實世界裡問題的答案常常不止乙個。這時想想你的目標是什麼，就會對你的思路選擇起到很大作用。而且目標是分長期和短期的，解決方案要綜合考慮兩者，不能犧牲其中乙個太多。比如你要解決的問題是如何設計一款能吸引客戶的xx產品，你的短期目標是盡快研發和推出一款產品來搶占市場，那麼乙個耗時耗力的方案可能不是乙個選項。但如果你現在就很看重長期目標的話，可能乙個快速但質量很一般的方案也不在考慮之內。
在《principles》一書中作者提到，解決問題時一般要問自己：這是乙個問題嗎？是否必須要解決嗎？有沒有辦法繞過它？如果確實是問題，無法繞開的話，接下來要做的才是遵循《如何解題》裡的思路去解決。很多時候，這種反問會幫我們避免浪費時間去解決乙個錯的問題。即便我們還是要解決這個問題，你也並沒有浪費時間。這些反問能幫你更深地理解，為什麼要解決這個問題，不解決的後果是什麼。所以，下次當你面對乙個問題時，試試這「靈魂三問」，能幫你親身體會到它的威力。
《conceptual blockbusting》一書裡也有類似的例子，作者設計過一種裝置，結果發現是完全不需要的，他耗費時間精力卻在解決乙個根本不存在的問題！
所以，把整個思路補全的話，應該是有時從現象入手找問題，有時直接拿到要解決的問題。在問題背後，明確自己的目標。在定義問題的過程中，思考是否真的是個要解決的問題。在此之後，按照《如何解題》一書的四步法，完成剩下的設計、實現、驗證三步。
而且整個過程很可能不是一蹴而就，而是多次迴圈迭代的。比如根據設計甚至實現時的反饋，回頭修正問題的定義，於測試驅動開發的反饋迴圈很像。從這一點上來看，解決數學問題、軟體開發流程、以及現實世界中其他問題的解決，真的都是相通的。
快速排序的解題思路
一 分而治之 一種著名的遞迴式問題解決方法。英文全稱 divide and conquer 簡稱d c，它提供了解決問題的思路。使用d c解決問題的過程需要兩個步驟 1 找出基線條件，這種條件必須盡可能簡單 2 不斷將問題分解 或者說縮小規模 直到符合基線提交。遞迴條件 舉例 假如你有一塊土地，它的...
IQCar的實現II 解題思路
上文簡單介紹了iqcar遊戲。接下來將描述用計算機如何求出它的解法。學過資料結構的，第一感覺就是用 深度優先搜尋 或者是 廣度優先演算法 就是不停的嘗試每一種可能，直到到達解。然後將嘗試的過程輸出即可。仔細觀察上文的，發現，每一輛車的可能性位置可能性非常少 由於車子只能前後移動，故長度為3的車子只有...
我的騰訊looksalike解題思路
賽題 分析 1.使用者是多個,廣告也是多個,乙個使用者可能對多個廣告產生行為,乙個廣告也可能被對多個使用者點選,這顯然是不好處理的.我們假設只有乙個廣告,那麼他對於使用者而言只有兩種情況,被點選和不被點選,這就成了乙個二分類的問題.我們把使用者特徵與廣告特徵拼接,作為x,把與x對應的是否點選作為y,...