程序員怎麼知道用什麼方法解決問題？

01-11

設計一個程序，怎麼知道用哪種數學和物理方法解決？兩者怎麼結合起來？例如做遊戲怎麼會想到矩陣那方面。數學建模求一個城市的警車分布，一開始怎麼想的?給你一堆零件，怎麼把它變成能用的成品？
拓展出來就是發明家當初是怎麼想到方法的，例如光為什麼能傳輸數據？又是怎麼傳輸數據的?

你聽過撞大運式編程和面向運氣式編程嗎？

總結了下大家的答案，基本上分為以下編程方法：

1.面向靈感編程

2.面向佛祖編程

3.面向運氣編程

4.面向deadline編程

5.面向窮舉編程

6.面向Google編程

7.面向stack overflow編程

8.面向他喵的睡一覺明天再算編程

9.面向他喵的老子不幹了編程

10.面向他喵的這代碼哪個傻逼寫的編程

11.面向他喵的我果然是天才這都能寫得出來編程

---------------不知道什麼叫分割線------

不知不覺拿了那麼多贊。為了回饋廣大知友的厚愛，我決定祭出我珍藏多年的鎮樓佛祖，供大夥在沒靈感的時候可以面向佛祖編程。逃）

程序員一般都有這樣的覺悟，我不可能是第一個遇到這種問題的人，別人應當也遇到過，網上看看別人怎麼做的。

如果網上找不到，也許的確是前沿領域，但更可能是思路錯了。

靠 Stack Over Flow

作為程序員acm前玩家和數學建模競賽前玩家的回答。

有一種東西叫做演算法。英文名algorithm，直譯叫做「計算的節奏」，描述的是如何一步一步解決問題。它不是編程里才有的概念，而是從小學做應用題就開始學習的一種分類：一個數學問題，通過轉化形成若干個有成熟解決方法的子問題，然後按一定流程解決這些問題，再把結果組合轉化為原問題的答案，這就是演算法。

沒錯，演算法也是一種數學模型，是可計算的數學模型。我的大多數論文里模型的建立都是如下步驟的：原問題-》數學描述-》數學模型-》計算模型-》評價模型-》解答。這其中計算模型就是描述了演算法的分析推導過程，換了個說法而已，並不稀奇。因為文章參加競賽都能獲比較好的獎，我想這個結構是沒錯的。

真不要覺得數學建模是個單獨的學科，它是我們解決任何問題都需要經歷的一個階段而已。編程解決實際問題過程中內含了數學建模，只不過大家一般不這麼說，只是用設計演算法這個說法代替了而已。

熟悉你要處理的對象領域，定義要處理的問題
進行抽象和建模
按照建模實現

第二點中的「抽象」「建模」這兩個辭彙看起來很屌是不是，用白話來說，就是從有限的事例中，總結出通用特性，再用這些特性來描述這一類的事物。

所以，題目中的「程序員」，有些時候一人做到底，有時候會細分出「售前/顧問/策劃」，「架構師」，「開發工程師」來分工這三件事請。

抽象和建模，其實在這三步中都會存在，複雜一點的食物甚至可以分出業務模型，分析模型，實現模型。程序代碼就可以看做是最後的實現模型了。實際上，建模並不是「程序員」專利，而是人們認識世界分析世界的一種通用的思維邏輯方式和描述表達工具。

統一建模語言(unified modeling language)就是程序員常用的一種（多虧up和xp？），有段時間曾被it界炒得很火，但是他其實也是一個通用的，用來描述世界的工具方法。很多人被其圖形所迷惑，其實真正的意義在於背後的思維方式——把所有事物按照固定規則來分解和描述。

ps: 其實和@Coldwings 答案想表達的意思差不多，就是「建模」。

挺懷念搞OI/ACM的時候花一周的時間就為了自己獨立去解決一道題……

不知道什麼方法才是最好的，但是面多無數次WA、TLE、MLE之後的AC，你就知道你解決對了！

然後被虐多了，就有所謂的靈感了。

你需要問出正確的問題，答案緊跟著它。

知乎個很奇怪的現象，很多人覺得會寫代碼好像是很牛逼似的，其實對真正的大神來說，寫代碼從來就和鍵盤打字一樣簡單，而真正的問題在於寫什麼。

個人以為，大多數程序員的瓶頸在於代碼之外的知識。

沒有人會一開始就知道怎麼解決問題的, 但是你會發現一個現象: 初級程序員總是在找怎麼解決問題, 中級程序員在已經有的方案中選擇, 高級程序員懂得結合大環境挑選一個成本最低的方案

所有的這些的核心就在於積累. 只有看的代碼, 方案, 經歷的項目多了, 自然就會知道怎麼解決問題了.

三點：

1：靈感，我認為一個問題思路的確定，必須要有靈感和直覺。但是很多人覺得靈感和直覺是無法把握，玄之又玄。所以，要學會刺激靈感，確保靈感的獲得。我主要通過這樣的方式來刺激靈感：(1)遍歷大量相關資料，尋找相關信息 (2)參考相關問題的解決方案 (3)冥想，發散思維。這裡應該重視自己獲得靈感的方法。

2：篩選，這裡主要利用邏輯思維，篩選出真正靠譜的思路。可以在腦海中預演一番，想像如何從這樣的方案出發，一步步下來會得到怎樣的結果。

3：實施，真正著手解決問題。在此過程中，注意反饋，再以此刺激靈感，重新設計解決方案等。重複1、2、3，直到問題解決。

建模+抽象+經驗+靈感+面向佛祖編程

前人的經驗

頓悟

腦洞

悶聲作大死

從上到下降序排列

C/C++: Segmentation Fault Driven Development

Java: NullPointer Exception Driven Development

按照順序：書本，Google，靈感

腦洞

基本靠靈感

基本靠谷歌。

我遇到不少一時半會想不通，網上也查不到的問題的時候，基本上都是睡一覺，第二天起床的時候就想通了。。

猜?