如何培養編程所需要的邏輯思維？

01-04

作為一個軟體工程的學生，雖然專業課（C，數據結構之類的）學得算是過得去吧，但是始終覺得沒有建立起編程所需要的邏輯思維。也許跟我從小數學不好有關。打個比方吧，簡單的問題可以很快搞定，但是遇到較為複雜的問題，就很難將其抽象出來，總感覺腦中一團混沌。為此甚是苦惱。但因為個人實在喜愛這個專業，所以從未考慮放棄或者轉行，只希望能夠有一天開竅，融會貫通。可是最近自學python，也還是找不到那種感覺。希望大知了們能給點建議。

你要允許自己做正常人。

很少有人能單單通過所謂「邏輯思維」從複雜問題快速找到抽象的，如果有這樣的人，他的經驗，工具，方法和直覺通常起到比邏輯思維更重要的作用。寫代碼需要邏輯思維，但解決複雜問題更需要理解分析，寫代碼只是解決問題比較靠後的步驟。所以不急著寫代碼，也不急著找抽象，先試著理解問題本身，而不是下意識地想把問題套進已知的，熟悉或不熟悉的工具，那樣是本末倒置的。

多數情況下，只要有一點耐心，理解問題並不難，這個時候既是邏輯推演，更是探索發現。

比如交通燈控制，是一個不那麼簡單的問題，不急著找模型，也不急著編程，想一想一個交通燈有幾種狀態，一組交通燈有幾種狀態，不同的路口的交通燈有幾種狀態，把具體的例子列出來，你大概會有一個概念：那就是你要寫交通燈管理程序本質就是一個狀態管理的過程。這個時候還沒有得到適合編程的抽象，但你已經積累了對輸入和輸出的認識，接下來可以寫一點簡單代碼或者偽代碼，把各種case的邏輯都單獨實現一遍，把各種狀態之間的轉換的條件和過程勾勒出來，從這裡觀察他們在數據和流程上有沒有共性，有沒有可以優化的餘地，這樣你就慢慢地找到你要的抽象，然後看看你熟悉的工具（比如編程語言）提供了什麼樣的數據結構和編程範式最適合去實現這樣的抽象。

把問題具體化，尋找具體的輸入和輸出，具體的狀態變化。具體化了的問題更容易分解，分解以後的問題更容易分析；先分析再歸納比不分析直接歸納更有操作性，你的「邏輯思維」才能派上用場。

這本書有很多這樣的例子

How to Design Programs (online)

z.cn

How to Design Programs: An Introduction to Programming and Computing

Problem Solving 101: A Simple Book for Smart People

這是一個免費的解決編程問題的視頻（有交互）教程

https://www.udacity.com/course/viewer#!/c-cs101

首先，建議要精讀或者精學三門課程：離散數學數據結構編譯原理。所謂的精讀或者精學，不是說簡簡單單為了應付考試的學習，而是對每個細節每項內容都窮究其理，融匯貫通。精學這3門課程的本身就是邏輯思維和抽象思維能力的很好鍛煉。其中前兩門課程，其知識本身在未來也有大用，編譯原理本身作為一般程序員用到的機會可能不多，但是學編譯原理真的很鍛煉邏輯思維和抽象思維能力。

其次，可以多玩一些抽象類，數字類的遊戲，例如數獨。

再次，多精讀一些好書，尤其是設計類的書，推薦《設計模式》，邊讀要邊思考，不是灌輸式的讀書，是思辨式得讀書

再再次，花大量時間去優化代碼，不管是自己的還是別人的。用不同的方式，不同的思路，不同的演算法，不同的結構去改寫和優化代碼。尤其是演算法類的代碼，系統控制類的代碼。

有一本書，叫金字塔原理，

不止編程適用，

平時生活上的邏輯，工作上的邏輯，各種，都適用。

我喜歡下載pdf高清格式放到pad里看，用cabinet這個軟體看，這軟體挺好的，有各種標註。就是有個缺點，打開300M的這本書，有點慢。。

要是有人有更好的閱讀軟體，可以推薦下下咩

大晚上照的，不清晰，見諒

不說了我要去看了?^???^?

////////

其實我感覺有點跑題

在打好基礎的前提下，適當學一下幾種思想不同的編程語言。開闊一下眼界，不要把自己局限在一個小圈子裡。關鍵還是要自己有動力，肯努力才行，知道成功方法的人很多，成功的確不多

我分享一下自己的經歷:

