IT人如何修煉程式設計的內功[2]

ok了，這我們是不是可以理解到，計算機程式設計，其實首先是人的工作，當我們遇到一個服務需求，我們人來做一次，嗯，獲得一個比較滿意的結果，然後我們覺得這個動作可以重複，下次遇到類似的問題，照做就好了。於是，我們就安排計算機來做這件事了。是不是這樣？

這是不是說明，程式，其實是在講一件事應該怎麼做，這個做的過程，以及這個過程的含義，其實是人定義出來的，然後通過程式設計，教給計算機來做而已。

我以前經常有種感覺，計算機程式設計，是兩層意思，一層，是程式本身的含義，就是怎麼做事，另一層，是隱含在程式下面的邏輯含義，就是做事的意義，程式只是字面上的意思，而邏輯，是程式段落組合起來，共同表述的一層意思。現在想想，其實就是這個道理。

嗯，既然我們知道，程式設計，就是把做一件事情的步驟，分拆開來，教計算機去做，但，分拆到什麼粒度呢？這個很重要。如果分拆的粒度太細，白白浪費程式設計師的時間和精力，這些都是成本。而分拆得太粗，計算機還是弄不明白，做事不對，就是bug了。

這說明，程式設計有個很重要的概念，就是粒度，也就是我們對問題描述的精細程度。

最開始的計算機是最笨的，學過計算機組成原理的同學大概知道，只要有個累加器，其實已經可以算一臺計算機了，只會做加法計算。因為從數學上，我們可以知道，任何計算，最終都可以演化成加法計算，事實上，現在的CPU,在最底層核心的部分，也還是這個加法邏輯。

這樣做當然沒什麼不好，不過，有個小小的問題，就是粒度太細了。如果每件事情，都要程式設計師去拆解成很細的加法計算，這個工作就幾乎不是人乾的事情了。難道就無解了嗎？

呵呵，前面我們說過，計算機的特點是什麼？無限重複，大家就發現，一個事情，比如7*24,這是乘法計算，但是，我們最終要拆解為加法計算去實現，但是，不是說我們每次都要這麼拆解，乘法計算也是一個工作，有規律的，因此，當我們拆解一次之後，我們當然可以把這次拆解過程本身，編訂為程式，下次遇到類似問題，讓計算機把這個程式再跑一遍就ok了。呵呵，大家以為Intel的CPU裡面的乘法計算指令是怎麼實現的？大家又以為AMD的CPU內部的微程式碼體系是怎麼實現的？

就是這麼一個思維，解決了所有的問題，遇到需求，首先拆分，然後不斷檢索我們以前是不是以前拆分過了，遇到能套用的程式段落，就直接用，不用每次都拆分那麼細，減少工作量，當然，遇到新問題，還是需要自己拆解的'，不過，拆解後，最好把拆解本身，也寫成程式，下次重用。

大家玩各種語言，一般都提供基本庫，這個基本庫，其實就是前人已經拆解過的結果，軟體公司覺得有代表性，可以滿足大多數應用場合，就編訂到基本庫裡面，以後程式設計師直接用，不用自己重複了，大家說是不是這樣？

現在，大家知道怎麼看待C的stdio.h,stdlib.h這些基本庫了吧？C++的iostream是什麼含義，知道了不？MFC知道了不？Java的執行時庫是什麼意思，也知道了吧？

不過呢，這個世界的需求總是很多的，並且，計算機的能力也是不斷在進步，以前不適合計算機做的事情，現在也慢慢變得適合了。因此，大家總能遇到一些新問題，需要自己重新拆解，基本庫中沒有提供，這就是程式設計師這個職業存在的真實含義。幫助使用者不斷拆解新需求，解決新問題。當然，庫本身也在進步，不斷把已經被證明拆解成功的問題，修補到庫中，避免以後的程式設計師做重複工作。就這麼簡單。