本文只提供給新手程式設計師閱讀。

多年前的一個 IBM 的老鳥曾經教過我一個 5 分鐘上手的思維習慣，當我聽到以後，醍醐灌頂，驚人天人，一改日常的編碼風格。到現在，它還持續保持在我的日常的編碼習慣當中。

我不知道應該怎麼稱呼這種思維習慣的名字，top-down，自頂而下，或者分治？不管怎麼樣，它的核心是非常清晰的：編碼的時候只思考同一個思維層次的邏輯，在這層完成之後再思考下一層。

它基於這麼一個事實：我們每個人智力是有限的，同一個時間只能思考有限內容的東西，我們都不是天才。由於這個事實的存在，所以程式 bug 就會存在（廢話）。因此，思考問題的時候（編碼）不要跨抽象層級思考，在我們有限的智力裡面現保證這個層級的邏輯正確，再思考下一個。什麼叫跨抽象層級思考，什麼叫同一個抽象層級的思考。我們通過一個例子來看看，假設現在我要編寫程式打車去上班。

首先穿衣服，然後洗臉刷牙上廁所，然後下樓打車。

這句話就算是一個三歲的人都能說出來。上面的描述是在同一個思維層次，把“打車上班”這個事情分成了幾個符合順序和操作邏輯的模組和動作，我的大腦能夠承載這些邏輯，這一套邏輯下來就能夠把這件事情完成。於是我把它寫下來：

def goWorkByCar () 
    dressUp() 
    wash() 
    goDownstairs() 
    goByCar() }

這個抽象層次的東西已經完成了，我看這個函式就知道這個操作的順序和邏輯是什麼，甚至還不用註釋。我們有四個函式都是沒有完成的，它們的具體實現就是下一個抽象層次的東西。我們現在下到下一層，看看 dressUp

從櫃子裡把衣服拿出來，先穿上半身，再穿下半身。

符合正常的操作，不錯：

def dressUp ()
    clothes = takeClothesFromWardrobe()
    dress(clothes.up)
    dress(clothes.down)

我們看看洗漱怎麼做：

上廁所，刷牙，洗臉

def wash () 
    urine()
    brushTeeth()
    washFace()

下樓呢？

我要先出門，然後鎖門，然後坐電梯。

def goDownstairs () 
    openDoorAndOut()
    lockTheDoor()
    takeTheLift()

打車呢？

用手機打車，然後坐車走人

def goByCar () 
    car = callACarByPhone()
    takeTheCar(car)

...然後再用這種方式實現像 brushTeeth 和 washFace 具體的實現，想想它們需要什麼操作。

你會發現我們不停地在填函式，函式裡面又不停地出現新的函式需要我們去完成。每個函式體裡面的操作都和這個函式所要完成的目的相關，在一個函式裡面，我們只關心這個函式需要完成的目標所需要操作。例如“打車上班”這個任務所依託的 goWorkByCar，我們在這裡並不關心怎麼刷牙，因為它是下一層的東西，我們只關注完成“打車上班”這個目標需要哪幾步。如果我們刷牙、開門這些操作都放在這個函式裡面，那麼一開始就會陷入無限的細節當中而失去了主要目的的關注，而且大腦也無法承載如此複雜多端的細節，處理不好就很容易出現 bug。

而這種思維方式可以讓我們不停地把一個大的任務在同一個層級做分解，保證這一層的步驟和邏輯正確以後，然後再下一層分解，最後其實是一個樹狀的結構，樹的葉子結點才是具體的程式碼演算法實現。在編碼的時候，我只用我有限的腦力關注當前層級的任務，不關注上一層也不關注下一層的細節。

這樣的程式碼寫出來不僅 bug 少，邏輯清晰而且還很輕鬆，因為你每一層思考的東西其實都很簡單，不知不覺就把程式碼寫完了。為什麼很多人覺得程式設計很難，因為你接到一個“打車上班”的任務以後就開始腦子裡面就填滿了刷牙打車穿衣服這種不成邏輯和順序的任務，並且都把它寫到一個函式裡面去。

接到任務以後你可以像上面一樣用人類語言描述一下如果你要解決這個任務，你需要什麼步驟。這些步驟才是這一層任務的關注點。例如跟女朋友看電影：你要先看看有什麼好電影，然後再約女朋友，再買票。

（UPDATE：有朋友說這裡第一步應該先找女朋友，同意！！必須同意！全身同意！每個細胞都同意！）

當你寫一行程式碼的時候可以經常看看你的函式名，你這行程式碼和你的函式名所代表任務的是不是同一個邏輯層次的東西，不是的話，把它分出去。