第一次編程思維突飛猛進是在學習處理器架構之後，我知道了處理器為了完成程序的執行需要哪些邏輯結構，需要哪些指令，知道了處理器實質上是在求解算數邏輯問題的序列。從此學到的定義就不空洞了，心裡也就清楚了，無論代碼寫成什麼樣子，它本質上還是一個求解算數邏輯問題的序列。之後，看到需求，我就先把要解決的問題分解成一個由小問題組成的序列，使得求解這個序列與求解原問題等價，然後一直迭代，直到每個小問題都是算數邏輯問題，然後就可以開始寫代碼求解這些算數邏輯問題。寫完整個序列，寫的同時仿照處理器架構編寫好求解問題所需的邏輯結構，程序就完成了。

第二次突飛猛進是因為正在讀一本書，《Code》，中文譯名《編碼的奧秘-隱匿在計算機背後的軟硬體語言》，讀了這本書我又意識到了，我寫的代碼實質上是對「動作」和「信息」的編碼，在解決一個問題之前，先想一想必須的「信息」和「動作」是什麼，然後再想想，該怎麼用數據和運算來給它們編碼，編好碼以後，就可以用數據和運算來表達求解問題的過程，表達完了，求解這個問題的程序也就寫好了。

波利亞的《怎樣解題》是本很不錯的書，提供了一種探索式的解決問題的方法論。另外，解決問題的核心在於一個因果關係的轉化，就是找到已知的條件到最終結果的橋樑，這個尋找的過程可以很多技巧譬如將複雜問題分解為若干簡單問題，先解決問題的一部分入手，假設問題解決而倒推需要滿足的條件等等。。。。這些不僅是編程，做很多其他工作都是必要的。

設計模式主要是意會啊意會。

最好使設計模式隨心所欲完全融入代碼，而不是生搬硬套

另外，MVC真的很好用

抽象能力是需要鍛煉的，而且複雜問題不見得能分解成簡單問題。我覺得你可以試著鍛煉怎麼把一個問題在頭腦中全部建立起來的能力。比如一些數學問題或者演算法問題，如果你能在紙上寫出問題的答案，試著把紙丟開，從頭在腦子裡把整個問題再解決一遍。用這種方式解決一些演算法習題，慢慢地你的抽象能力會有上升的。

好好打基礎吧. 把數據結構, 演算法, 面向對象等等都學好. 然後再多學幾門語言. 別太著急, 現在正是你打基礎的時候.

1.編程技術方面的知識作為基礎是必須的，如果沒有這方面的知識積累，你在解決編程這方面問題時很難產生一個好的思路；如果沒有關於這方面的任何知識，那就完全不可能產生。

好的思路說白了最終還是來源於過去的經驗和以前獲得的知識。

2.至於你說的簡單的問題還可以解決，複雜的問題就感覺混沌。推薦一本書是波利亞的《怎樣解題》，也許能讓你對正確思維這方面的問題得到些啟發。

送你三個字：畫腦圖！

對於想成為一名優秀的編程人員來說，邏輯思維非常重要，本質上寫程序就是在寫邏輯嘛。培養邏輯思維，主要是多思考，這個思考有幾個方面的，

1 思考並學習數學方面的基礎，這裡不但包括微積分，線性代數，概率統計，還包括對於計算機很重要離散數學，組合數學等，我最近在看《具體數學》，建議你可以試著看一看，這本書不要奢望一次性看懂，要做好看幾遍的打算，看一本書的關鍵不在於你看了多少，而在於你思考了多少。

2 提高思考的能力，這其中包括學習各種思考的基本方法，培養良好的思考習慣，這裡可以看看波利亞的《如何解題》，以及follow 劉未鵬童鞋的博客http://mindhacks.cn，當然還要有自己的思考總結以及回顧。

3 多寫代碼，多多練習，特別是在寫的時候，要思考怎麼樣做才能有擴展性，怎麼樣寫比較易於維護，始終督促自己寫優秀的代碼（至少你目前能力所能達到的最優），寫完後可以和別人討論。

提高邏輯思維能力絕不是短時間的事情，要多多思考，勤於練習，我們共勉。

讀毛澤東的辯證法。

數據結構肯定要學好。

另外acm基礎訓練是大殺器

