程式設計的具體化與抽象化分類：系統

以我寫程式多年的歷史來看，寫程式除了靠經驗的累積以及開發工具的使用之外，最重要的就是邏輯推演的具體化與抽象化兩個方向，這兩個方向若能互相契合，這個軟體系統就能把錯誤減到最低，而且跑起來也特別的順暢。

首先先想一想我們再解一道代數數學的題目時，總是用一些抽象化的方法，先盡量把因數分解、多項式的加法變成乘式或者除式，然後把就可以找出答案來，但是這個過程除非經過大量的死背經驗，不然很難想出這些抽象的方法，這也是大多數人代數學不好的原因，無法具體化答案。

PS. X^2+2X+1=16 →　(X+1)^2=16 → X=3 or -5

記得我剛學代數的時候，每當解不出答案的時候，就是硬寫了一個小程式，把代數的數值從零開始把代數值填入，利用電腦的快速運算，找出最接近的答案，甚至到了微積分的考試的時候，特別去買了一台可以寫 BASIC程式的計算機來找答案，雖然答案對了，但是解題的過程完全無法交代，所以還是被當掉了！

要寫出一套好的系統，抽象化與具體化的能力一定都要能培養，我看了很多的程式，只是在寫流水帳的程序而已，要什麼功能，就寫一個功能，要一個對話窗，就畫一個對話窗給使用者，到最後程式愈來愈大，雖然這個是具體化的結果，但是所有的程式都沒有模組化，前因後果也沒有考慮，當然系統就不好維護，要改一個程序的時候，甚至都沒有辦法修改，而衍生出一些Bug! 這時候就要適當的加入一些抽象化的概念，想辦法分類然後模組化或黑箱化。

我也看過非常抽象化的程式，每一個模組的分的很好，利用物件導向的程式寫出來，但是看程式就像數學的解題過程一樣，非常的刺激，但是維護起來卻十分的困難，要加一項功能，就要花很多的時間!

一套系統在開發的階段，不可能完完全全的仰賴客戶或所謂的系統分析師的紙上作業，實際在寫程式碼的時候一定會發生困難，利用具體化或抽象化的概念，不要讓自己困在中間，才能寫出一套好維護的系統。

系統架構的構思過程分類：創新、系統

創意的構思過程可以分為感覺構思→邏輯構思→多面構思→靈感構思 這四個過程，而我們往往在一個系統的構思階段便想了很久，做不出來，只要善用這些構思的方法，你很快可以把一個系統的架構畫出來，以便快速的完成一個雛形。

一般的軟體工程師往往會不滿現狀，想設計出一套完美的系統，我們在之前討論用最笨的方法來思考的時候，就是避免大家想的太多非必要性的功能，造成後續維護與發展的困擾，試著想想看當我們早上起床刷牙洗臉吃早餐一直到搭車上班，我們需要用很多的腦力去構思嗎？這就是反射動作，我們在做一項思考的時候，往往就是用感覺構思就已經完成了大部分的事情，可以說是反射動作的思考。

當我們找不到一項東西，譬如說是一本書好了，便要冷靜的回想，什麼時候用過這本書，書本可能放置的位置，從主題意義來想，用各方面的判斷與分析，是不是上大號的時候放在廁所，或是放在公司放在朋友家裡忘記拿回來了，這個構思的階段就是邏輯的構思。

如果找不到我們通常就開始全面的搜索，地毯式的找尋，把全家每一個地方翻過來找，我們在創意會議的時候也常常如此，把所有現有品牌或是競爭對手，把字典的字全部翻出來，一項一項檢討比較，這個就是多面的構思。

至於靈感的構思方法，是我們比較少用的，用不同的角度，在一個突發的狀況下想出一個靈感，好像寫文章文思泉湧，創意猛然向你撲來，這個就是靈感的構思，一般寫程式的時候也就是為什麼有時候去上上廁所休息一下，就會把Bug臭蟲抓出來的原因。

而據我個人觀察發現一般工程師在邏輯構思的階段就往往無法決定是要往哪個方向，無法決定用哪個方法來實作，這個當然是要問問別人的意見，如果無法很快的做決策的時候，一般來講都是先做了再說，當然不要做完了再來測試，要做到一半的時候就要想辦法測試，來看看自己當初想的方向有沒有錯誤。

再來工程師常常犯的毛病就是想的太多，設計一些很少會用到的功能，雖然是多面的思考，但是很少會用的上的，這一點需要做一些測試，來測試我們的程式碼，這一點也是我們目前為止很少做的品質管理工作，來評定我們的程式設計師。

當然撰寫新系統需要一些經驗，看看前人的程式碼是最快的學習方式，用上述構思的方法或許可以讓您更快的了解你的思考架構。

延伸閱讀：【創新】先把自己變笨，歸零的思考