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

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

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

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