編程如同做事，首先最重要的就是要弄清楚要做的到底是一件什麼樣的事，一定要弄得清清楚楚，不能關靠字面來理解，這一點不容模糊，否則後面的邏輯很容易因各種思考，各種糾結而終止；其次要分析因果，其中最重要的是要分析輸入與輸出的因果關係，這是程序是否能成功實現功能的關鍵點。舉個簡單的例子來說吧，比如我要做用VHDL語言來實現一個四選一多路選擇器，首先我就要搞清楚四選一多路選擇器到底是個什麼東西，並把它用自己最簡潔的語言概括出來，注意是自己的語言，如果我的理解是「四選一多路選擇器就是在四個輸入信號中選擇一個信號進行輸出的器件」，這已經夠直白了，然而這還不夠，思考不能在這裡終止，因為我並不知道如這四路輸入信號是從哪來的，如何在四路中選擇一路，又如何把選中的一路給輸出，這些就是要分析的因果關係，其中的輸入與輸出的關係則可以這麼理解，即輸入就是要輸入的那四路信號，輸出就是要選出來的那個信號，所以關鍵是要選擇才有輸出，這樣的話只要理解了如何進行選擇這一點，就可以得到輸入與輸出的因果關係了，就實現了這個四選一多路選擇器。

大學我都沒有學過計算機理論的書籍，大一我學習的是機械工程，後來轉專業學了電子商務，和軟體關係不是很大。編程完全是自學的，自認為編程要比很多人強。對某一件事情的深入理解後，邏輯自然就出來了。如果你所說的邏輯是像數學推理之類，那麼數學知識是必不可少的。

如題：程序員是一項需要高度集中、高複雜邏輯思維的工種，那麼如何培養自己對問題的分析能力呢

問題本身是需要進行分析的、那麼什麼是問題呢，如題"如何培養自己的編程思維"

那麼首先要知道什麼是"編程思維"

」思維「，我的理解是一種對某種現象在多次發生之後，尋找到的一種規律
」編程思維「就是如何用軟體去解決問題，
需求首先要確定輸入、和輸出。這個求解方程一樣
例如現在很流行的單車模式，我們分析下這個開鎖和解鎖過程

用戶角度：

登錄單車
搜索附近的單車
找到單車掃描二維碼
進入等待解鎖界面
解鎖成功，開始計時，後台開始GPS行為軌道記錄
關鎖、等待10秒作用，手機界面提示解鎖成功

運營人員角度：

登錄系統
根據區域，查詢附近需要維修或者需要轉移單車
轉移單車

開發人員角度

單車與伺服器操作
單車需要上報自己所在地址
伺服器向單車發起開鎖命令
單車關鎖時，向伺服器發起關鎖命令
上面三個要求啊：核心功能就是單車和伺服器是實時通訊的，

用戶和單車
單車掃描二維碼（請求需要開啟的單車序號）
伺服器對用戶身份進行審核，伺服器向單車發送解鎖指令
單車解鎖成功，上報伺服器，伺服器再通知用戶解鎖成功，用戶端開啟GPS跟蹤記錄
用戶手機實時上報行程軌跡
手動關鎖，行程結束。（一般設置手動和自動關鎖）

單車狀態
上報地址
收到解鎖命令
關鎖

核心功能

單車和伺服器實時通訊
單車電力和網路問題，需要分析高、低網路狀況時方案
用戶GPS上傳速率問題
用戶離線下，如何關閉單車
用戶獎勵規則、
行駛距離可以得紅包
在規定地方停車可以得紅包

注意：用戶的所有操作和單車是分離的，也就說所有用戶相關獎勵操作和單車狀態是解耦的關係

一個大致的分析就可以得出一個單車共享模式

作為轉行人士，這也是我應該關注的

普通人的腦容量,大概是5-7,所以比較好的方式是,將你的問題分解為不多於7個子問題,把它們寫下來,再深入到下一層

個人比較同意一種觀點,就是複雜問題的coding更類似於數學題,多見多總結是一個不錯的選擇

大型程序的coding需要系統化的思維,這時候你需要一些指引,這是國內CS教育比較缺失的一塊,很難想像一個較大的程序,能夠經由一個沒有任何經驗的人做出來,就像一個從沒了解過房屋內部結構的人,僅憑外觀去設計一棟建築

既然是小項目無憂，大項目無從下手的話，那就應該去補面向對象，UML建模，軟體工程方面的知識技能阿。這方面正是軟工與計科及其它工科轉職猿相比的核心竟爭力。

如果純理論難以提高的話，就該找個項目來練手。從小項目開始，不斷加需求，改界面，前後端分離，BS,CS,MVC,框架，資料庫優化，重構為大項目。

之後?完整一套做下來，你就知道自己的基礎有多差，然後滾回去補理論吧。