X22 關於○○，你瞭解了多少？

前幾天在聯合新聞網上看到一篇報導：爭拔河起源 女研究生舌戰日韓學者。

「拔河」起源於中國、日本，還是韓國？在今年四月的「拔河節」上，日、韓兩國學者為此爭得面紅耳赤，他們紛紛引經據典稱「拔河」是自己國家的非物質文化遺產。學歷史的熊夢霞知道「拔河」運動是最早源於楚國的「牽鉤」，當時是配合水戰的一種軍事技能，在從隋唐、五代、元、明、清時期都有很好的一直傳承下來。所以當時她大膽地站出來將所掌握「拔河源自中國」的證據在現場陳述。

「你這麼年輕，研究過多少國家的拔河文化史？」一個日本專家向她反問。很自然地，研究過許多相關範圍的專家總會反問這麼一句話，情境一如我提出自己想法時，無論是鑽研理論的主管或是實務豐富的同事會講的話語。她雖然沒有對中國的拔河文化進行過系統考證，對韓國、日本拔河文化也不很清楚。「但是我至少要講出我自己所知道的真相情況，讓在座的人知道，拔河很有一種可能就是起源自於中國！」

在會場上她的這個「插曲」，讓日韓學者們達成共識要重新繪製拔河文化發展的歷史圖譜。不過在現實上，縱使看到一些“似乎”可以改進的地方，但若不讓自己的程度提升到與旁人相近的水平，無論說什麼都沒人會理睬的。這陣子被指派撰寫技術研發計畫書的工作，在公司的佈局之下不斷地涉獵所謂的“標準”同時參加外面的課程；以往落後的知識還是需要努力去追趕回來的。

未來的某一天，總是要在別人質疑自己對○○懂得多少時，能夠輕鬆地回答說：“我看過也實作過，很清楚○○的優點與潛在問題才這麼說的。”才有辦法讓別人認真聆聽自己的想法。

註：關於韓國努力地申請世界遺產之事，這裡有篇報導。擔心「被韓國」 就怕丟正宗地位 對於這個現象，以下的故事或許有人能看出終極的解決方法（強調：我什麼都看不出來。無論看出什麼，都是你自己的精闢見解，與我無關！）

有一個富翁得了無藥可救的重病，唯一的獨生子此刻卻遠在異鄉。當他知道死期將近時怕僕人侵佔財產，便立下了一份令人不解的遺囑︰”我的兒子僅可從財產中先選擇一項，其餘的皆送給我的僕人。”富翁死後，僕人便歡喜地拿著遺囑去找主人的兒子。富翁的兒子看完了遺囑想了一想，就對僕人說︰”我決定選擇那一項，就是你。”這聰明的兒子拿到父親全部的財產。

X21 相信組裝式開發的原因(3)──語音傳真系統

每一條線路都配置10個迴圈計數器與100個系統變數（VAR00-VAR99）保存必要的資訊，比較典型的語音系統指令有下面幾個：

●播放語句：播放指定的語音檔，可指定重播次數與每次重播間的等待秒數；同時設定選擇項與選擇保留變數。語音播放次數結束或是使用者有按鍵的話，都能夠跳往不同的流程區段。


●輸入資料：播放語句的同時接受用戶以DTMF輸入較長的資料並存放到指定變數，輸入後可用結束字元並進行長度的檢查，再根據結果進行不同的流程。


●電話撥出：撥出指定的電話號碼並依撥出結果執行不同的流程。搭配執行記錄可以做出撥出數量與結果的報表；撥通後搭配播放語句的選擇功能就可以做出隨機撥號的問卷統計。


●讀寫DBF檔、讀寫binary file、用RS-232C傳送資料也獨立為執行指令，取得使用者輸入的資料寫檔或是讀入資料後運用合成語句的方式將結果播報給使用者聽，也是很常出現的運用。

當年開發語音應用程式時，大部分的時間都是在畫流程圖與切割組裝用的語句，等到客戶確認流程圖後再選擇適合的指令組裝出流程。除了複雜的資料處理與極少數未規畫為指令集的行為還是要另外寫程式之外，九成以上的時間都在組裝指令與進行測試。這樣的開發模式除了比撰寫程度快速許多之外，對於不懂語音卡、資料庫、RS-232C底層API的人，只要經過少許訓練後就能上手開發。

自己曾經藉由這類的開發工具而步入職場，在理解設計原理後另外重新製作一套，同時享受只運用流程的組裝就建立系統的過程。在1990年代時就能如此，這正是我一直相信程式能夠設計為組裝式開發的原因。

註：當年運用這套語音工具開發系統的單位有
●ＸＸ政府便民語音傳真系統──除了提供民眾以語音或傳真取得資訊之外，同時提供維護者撥電話進入系統製作語音與傳真內容。
●ＸＸ證券分析師盤勢分析──民眾與分析師以用戶代號與密碼驗證身份後，根據不同身份進行聽取盤勢分析（另有扣點功能）或是錄製功能。
●ＸＸ公司庫存記錄系統──不同分公司的業務在銷售某項產品後，在外面撥電話進入分公司按入產品代號與數量，資料會藉由數據機傳回總公司即時計算存量後顯示在工作人員的電腦上。
●ＸＸ單位費用催繳系統──從文字檔讀入欠費資料在設定的時段依序打電話播放催繳費用的語句，並在最後讓使用者按鍵回饋聽取的結果。每天與每月都要產出結果報表作為記錄，並用人工催繳撥號失敗的用戶。

