第 １ 節 前言
常常有人問筆者：要學什麼程式語言比較好？同樣這批人在學會某種程式語言後，
又常會問說：接下來要學什麼程式語言呢？為什麼學會電腦語言卻又寫不出程式來呢？
相信讀者中必然也有不少人有類似的問題，但可能找不到適當的答案。因此你這時你
不禁會懷疑：電腦到底可以幹啥？
基本上這源自於一個很簡單的誤解，因為不少初學者認為除了瞭解鍵盤如何使用、
電源如何起動外，學電腦最主要的目的是要學會如何寫程式！而不是用來處理資料、
編輯文書......。當然啦！如果有心人想對電腦科學做更深入的研究，當然是樂觀其成
的，但可惜的是入門者常常是在走錯路後才恍然大誤。這不但浪費時間，也相對的浪費
金錢。有鑑於此，筆者希望能透過這篇文章，讓有心大眾能少走些冤枉路，而加速邁向
成功的終點。
第 ２ 節 你要電腦為你做什麼
為什麼需要寫程式呢？理由很簡單，就是因為你對電腦有所求！希望它能為你作些
事。點子（計畫）的來源可能是前夜周公來托夢，或者是因應他人的需要（例如朋友、
客戶、或是自己）而產生的。你應該詳細的思考一下你對電腦的要求，你希望它作些什麼
事，程式必須有何功能？輸入資料的型式（是圖片、文字敘述、電話號碼......）？輸出
的結果？型式？......越週詳的考慮，對於往後的工作進行會有越佳的幫助。
一般而言，這些雜七雜八的要求可能會顯得十分混亂，特別是由那些不懂電腦的所
開出的規格，更是匪夷所思，摸不著頭緒。而身為工程師的您，你的工作便是分析出程式
的功能。這有點像是室內設計師的工作，你的客戶只可能會告訴你，這裏要擺張桌子，
但不告訴你尺寸；他可能會突然想到椅子上必需要鑲入珠寶，但卻不會去考慮椅子是紅
還是黑的......。因此，充份的溝通是有必要的，軟體工作者應該充份的了解客戶的需要
。當然這點做起來可能很難，特別是當你的客戶是暴發戶型的大老板時，那麼此時必需要
以心理醫師的方法慢慢的誘導出你所要知道的細節。
如果你寫程式的原因是要交作業的話，盡可能的弄清楚文字說明的意義，該達到的
目標一點都不可少，與主題無觀的應予拋開。想一想下面這個問題（這題是七十九年度
程式設計比賽校內初賽的一個問題）：
“設計一程式，以之判讀一般之中序算術式，是否為有效或無效之運算式。
式子中所涉及的運算元暫定為由Ａ到Ｚ或ａ到ｚ的單一字元，可為使用之
運算子則包括加、減、乘、除及括號與次方。程式的輸入為一中序的運算式，
而其輸出為一判讀之結果。”
這邊要特別解釋一下：中序運算式指的是我們一般所列的式子，例如 1+2=3 。
題目就這麼多，條件也說的很明白了。讓我們來整理分析一下它到底要作什麼。
關鍵字句在於“判讀一般之中序算術式，是否為有效或無效之運算式”，說得清楚些
，就是說判斷一個式子是否正確，例如 1 + 2 是對的, 但 1 +* 3 就不對了。另外，
我們必需知道哪些符號是合法的，由“加、減、乘、除及括號與次方”此句中我們知道
可以用“＋”、“－”、“＊”、“／”、“（”、“）”、及“次方”。前面的符號
都沒問題了，但“次方”就麻煩了，因此電腦的符號系中似乎沒有強制限定次方符號，
例如 BASIC 是以 ^ 為次方符號，FORTRAN 是以 **，甚至Ｃ語言根本就沒次方這回事。
此時，儘可能的與試務人員交換意見，或者明白的在你的說明文件中定義次方符號。但
因為這場比賽是以 BASIC 撰寫的，因此便以 BASIC的 ^ 表示了。接著，在“運算元暫定
為由Ａ到Ｚ或ａ到ｚ的單一字元”此句中我們知道一個算式必需以英文符號代入運算，
例如 x=y+z，但相對的，23+12 就是不合語法的了。並且，題目中只要我們辨別出運算式
是否正確即可，不必畫蛇添足，算出到底是多少來。另外題目中並未提到“運算式的來源
”，究竟是經鍵盤輸入或是由檔案中取出呢？但經瞭解後是由鍵盤輸入。而以上就是對
有限條件題目的分析。
在你仔細的分析完這個問題後，你可能會發現解決這個問題對你而言可能是力不可及
，或者是所需時日甚多，無法如期完成，或是有現成的套裝軟體可以立刻解決此需求的...
... 而無論如何，這就是我們所以要分析定義問題的緣故。
第 ３ 節 仔細的思考軟體的結構
經過一番努力後，你已經定出一套完整的規格，此時你大概也有個譜了。然而這只是
第一步罷了，系統結構尚未建立呢！因此別興奮的太早，接下來你應該要把夢想落實，
一步一步的具體化。規劃的目的除了在描繪具體的軟體結構外，重點是要進行模組的建立
，資料格式的規劃，模組間的通訊協定（Protocol）等工作。
關於規畫軟體，有很多理論上的設計方法。但有諺曰：『一圖勝過千言萬語』。畫圖
是幫助我們規畫程式的最佳方法。幾個比較著名的方法，例如流程圖、拿西－尼得門圖
(Nassi-Shneiderman)、及下面要談的 DFD 圖。
第３．１節 ＤＦＤ圖
一般的軟體，最基本上可分為“輸入”、“處理”、“輸出”三部份；所謂的“資訊
”，其實所指的就是經過處理後的“資料”，因此ＤＦＤ圖便應運而生了。ＤＦＤ圖的
精神就在於資料流程的規劃、各處理單元的動作、並且可以作更深一步的切分。ＤＦＤ圖
有幾個符號，介紹給大家認識一下：
┌──┐
│ │ 外界個體 系統輸入的起點或輸出的終點
└──┘
╭─╮
│ │ 轉換程序 執行輸入資料處理轉換成輸出資料的單元
╰─╯
╭───→ 資料流 用以連接不同的程序，以表示資料傳送的方向
──╮ ╭─→
↓ │ 資料儲存所 資料儲存的地方，箭頭表示資料的來源及輸出的方向
═══════
舉一個銀行自動櫃員機的 DFD 圖：
┌────┐ 提款卡密碼 ╭───╮ 付款訊息 ┌──┐
│ 終端機 │──────→ │櫃員機│ ────→ │點鈔│
│ 鍵盤 │──────→ │ 系統 │ │付款│
└────┘ 提款金額 ╰───╯ └──┘
《第 A 層次的 DFD 圖》
這是最初步的，未經細部規劃的。但一個雛型已經產生了。下一步工作是逐步的將
DFD 圖分解成細節。
┌────┐ 提款卡密碼 ╭───╮ 帳戶資料
│ 終端機 │─────→│總行電│←─────╮
│ 鍵盤 │──┬──→│腦查核│────╮ │
└────┘ │ ╰─┬─╯ 帳戶 │ │
│提款 │查核 │ │
│金額 │結果 ↓ │
│ ↓ ══════
│ ╭───╮ 銀行的輔助除存裝置
╰──→│櫃員機│ 例如磁帶機
│ 電腦 │
╰─┬─╯
│ 付款訊息 ┌──┐
╰──────→│點鈔│
│付款│
└──┘
《第 B 層次的 DFD 圖》
┌────┐ 提款卡密碼 ╭───╮ 付款訊息 ┌──┐
│ 終端機 │──────→ │櫃員機│ ────→ │點鈔│
│ 鍵盤 │──────→ │ 系統 │ : │付款│
└────┘ 提款金額 ╰───╯ : └──┘
. ...
. ...
. ....
. :.
. ╭───╮ 帳戶資料 .
提款卡密碼 │銀行電│←─────╮ .
─────→│腦查核│────╮ │ .
─────→╰─┬─╯ 帳戶 │ │ .
提款金額 │查核 │ │ .
. │結果 ↓ │ .
. ↓ ══════ .
. ╭───╮ 銀行的輔助除存裝置 .
. │櫃員機│ 例如磁帶機 .
. │ 電腦 │ .
╰─┬─╯ .
│ 付款訊息 .
╰─────────→
《資料流程的分解》
第３．２節 由上而下的程式設計 (TOP-DOWN DESIGN)
由上而下的設計哲學，是一種逐步細緻化的設計概念。就像你寫生時，必然是先打
草稿，既而以大號畫筆勾勒輪廓，再用更細些的筆描繪出細部構造。很少有人是拿細筆
一筆一筆刻劃的，即使有，也不容易畫得好。可能的結果是畫虎反類犬。有個人找了位
建築師幫它設計一幢洋房；數週後，他去找建築師看看設計圖。於是建築師便拿了張圖
告訴他說：“讓我們來看看廁所屋頂的水管設計圖”。“可是我還不知道房子到底是什麼
樣呢？”顧客說。誠所謂綱舉目張，當結構設計好之後，細節就可一一浮現了。並且，
由上而下的方式，不僅運用於初期的規劃，也應用於編碼 (CODING)、測試時。
一般而言，一個完整的程式是具有“層次性”的。大部份看來就像例圖這般：
（當然實際情況會複雜多了）
┌───┐
│主程式│
└─┬─┘
│
┌─────┼──────┐
│ │ │
│ │ │
│ │ │
┌───┴─┐ ┌─┴───┐┌─┴───┐
│主要模組Ａ│ │主要模組Ｂ││主要模組Ｃ│ ．．．．．
└─────┘ └──┬──┘└─────┘
│
┌───┴┬─────┐
│ │ │
│ │ │
┌─┴───┐
│次要模組Ｄ│．．．．．．．．．．．
└─────┘
（模組在下一節介紹）
因此我們對一個程式的結構應該是由頂端主程式開始思考，再逐步的往下深入，像
蓋房子要先打地基，再建一樓，再建......如此一層層的堆上的。在作由上而下設計時，
要避免“向下思考”，也就是說先不要考慮下一層模組的工作。並且也不要在規劃時期就
急著編碼。不然何必先規劃呢？
同樣的，當程式在編碼 coding 時，則能夠先寫上層的模組，再繼續往下寫。寫好
一個上層模組後，可以先進行模擬測試，完成後再繼續下一步驟的工作。
不過由上而下的設計、編碼、測試都只是大原則罷了。一個專業的設計師真正在工作
時可能也會由下而上的設計、編碼、測試。為什麼呢？因為我們可能會須要一些低階的
副程式，例如視窗副程式、繪圖驅動程式、通訊程式等等，不過要注意的是，這種由下
而上的寫作方式依然還是得在由上而下的訂定整體結構後才實行，不然常常會發生上下
模組無法銜接的情況，這就像開挖隧道一樣，你可以分兩組人馬分別從兩端開挖，但精密
的測量和協調絕對是必需的，否則將會出現兩條隧道......。
第３．２節 結構化的程式設計
將到結構化，很多人便會想到“ｇｏｔｏ”敘述的存廢問題。理想中我們的確不希望
見到ｇｏｔｏ的存在，但對於那些老舊的程式語言而言 (BASIC, FORTRAN, COBOL...)，
去除 GOTO 敘述是幾近不可能的！
那麼到底結構化程式設計的本質是什麼呢？在結構化設計的理論中，任何一個程式的
流程都可以被分類為三種形態：循序、二元分歧、迴圈。也就是說經由這三類的基本指令
就可以構成一整個程式。
│ │ │
│ │ │
↓ ↓ ↓
┌────┐ ／＼ ／＼
│ 處理 │ ／ ＼ ／ ＼
│ 方塊 │ 〈 判別 〉 ┌→〈 〉
└────┘ ＼ ／ │ ＼ ／
│ ＼／ if │ ＼／
│ │ │ │
↓ │ │ │
┌──┴──┐ │ ↓
then │ │ else │ ┌────┐
│ │ └─┤ │
↓ ↓ │ │
└────┘
循序結構 選擇結構 迴圈結構
另外，整個程式的流程是極順暢的由起點到終點，而不是用 goto 指令改變程式的
流程。結構化的程式在閱讀上十分容易，因為閱讀者不必跳來跳去閱讀，而是一目瞭然
的！下面附的是一個用Ｃ＋＋所寫的範例，讀者可以感受一下她的優美性：
int main( int argc, char *argv[] )
{
if ( argc != 2 )
{
cerr << "Usage: lookup classname\n" return 1; } Dictionary& classDefinitions = *( new Dictionary ); for ( int i = 0; i < classname =" *(" classdef =" *(" entry =" *(new" definition =" classDefinitions.lookup(" definition ="="" style="color: rgb(0, 0, 255);">第 ４ 節 資料結構與演算法
最近看到不少人都在參加〞電腦擇友〞的活動。參加這活動的男男女女將條件填在
表格上，寄給主辦單位的電腦，處理後將形成〞最佳〞的配對資料。但筆者要偷偷的告訴
你們，要換成是筆者，就根本不會期待這個結果是正確的！當然啦！如果有人因此而陷入
熱戀，那我們應當祝福他們，但請不要告訴他們說：有個姓林的電腦狂說電腦擇友是唬人
的！
諸如電腦如何由眾人中依條件找出配對的方法，或是電腦鼠走迷宮，事實上都是按照
一套已經預先建立好的方法來進行，此便稱為演算法。廣義的演算法解釋是這樣的：凡是
一個程式的執行，必然是按照一定的規則步驟去進行。整個程式的流程便是一個演算法，
但一個大的演算法可以是（或必然是）許多演算法個體的結合。但通常我們常常會討論
一些特殊用途的方法，例如剛剛舉的電腦擇友，數字從小到大的依序排列，乃至於計算機
的微分解法，都可歸類為狹義的演算法。而資料結構與演算法則是一體的兩面。正確來說
是密不可分的，更保守來講演算法就是資料結構，資料結構就是演算法！但若要筆者來分
的話，筆者則將資料結構定義為一個“資料的抽象描述方式”，而演算法則是“處理資料
的方法”。
“條條大路通羅馬”這句話可以說是程式設計千古不朽的銘言啊！因為解決一個問題
的方法必然不會是唯一的，舉例說從台灣到美國，你可以考慮坐飛機，也可以搭船，當然
啦，如果你自願游泳渡過太平洋筆者也不反對。但是“效率”與“實行成功性”便成為
我們必需好好考慮的要素。坐飛機無疑是最有效率的選擇，但卻不適合大量貨物的運送，
因此此時你便得考慮船運。如果你沒錢買機票或船票，那麼游泳可能便是你最後的抉擇了
......。選擇正確的演算法，會使程式的效率大為提高，並且可以確保程式是否能正確
完美的執行。並且對於某些特殊問題的解答將會獲致意想不到的效果。
其實整個資訊科學可以分成兩大類別﹕一是實務派，也就是真正投入工業生產的，
把演算法實際“實作”的﹔另外一類是學術派的，他們的工作主要是研究規劃特定的演算
法，但兩者並非相衝突的。一位好的程式設計師通常也應該是一位好的演算法設計者，
否則他也必需要會正確的引用已知的特定演算法。但很多〞玩家〞倒不重視這些了，他們
總以為程式會跑就好了！這是一個很危險的想法，也是不正確的（但這也是專家和玩家的
分野）。理由就像上面所講的。
不但設計演算法是一們學問，實作演算法（編碼）更是一門大學問！一個好的編碼
結果必然會有較佳的執行效率，例如“壓縮程式”（像 LHARC, PKZIP, PKARC 啦...）
其實大部分用的都是相同的演算法，但其壓縮後的縮減比例和計算速度卻都有很大的差別
，因此演算法實作的重要性自然不在話下。
由於這篇文章不是討論資料結構與演算法的專書，筆者的目的是在給各位讀者一個
演算法上的概念。但相信藉由舉一些著名的演算法為實例必然可以引起讀者較高的興趣。
排序
──
排序法幾乎是每一位學電腦的必修的項目。方法很多，筆者舉兩個極端的例子，它們
分別是“泡沫排序法”和“快速排序法”。假定有一堆散亂無序的數字：（由小而大排）
23,64,2,73
若是用泡沫排序法來解決的話，它會這麼做：依次比較一對數字，如果後者大於前者
，則互換排列；用這個方式從頭到尾循環進行，直到沒有交換的情況發生才算完成。
執行過程：
┌──┬──────────────────────┐
│步驟│排列情況 │
├──┼──────────────────────┤
│ １│23,64,2,73 第一回合 │
│ │^^ ^^ │
├──┼──────────────────────┤
│ ２│23,2,64,73 │
│ │ ^ ^^ 大小互換 │
├──┼──────────────────────┤
│ ３│23,2,64,73 因為發生過交換，所以必須繼續執行 │
│ │ ^^ ^^ │
├──┼──────────────────────┤
│ ４│2,23,64,73 第二回合 │
│ │^ ^^ │
├──┼──────────────────────┤
│ ５│2,23,64,73 │
│ │ ^^ ^^ │
├──┼──────────────────────┤
│ ６│2,23,64,73 並未發生交換 │
│ │ ^^ ^^ │
└──┴──────────────────────┘
另一個解決排序問題的方法是“快速排序法 Quick Sort“，相對於泡泡排序法，
Quick 的效率有明顯的改善。假定有 n 個數字等待排序，若以泡泡排序解決，理論上須
費時 n 平方的基本時間單位，如果用快速排序法來做，理論上所花費的時間大約是 n 的
1.2 次方左右的基本單位時間。當然實作時會有很大的出入，不過，事實很明顯，採用
快速排序法的確能節省較多的時間。快速排序法是如何動作的呢？以一個較簡單的概念
來解釋，同樣是 23,64,2,73 這個數列，Quick 的作法是這樣的：
(A)
取一個數 m 為基準，使得剩下的數字可分為兩堆，第一堆的任一個數字都小於
等於 m，另一個數列中的任一數字都大於 m。
(B)
將 (A) 步驟所分離出的兩個新數列分別再以同樣的方法分割，直到不能再分割
為止。
也就是說，QUICK 採用的方法是一個“各個擊破”的方式。
第４．１節 選擇適當的方法
如前面所提到的，QUICK SORT 的效率高於泡泡排序，但這便表示我們在各種需要
排序資料的場合都應毫不考慮的應用 QUICK SORT 嗎？答案並非肯定的，很簡單的道理：
如果它真是那麼沒用的，它並沒有存在的需要！換句話說，泡泡排序在某些場合可能有用
。而這也是本節討論的重點：適時、適地的選擇適當的演算法。
設計程式時常常必需要分析我們所要處理資料的特性，而採取適當的演算法，換句話
說，程式設計師應該要瞭解資料與演算法的特性。就以上述的泡泡與快速排序的問題來看
，泡泡排序的執行時間與資料個數的關係呈現出一個指數圖形，而快速排序則呈現一個
對數的關係。如圖所示：
︿ ︿
時間│ + 時間│ ********
│ + │ ***
│ + │ **
│ + │ *
│++ │*
└──────> └───────>
個數ｎ 個數ｎ
泡泡排序法 快速排序法
這表示：當要待排序的資料個數ｎ小於某個範圍時，泡泡排序的效率可能會較快速
排序來得快。例如以統計學生成績來講，統計一個班的成績便適用泡泡排序法，因為通常
學生都在五十人上下；但統計一整個年級的成績就適用快速排序了，因為數量極大。
由上例我們便知道演算法對程式執行效率的影響。在電腦科學界中，有一個最廣為
人知的定理便是『空間與時間』的相對關係。在一個理想的環境中，當你在選擇演算法及
資料結構時，便需考慮到：到底是花多一點時間來處理資料還是用較多的記憶空間來爭取
較快的速度呢？舉一個明顯的例子，就以『串列』來說，單向串列的每一個節點僅須要
記住指向下一個節點的位址值（當然也可以指向前一個），而雙向串列則須記住前後兩個
節點的位址，因此雙向串列便較單向串列需要更多額外的記憶體。但有得必有所失，雙向
串列在做“巡視（TRAVEL）”動作時較單向串列便要快了。理由是因為“回溯（reverse）
”節點時，必需從頭計算前一個節點的位址。另一個則可舉前面所提的排序法，做“遞迴
式快速排序”時要耗去不少堆疊的空間，甚至有可能造成堆疊過滿的情況，當然解決的
方式不會是採用泡泡排序的，通常我們都會應用非遞迴的 quick sort 來作。另一個在
生活中常見的實例便是發生在碟式中文系統上，你要是設定較少的字型緩衝區，相對主
記憶體會有較多空間可用，但顯示或列印速度便被犧牲了；反之設定較多的緩衝區供中文
應用，顯示速度固然加快了，但剩餘的可用空間反而少了，這個結果常常導致很多套裝
軟體無法執行。
因此在設計程式時應該考慮將重點放在節省時間還是節省記憶體上。假定你設計一個
在中文系統下執行的軟體，那你可能必需要盡力的節省記憶體了，因為碟式中文系統常要
花去不少記憶空間。但假使你正在設計一個飛機場的航管系統，那便務必求快，否則空難
的發生將會是家常便飯的事......。
另一個選擇演算法所要考慮的要件是“可讀性”的問題。固然選擇又快又小的演算法
是我們的目標，但各種演算法中，不乏高度數學化、不易為人瞭解的方法。例如字串的
搜索法就難倒不少工程師了。想從這篇文章中找出『演算法』這個字串有什方法呢？一般
人類直覺上會先比較第一個字，相符後再比第二個字......重覆這樣的步驟。這種很笨拙
的『暴力法』的確不太好。有個方法叫 K.M.P., Kunth - Morris - Pratt 法，它的工作
方式是將要比對的字串中每個字元的相對位置，再決定比較失敗時要從那裡繼續工作。
另外還有 BM 法、RK 法，說實話並不容易了解，況且效率不會說有很高的差異（其中
ＲＫ法要用到大量記憶體）。因此很多工程師便乾脆繼續用他的暴力法，而捨棄快、但
不易瞭解的方法。理由是因為這些方法可能造成測試上的困難。另外要程式設計師對於
一個不瞭解的演算法加以實作，可能不能得到很好的編碼（當然這和設計師的經驗有關）
。所以便有人認為寫程式應該採取 KISS 的規則來，KISS 是 Keep It Simple and Stupid
之簡稱，而不是 kiss 的意思，就是讓程式的流程簡單而且“樸拙”，這點和我們的校訓
『勤樸誠勇』好像是相通的。
第４．２節 效率的考量
提到演算法，就不得不讓我們考慮到效率的問題。一般對效率的定義是指完成某件
工作所需的時間、空間比。我們可以從幾個方面來討論。
（一）與機器的影響
程式的執行效果在不同電腦上的執行成果，差異是顯而易見的，而改善硬體環境則是
提升軟體效率最明顯的途徑。這也是人類為什麼致力於製造更高速的電腦。例如氣象局
便需要超級電腦，因為明天的天氣總不能等到後天才算出來吧！無論如何，軟體還是應該
盡力地提升本身的效率，而不能依恃硬體的進步。否則仍無法發揮整體應有的效能，甚而
形成系統的浪費。
（二）與程式語言的差異
程式語言對於軟體效率甚至目標的可行性究竟有多大影響呢？這點在計算機科學界
一直爭論不休。但一般而言，在同樣的結構、相同的演算法，用不同的程式語言所編出的
程式大概會有１５％～２０％的影響。這是不是說用組合語言寫出的作品會有較高的效率
呢？非也非也。良好的計劃直接影響了編碼的品質。同樣的模組若同時以組合語言和高階
結構化語言撰寫，一般的結果通常告訴我們採取組合語言實作將發生悲劇！組合語言通常
會多出１／３的花費（花費指的是用了多少記憶體和時間）。科學家發現“編譯程式”的
好壞才是整個問題的關鍵。現今結構化的編譯器對於“最佳化”的處理已經是相當的優秀
了。各位如果手邊有 Turbo C 2.0 和 MSC 6.0 編譯器的話，不妨自己做個比較，你便會
有驚人的發現。同樣的你也可以要求編譯器產生組合語言程式碼，看看編譯器的處理手法
是不是比你用組合語言撰寫來的高明。但專業的應用上，我們常是用高階語言寫好原始
程式，再用組合語言作低階的最佳化，例如繪圖函式這類對速度要求極高的部份。
但考慮一下“維護”與“除錯”，結構化程式便較非結構化程式語言甚至組合語言
來得容易的多了！況且，每個程式必然都會發生錯誤！如果因為求一部份模組的“技巧性
”，而導致整體工程的延宕，是很划不來的。
（三）與演算法的影響
事實上，演算法對於整個程式才具有真正決定性的效率影響，理由在上一節就說過了
，為了避免讀者忘記，請再參考前面的理由。
（四）與軟體結構的影響
與其說是與軟體結構的影響，倒不如看成整個系統流程的合理性。事實上整個資訊
科學所關心的，不僅僅只是程式該怎麼寫，系統運作的方式也是我們所關心的。因為我們
或是一些機關在處理事情的流程和做法上，常常有重覆而不合理的地方。這種情形或許在
人工作業時期可以諒解，但在電腦化的時代只是多餘的浪費罷了。例如說圖書館的書目
管理，一本書至少須要書名卡、作者卡，還有書籍本身的出借紀錄，而借書人的借書證上
還要登記這個人借書的紀錄。各種資料實在有夠多也有夠雜，但如果在電腦上，你還用
這種方法來為每一本書建立各種檔案，真是浪費記憶體的行為。事實上書籍只要一個資料
檔就可以解決了（理想中），借閱人要查詢資料的程序也簡單多了；借書證上也不必填
一堆東西，一切都是由電腦來整理歸類資料。換句話說，系統的合理性，是影響整個軟體
最基本的變因。
第 ５ 節 程式設計
第５．１節 程式語言
程式語言依照年代和特性的先後可以分成四類。各代有各代的特色，也因此在軟體
設計方式上有不同的方法：
第一代 組合語言／機械語言
最原始的程式只是一堆 CPU 所能瞭解的指令集，它們都是數字，不過實在很難瞭解，
像“23 EA 73 66”這樣的數字代表什意義呢？除了 CPU 和天才外，恐怕沒人能瞭解，
因此我們便用一些簡字符號來代表某個機械碼指令，例如 80X86 的 MOV、ADD 等等。
它的特點便是非結構化、極低階的運算方式、但執行速度極快，不過很難為人了解，因此
在設計上常常造成很多困難， 不過許多較好的編譯器都會提供巨集 MACRO，提供較佳的
設計途徑。
第二代 非結構化語言
這代語言的黃金時期是在 1960 和 1970 年代。這時代的作業系統正在發展分時系統
，硬體環境相當嚴苛。BASIC、FORTRAN、COBOL.....都是這類語言的代表。他們的特色是
非結構化，也就是說 GOTO 用的很多，此外缺乏模組化的結構。大家可以看看 BASIC 是
什樣子的，大概也就差不多了。
第三代 結構化程式語言
第三代程式語言起於 1960 年末。這代語言都具有嚴密的區塊結構、更抽象的資料
封包方式、結構化的語法結構、適當的資料形態、程序與函數的結構相當完整。Pascal
是最具代表性的程式語言，事實上它當初設計的目的便是指導人們以結構化的思考方式
來寫作程式，也因此成為研究計算機科學者必修的語言。Ｃ語言一直是我的最愛，它本來
是貝爾實驗室用來發展ＵＮＩＸ作業系統的，但目前許多應用軟體也用Ｃ語言來寫（例如
dBASE)。Ｃ語言不但具有像 Pascal 的結構，它本身具備了一些低階的特性，五十餘個
強有力的運算子，使得這個語言的結構更是完美。
第三代語言還有兩種較特別的族類，一個是人工智慧 (AI) 用的程式語言，另一種是
物件導向程式語言 (Object Oriented Programming Language, OOPL)。人工智慧語言可以
用 LISP 和 PROLOG 為代表。這些語言的特點在於它們對符號處理能力很強，PROLOG 對於
階層性的串列還可以自動回溯。OOPL 則應以 SmallTalk 為代表。Smalltalk 和Ｃ一樣也
是貝爾實驗室的產品。它允許我們將有關的資料與程序（OOP 術語叫方法 METHOD）捆成
一包“物件 Object”，相類似的新物件可以經由“遺傳”舊物件而來。整個 Smalltalk
就有三四百個庫存的物件，一位 Smalltalk 的設計師只要遺傳這些物件就可以了。最近
漸趨熱門的 C++ 則是在這股 OOP 風潮下，由原先的Ｃ語言加強而成的。
第四代程式語言 ４ＧＬｓ
第四代程式語言又較第三代來的高階並且更抽象化。以前程式設計師必需費時於設計
很多演算法。但經由第四代程式語言，設計師只要描述它所要的需求（requirement)，
就可以輕易地設計出程式來，例如 dBASE 等。不過目前大部份 4GL 都用在資料庫或商業
方面，並不易運用於其它的範圍，例如系統程式的設計。不過等將來人工智慧的技術發展
成熟了，相信 4GL 必然會成為主流。
筆者強烈地推薦以第三代以後的語言來設計程式，第三代語言的好處在於它能夠很
簡單將各類演算法實作出來，並且又具有易於除錯和維護的優點。第四代語言則可以節省
大量的時間在細節的設計上。第二代語言如 BASIC 或 FORTRAN 要真和 Pascal 或Ｃ比起
來，實在是很可憐的。
第５．２節 考慮系統
筆者認為有時真實世界的作業環境對於程式設計者常常會是一場夢魘。此話怎講？
因為我們常常看到教科書上不斷的提示說：降低程式對於電腦（機器）的依賴性。這句話
實在說得很曖昧。假如你今天設計一個在ＰＣ上使用的電動玩具，你將會發現各機器的差
異是如此的大，光顯示器常見就四、五種了，還有各家音效卡也不一樣，透過 BIOS 來作
繪圖的工作似乎是很愚笨的一件事，因為像 F-19 這類模擬飛行的遊戲玩起來將會像騎三
輪車一樣缺乏速度感！與系統的相依性越低，可能就必需降低不少效率！這真是一個讓人
傷腦筋的問題。我們實在不得不承認﹕一套軟體的發展的確受限於電腦硬體環境的限制。
筆者提出一些解決的參考方案：將與硬體高度相關的部份獨立成模組；在規劃程式的當初
最好考慮將要採取的系統或是周邊裝置。不過，仔細想想，大部份程式實在不是很有必要
依靠機器，頂多也是一部份罷了！
另一個 PC 使用者常見的問題是在於『編譯器』的問題！特別常見於用ＴＣ的人身上
。雖然程式語言幾乎都有國際標準的語法（例如 ANSI, ISO 等），但移植到各種電腦、
作業系統、編譯器上就會出現『方言』，這導致程式原始碼（source code）的可攜性降
低。這就像是湖南老鄉見到山東大漢一樣，雖然講的都是中國話，但溝通上實在有困難。
解決這個問題有兩點建議：（一）當你開始寫程式時，就必需按標準來寫，即使有部份要
用到方言的語法，必須分開獨立並且要詳細的指明。（二）下定決心，將終身大事托付給
你的編譯器吧。
第６節 撰寫程式的風格
程式設計本質上至少有一半具有藝術創作的特性，好的程式往往就是一件藝術品。
而你，電腦藝術家，具有你自己的風格，你自己的創意，因此你的作品將會處處顯露出
你獨特的個性。
當然這麼說並不是要你將程式『畫』得像畢卡索的作品一樣，但至少你的程式應該
具備一些特性：明確的定義、詳盡正確的註解、善用縮格與空白等等。當然你可以培養出
你特殊的氣質，展現在你的程式中。
註 解
───
註解是說明程式碼內容的文字，明白而清晰的註解使得程式碼容易閱讀與瞭解，
很多人多懶於撰寫註解，他們常見的藉口不外：
我的程式本來就很容易瞭解了
我當然看得懂我自己寫的程式了
諸如此類都不過是推拖之辭罷了！人們常常忘記一些瑣碎的問題，這當然也包括他們
自己的程式在內。到底這個函數的參數代表什麼意義呢？他的傳回值又是什麼？螢幕的
左上角是（０，０）還是（１，１）？ 這些都應是註解的內容之一。但我們須要寫多少
的註解？註解的內容又該有多詳細呢？ Planger 說：『好的註解不能代替壞的編碼，
然而好的編碼是否就能夠取代註解，那就不得而知了。』爛的註解就像撒旦一樣，會給你
錯誤的指引。通常的規則是把註解分兩類來寫：前言性註解（prologue comments）和功能
註解（functional comments）。前言式的註解一般是放在模組的前端來指明該模組的技術
簡明資料，大概包含了：
（一）功能和目的
（二）介面說明
A. 說明參數意義
B. 說明傳回值的意義
C. 所需參考到的模組
（三）資料的規格和限制
變數的使用方式和範圍，例如標明螢幕左上端是 (1,1)....
（四）發展紀錄
誰設計了這個模組，修改的日期和所修改的內容等等歷史資料
功能性註解則是安插於程式碼中來說明某一區塊程式碼的功能。寫註解並不是寫文章
，不必寫的長篇大論，但也不要太簡略到用幾個簡字符號。有部份註解的內容可能是在
除錯時留下來的，這些註解最好在除錯完成後便去除，以免造成誤解。另外關於註解要用
英文還是中文來寫，筆者倒認為“易懂”才是重點，用中文不一定會比較爛。
變數的命名
─────
常常看許多人用了一些毫無意義的變數名稱，像 A,B,C,D,X,Y,Z,PP,SS,TT..
亂七八糟，而這種情況特別常見於初學者。這種習慣不是很好，甚至比那些沒寫註解的
差上一級，當然要是註解沒寫，變數名稱又亂寫的，真應該好好反省了。變數的命名應該
以明白易瞭解為主。許多人為什麼用無意義的符號來做為變數名稱的原因是因為嫌多打
幾個字太累，或是佔空間等等。不過還有一種是較誇張的行為，就是變數名稱寫的有夠長
，例如：AmountOfYear、KiloMeterPerSecond等等，的確是有點矯枉過正，不過還是比
那些用無意義簡字符號來的好。在為變數命名的當初，最好能建立一個『字典』來說明
縮寫與展開字的關係。例如：
KM = Kilo meter = 公里
Sec = second = 秒
rec = record = 紀錄
當然最好能夠將該變數的意義附加在表格後面，建立一個『變數字典』，方便程式
設計工作的進行。
縮 格
───
在結構化的程式中，縮格可以很明顯的分別出每一個區塊，和各區塊間的關係。
例如說：
.... ....
..... .....
if 邏輯判斷 then if 邏輯判斷 then
begin begin
..... 敘述 ..... 敘述
.... ....
..... .....
for 迴圈控制 for 迴圈控制
begin begin
..... .....
....敘述 ....敘述
..... .....
..... .....
end end
.... ....
...敘述 ...敘述
end end
.... ....
....... .......
有『鋸齒』狀的縮格 缺乏『鋸齒』狀的縮格
縮格與不縮格的效果相當的明顯，你要縮多少格都沒啥關係，現代的編譯器都會自動
辨識，但是對於某些程式語言有『欄位』限制的，例如 FORTRAN 等等，會稍微麻煩點，
但可以盡量的作出這個效果來。另一個焦點是在於像 begin 和 end 這一類“標示區塊”
起迄點的位置。以Ｃ來說，它以｛ 表示 begin，以 ｝來象徵 end，結果筆者看到的寫法
就有一大堆：
┌───────┐┌──────┐┌───────────┐
│for (......) {││for (.....) ││for (.) { .... .... } │
│ ..... ││{ ││ │
│ ...... ││ ..... ││ │
│ .... ││ ....... ││ │
│} ││} ││ │
└───────┘└──────┘└───────────┘
＜＜幾種Ｃ程式的縮格＞＞
不勝枚舉啊！筆者是喜歡用中間那個方式，有些教科書則是用第一種，第三種則常見
於只有一行敘述的函數中，這種情況在Ｃ＋＋的教本中特別常見。用縮格時不要擔心這是
否影響整個原始碼的長度等等，這是多餘的。較長的原始碼不會導致程式的效率降低，
但亂七八糟的原始碼是鐵定會出問題的。
運算式
───
從兩個方面來看一個運算式的寫法﹕第一是運算式本質上的複雜度，第二是表示的
方法。以第一個角度來看，這樣的式子：
x = 26 * ( 22 + y * 7 ^ z + ( 164 / 64 mod 7 ) )
實在不太理想，因為太多的括號和不明顯的本意讓人讀起來很辛苦，並且，沒有經過
最佳化處理的式子也會降低不少效率，例如說：
x = 2/3 + 5/3
在這個式子中，電腦必需做兩次的浮點數（簡而言之就是帶小數）的計算，分別是
2/3=0.666666 和 5/3=1.666666，但如果你寫成 x = ( 2 + 5 ) / 3 ，只需做一次
7/3=2.333333 的浮點計算了，而電腦作整數計算遠較浮點計算快，這樣寫效率便提高了。
第二個觀點是表示的方法。特別以Ｃ語言為例是因為它所有的運算符號是眾語言中
數一數二多的，例如以下的邏輯判別式來說實在有夠曖昧：
!x == 3 && y != 6
但是加了括號後就明白多了：
( (!x) == 3 ) && ( y != 6)
善用括號和空白是很重要的！
第７節 除錯與測試
除錯常常是設計師頭痛的來源。每個程式幾乎都不免有錯，不論是生手或老手的作品
都一樣。我們在設計程式之初總會有美麗的憧憬：當我作好規劃，然後編碼，再修改一些
『小錯誤』，這個程式就完成了！事實不然，或許你寫程式的速度的確很快，但你永遠也
無法知道你將會花多少時間和精力在除錯上，這真是一個可悲的事實！另一方面，『除錯
』這件工作即使是在科學昌明的今日，也缺乏一套好方法，和一些好工具來協助我們除錯
，雖然新的除錯工具不斷的在出現，但除錯依舊還是一件令人沮喪的工作。
一般而言，錯誤被區分為語法上的錯誤和邏輯上的錯誤。語法錯誤的原因主要來自
打字錯誤或一些無意義的語法，較嚴重的可能是指令或變數名稱的誤用，不過這種錯誤
一般而言都不太麻煩，絕大多數語法上的錯誤都會由編譯器偵測出來。因此我們較關心
是邏輯上的錯誤。
在講除錯前先說說測試。測試和除錯是兩碼子事，測試工作主要是在運用一些假設的
狀況，來查驗程式是正常或有錯誤，因此測試的方式和測試的樣本就很重要了，因為沒有
正確的發現程式有錯，問題將會在日後如山洪一樣的暴發出來。當測試工作一開始進行，
並不會斷然的立即測試一整個系統是不是正常，因為你一定會發現有錯，但找不出錯誤在
哪，因為程式實在太大了。一般我們會先進行模組測試，等一個個的模組都驗證無誤後，
系統或許也應該沒問題了。測試程式的方式有主要兩種策略：黑箱 (Black box) 和白箱
(White box) 兩種測試方法，互有利弊。
白箱
──
白箱測試的方式就好像拍攝模組的Ｘ光照片後，再仔細的分析。有四個主要的測試
方向：（一）至少將模組中所有的獨立路徑測試過一次。（二）測試所有邏輯判斷的流程
。（三）以『邊界值』來測試模組，例如對於位元組的資料型態，則以邊界值０和ｆｆｈ
來測。（四）測試內部所有的資料結構。簡而言之，白箱測試就是將模組的內容作執行
路徑的分析，因此模組就像是玻璃屋一樣，一覽無遺。理論上白箱測試應該每一條路徑
都須檢查，但實際上卻有遺漏的可能，特別是在大型的模組中，白箱測試的工作更是複
雜，不過白箱測試仍是必需的。
黑箱
──
黑箱測試用來判定程式是否正確的作了我們要它作的事情。經由這個測試程序，可以
驗證程式是否達到我們的要求。例如說我們要測試一臺“換鈔機”，你可以分別投入各種
幣值的鈔票，換出對應的零錢出來。這個時候，用來測試的數據就很重要了！因為你的
測試數據不可能包含將來所有可能發生的情況，但你卻要保證測試能找出所有的錯誤！當
然這似乎是不可能辦到的。所以我們可以拿以前真正實際應用時的數據，例如說拿百元鈔
換十元幣，五百元換五角等等。拿實際數據來測有個好處，就是常見的正確情況和常見的
錯誤情況都包含在裡面了，因此可以證明程式在真實情況下的可信度。當然你也可以產生
隨機資料，不過這些數據可能就不會常見了，例如說拿一億元換一角的情況並不太可能
發生。
黑箱測試和白箱測試看來似乎是相反的測試方法，前者是藉由測試的資料和結果來
驗證，後者則是仔細的查驗程式中每一個步驟。兩種方法都有存在的價值，因此它們的
效用是互補而非互斥的。白箱測試通常應用於程式設計初期，黑箱測試則應用在軟體完成
後。
錯誤是可以分類的，特別是可以用出現頻率來分別，一直發生，常常發生，偶而發生
，甚至發生過一次後就再也不發生的錯誤。而搜索錯誤的方式也有一些常見的方式：
暴力法、往前搜尋法、原因消除法。暴力法是最常見、最沒效率的方法，除錯的人總是
一步一步的從頭追蹤程式，把記憶體中的變數甚至檔案的內容都印出來，或是在程式中
很多地方顯示執行時的情況......當然這種方法可以找到錯誤，但需要很長的時間和很多
精力，不過我們還是會運用這個方法，特別是在一切都絕望的時候。
往前搜尋法或許是較好的方案。從錯誤發生的地方往前找看看到底那裡不對勁。在
程式較小的場合或許管用，但程式太大了就困難了。最科學的當屬原因消去法。我們有
系統的去分析一個錯誤發生的原因，作一些可能的假設。就像是汽車發不動了，你不會
急忙的把車子支解，而是會想想看那些零件的故障會導致車輛無法發動，例如火星塞、
分電盤......。
以上提的三種除錯的方法都有適當的軟體工具來配合，例如單步追蹤器，或中斷點
除錯......等。
不可否認的，除錯的工作是一件令人痛苦而不耐的工作，特別是對於原程式設計者
而言，要他承認自己的程式有錯，真是一件丟臉的事，但事實就是如此，錯誤就在你的
程式中。因此從人性面來考量的話，除錯的工作或許該交由別人來做，但有誰會比設計者
本人更了解這個程式呢？話說至此，筆者還是認為設計師本身應該能夠坦誠的面對問題，
並且不要蓄意的去保留自己的秘密，這點應該是很重要的。
第８節 結語
軟體設計是件高度創造性的工作，因此創意是不可缺的。但創意的實際化是否需要
一套方式來規範呢？或許僵硬的限制是扼殺創意的的元兇，但缺乏一套記錄、表示創意的
方法，將會讓創意白白的從指縫間流走。或許你看完這篇文章後會說：『我從來都不依照
這些法則來寫我的程式啊！』是的，許多人都是如此，但也因此他們程式的發展都有個
上界，這個上界可能是程式的大小或複雜度等等。當然真實的設計工作不會這麼死板，
你可以自由的運用這些軟體發展的策略，來設計你的程式，要知道，草率的設計和編碼
所導致的結果總是痛苦的除錯！
很明顯的，限於篇幅，筆者不可能將程式設計的方式完全寫出來，讀者有興趣當作
更進一步的研究。不過累積自己的經驗是很重要的，這些實務上的經驗幾乎是很難從書本
上習得，特別是對我們中國人而言，很多設計的理論完全是國外研究出來的，但諸如中文
的處理，卻是完全本土化的一種東西，但國內真正在將技術本土化的人並不多。附帶一提
的，在模組化設計的方法中，有一個由 Stevens 所提出來分別模組緊密性的方法，這個
方式完全就是架構在英文文法上，對中文並不完全適合，因此筆者就捨棄不提了。
對於創造完美的程式，永遠是設計師們追求的目標。你呢？