X20 相信組裝式開發的原因(2)──第二份工作

新的公司標到某個縣市政府便民資訊系統建置的合約，其中包含一套公司內沒人會做的語音傳真系統，因此雇用我在五個月內無中生有地完成那一套語音傳真系統。在當年寫作風格還只是包裝常用API來呼叫的情況下，我當然可以只製作一個僅符合需求規格的系統；不過受到第一個工作使用系統的影響，我選擇了更高一層的挑戰──在DOS下實作相同規模的語音系統。

整個語音系統分為editor與runtime兩大部分，開發人員在editor選好指令製作出流程後，就能在runtime依狀況或使用者選擇進行對應的行為或播放語音內容。延伸來自之前工作的經驗，我應用在這次的系統設計裡：

●語音系統指令的定義
根據之前開發語音系統的經驗，除了補強原有指令的設定參數之外，同時增訂幾個存取資料（讀寫資料庫與文字檔）的指令，另外也加強變數處理功能，儘可能地將常用的行為涵括到指令集內。當然，還是保留呼叫外部客製化程式的[自定函數]功能以應付更複雜的變化。

這是完整的指令表：


●快速的畫面開發與變化
利用控制顯示文字與顏色的兩個bytes[80][25]陣列，將要顯示的內容定義在外部檔，於需要時快速計算貼入陣列裡顯示；建立多層視窗重疊顯示與逐層隱藏，也加快了編輯畫面的開發。像等待來話的設定畫面就先定義在外部檔，在顯示時將兩個中引號之間轉變為輸入欄位，並依設定字元作輸入的檢查。


V0000=╔══════════════════════╗;
V0001=║ □行號:[####] 指令函數:[############] □ ║;
V0002=╠══════════════════════╣;
V0003=║用戶撥入電話執行行號 [DDDD] ║;
V0004=║在等待來話時執行行號 [FFFF] ║;
V0005=║用戶撥入後偵測到對方掛電話執行行號 [DDDD] ║;
V0006=║要清除本線的系統變數範圍 [DD][DD] ║;
V0007=║ <確定><取消> ║;
V0008=╚══════════════════════╝;


●用迴圈控制16條線路的執行
在runtime的實作上就需要模擬多執行緒的技巧。當時並不像現在只要new Thread()就可以獨立撰寫一條線路，必須要依序對每一條線路切割工作狀態，每次迴圈經過時都執行一點點工作就要跳到下一條線路；複雜或時間較長的指令還得再細分為更小的多個步驟來執行，以免因為耽擱過久而造成語音停播的窘況。（聲音取樣為8K/Sec，語音卡緩衝區是4K，也就是半秒內必須保證迴圈繞完一圈──CPU是486DX）

為了保證執行狀態夠快且不會錯，當時做了很多切割方法的測試才終於找到了最佳的結論。自己認為這樣的經驗值磨鍊了許多開發的思維。

●試作報表產生器
利用寫資料庫指令，在流程經過的同時寫下該線路的相關資訊，累積下來就有語音系統的使用資訊。根據記錄的規則填寫對應的參數，就能夠獲得許多類型的常用報表。像是作為服務系統時的來電數統計、選擇項統計、線路用量統計……等，作為外撥系統時的撥號數統計、接通數統計、問題回答統計……等，都能用定義的方式客製化出要顯示的內容。

五個月後，終於如期完成了這個系統。

X19 相信組裝式開發的原因(1)──第一份工作

每次與同事間討論軟體工廠的可性行時，其他人到最後都認為程式設計的複雜度太高而無法用組裝方式來開發。由於最近幾年同事們都在專案上打滾，而我一直從事工具開發與維護其他人的程式，有時難免被懷疑是否理論的書看太多而開始相信書上說的那一套理想？

照理說，書看得比別人少且專案實務也比別人少的我，不應該執著於要花很多功夫的軟體工廠才是，但是事實上卻偏偏相反。在最近的一次討論裡，我才驀然發現第一份工作對自己的影響是這麼地深遠；就是它讓我到現在仍然一直相信軟體是可以組裝的。

時間回溯到1990年代的初期，作業系統還只是DOS的年代，市場上主流的開發語言是C與Pascal。大學混四年畢業的我在退伍後，等於什麼都不會的狀況開始求職，由於不熟主流開發語言而沒法找到較好的工作，最後進入了一間開發語音系統的公司（參閱S24）。很多同期進去的人大多因為碰不到主流技術而沒待下來，卻沒想到公司裡另有兩位資深的人一直使用C語言開發許多特別的功能。

從事第一份工作兩年多一些，現在回憶起來帶給我一些特別的經驗：

第一年的語音系統
●特點在於區分為編輯器與執行器。在編輯器上有十多個指令，運用basic語言行號的觀念能夠很快地將流程圖的內容輸入為許多指令的集合。
●語音的斷句、組合與聲調處理。
●主機電文的處理經驗，包含上傳電文的組合與下傳電文的拆解。

第二年使用C語言
●以迴圈方式模擬同時處理多個執行緒運作的技巧。
●操作與主機連線的moden而熟悉com port API。
●以一個bytes[80][25]陣列控制顯示文字，另一個bytes[80][25]陣列控制顯示顏色的技巧。
●利用關鍵字的設定，快速地製作或調整多個輸入欄位的設計方法。

帶著累積下來的一些經驗，當時的我預備踏向另一段旅程。