Visual Basic .Net (VB.Net) 程式語言案例學習 (13. 總結)¶

本書專為想要快速進入資訊系統開發、想要快速解決工作、迅速而有效解決的讀者而寫的，藉由簡單的分析需求，到系統規格制定，都能透過快速的方法進行。有時候我們會花掉許多的時間在系統分析上，可是對於熟練的程式設計師而言，寫程式已經不是多大的問題，真正的問題是在於能否作出符合客戶需求的軟體。因此無論是系統分析或是程式設計，我們提出一些要注意的地方，供各位讀者參考。

13.1 修改系統要注意的地方¶

有時候我們在設計系統的時候（系統分析），往往會忽略到系統真實的面貌。這就好像為什麼我們畫圖的時候，都沒有辦法畫得很像呢？這是因為我們在畫圖的時候，影像藉由視覺傳入大腦中，而大腦會自己修改以及轉換，所以在畫圖的時候，所繪出的東西其實是我們認為的樣貌，而非物體真正的樣貌，因此無法畫得很像。同樣的在設計系統的時候，也會遇到相同的情形，不過這是可以透過經驗法則去改變，但是就會顯得慢了許多，因為你必須不斷的遇到挫折，才會改變到價值觀，所以我們才會提出簡單的分析方法，一開始我們會羅列出許多的功能項目，然後透過簡單的需求分析表，找到要製作的項目，以及優先順序，如此才不會像無頭蒼蠅一樣到處碰壁。

系統是會隨著人、事、時、地、物而有所改變，我們就稱為改版，每一個版本都必須保存下來，無論是文件或是原始碼以及封裝程式，每一次的小改版也是如此，相信我有時候時間久了，系統改來改去，難免會需要參考到以前舊的資料，甚至有可能需要以前的功能，這時候若有保存，就不必再重新撰寫程式或設計系統了。

至於改版一向是令許多設計者抱怨的工作，因為你必須先熟悉原來的版本，才能修改出新的功能，在這裡建議兩種方式。第一種是外掛法，你可以保留原來的程式，重新開發另外一支程式或是子程式，用新的需求及規格去做，然而卻不用動到原始的母程式，這除了可以釐清責任歸屬（假設母程式不是你寫的），而且透過子程式的單獨運作，這樣可以縮小你要參予的範圍，將焦點集中在新功能上。第二種方法是增設法，這常常用在資料管理系統上，隨著不同的改版需求，舊的欄位可能已經不敷使用了，但是資料庫系統已經上線，而使用者眾多的情況下，首先你不可能動到原始欄位，因為這樣會導致舊版程式產生錯誤，再者你也不可能馬上替眾多使用者更新版本（除非你打算加班熬夜替每個使用者安裝新程式）。這時候就可以用增設法，直接在原始資料表上新增欄位，然後新版程式可以自動判別新舊之別，當遇到舊版時，程式可以進行轉移，將舊欄位的資料轉移（複製）到新欄位。如此一來，無論是新版程式或是舊版程式都可以使用，設計系統時最忌諱每次都要重零開始（重新設計），因為你有多少次讓你人生重頭來過的機會呢？別浪費時間重頭設計了。

除此之外，規劃系統時最好是採取先求有再求好的概念，因為無論你設計的如何仔細，客戶都會有所抱怨，能夠一次達到完美，簡直是不可能，筆者設計程式約有九年經驗，只有遇過一次，第一版就達到完美的經驗（客戶還高興的跑來送禮）。所以根本就不要去想說一次做到好，這簡直比中樂透還難。綜觀許多的軟體工程法，都有所著墨在客戶回饋的部分，這就是說經過不斷的溝通，要拉近客戶需求以及軟體功能的距離，因此簡單的說，設計系統時把主要的功能先做出來，並且有粗略的描述即可，用以驗證客戶需求與軟體功能是否一致。

切記把介面跟模組分開來設計，就算沒有使用『MVC』設計，也要將這兩個部分切開來設計，倘若你把介面跟模組結合在一起，你將會陷入恐怖的輪迴，永遠也無法抽離。為什麼這麼說呢？簡單的說，介面是一種展現方式，也就是客戶最直觀的樣貌。而模組是實際運作的流程，與資料展現無關。倘若結合在一起，就會變成牽一髮而動全身。這是相當痛苦的一件事情，何不讓介面與模組分離，透過既定的溝通模式，介面專注於資料的展現方式，模組將焦點擺放在資料的處理上。如此接收到需求變更的時候，就可以透過分別運作，而無須將兩份工作加諸在自己身上。更實際一點的說明，設計的時候可以先規劃模組的部分，把資料處理設計成一個元件，而介面透過這個元件取得所要的資料，倘若日後改版的時候，改介面就無須修改模組，改模組就無須修改介面，而更新工作也只是元件或檔案置換罷了。

最後是無論採用任何一種軟工方法，都要有的觀念就是替代方案，在開發軟體的時候，若是遇到未知的問題，往往我們都會預先假設這是可行的，但在實際運作時，也許會遇到瓶頸。這個時候就會造成工程延遲，倘若沒有替代方案的話，就很容易卡死在這個環節而出不去，因此如果具有備援概念或準備的話，就不會輕易的陷入這個死胡同中。這點是非常重要的，替代方案最好是越簡單越好，因為往往採用到替代方案，就是接近困境的時候。此時無論採用模擬法或者是其他方法，只要能夠讓工程繼續下去，就先完成可行的部分，回頭再來修正有問題的部分。

13.2 修改程式要注意的地方¶

本節是較為細部的部分，與設計系統有所區別，跟實作方面比較有關係。修改程式的時候，必須先釐清原始程式與新增程式碼的不同，所以註解是非常重要的一點，至於註解要怎麼寫呢？各種學者有不同的說法，但筆者認為使用時間日期標示是最簡單的，若是要動到原始碼（上游來源程式）的時候，最好是將原始碼註解（Mark）起來，不要動不動就刪除掉，因為這會喪失參考的來源。倘若你覺得這樣很礙眼，會造成原始碼文件過長，編輯不易。IDE介面都可以載入文字檔，將這些程式碼移動到文字檔內，就可以解決這個問題。

在客戶還不知道自己想要甚麼程式之前，最好不要隨意的修改原始碼，更切確的說就是不要做沒有把握的事情。通常客戶是不知道自己想要甚麼的，因為你不能期待每個客戶都學過軟體工程，所以一切都是假設，修修改改是必然的結果。那要怎麼去安排處理這些情形呢？首先要避免的就是不要去更動無法快速修改的程式碼，找出可以動工的部分，然後再替客戶修改出雛型的版本，這樣確認的步驟看似麻煩，但卻可以省下許多時間。

接下來是不要使用沒有控制權的函式庫，所為控制權指的就是你所能掌握。有時候我們會因為貪圖方便，而採用一些已經封裝好的函式庫，無論這些來源是第三方或是網路分享，在沒有所謂官方的支持下，直接採用是很冒險的行為。因為出了問題你不知道要怎麼解決，更別說當客戶需要延伸功能的時候，你根本無從著手。使用沒有控制權的函式庫，也就是把控制權交給別人，幾乎沒有轉圜的餘地。有時候就算是使用了官方的函式庫，也都還會遇到問題，根本就是種考驗。所以能夠的話採用已經驗證或是有官方支持的方案，會是比較有保障的作法，當然最好有開放式原碼的方案，你至少有個參考，而控制權還是在你手上。

設計程式的時候儘量保持擴充的彈性，不要一次把它寫死。簡單的說在資料庫欄位設計的時候，千萬不要依照客戶所定的規格，一次寫死，要保留改版的彈性，否則改版的時候會相當的麻煩，甚至要重新改寫原來的程式碼。就效益考量，一次寫死的程式，再使用率（Reuse）相當低，這跟軟體工程是有所違背的。筆者在設計程式的時候，一定會保持彈性，並且能夠作成模組的，就一定採用模組的設計。往後要遇到相同的情形，就可以馬上使用，根本不用重新去撰寫程式，所以筆者累積了許多自己開發的元件，有時候直接套用即可。甚至遇到不同的平台，透過多型的設計方式也可解決。就如同六十年代的設計師，對於日期格式習慣取兩碼，誰知道四十年後，會產生Y2K的問題。

不要在介面與模組之間添加無所謂的程式碼，有時候圖個方便，就在模組與介面之間添加程式去解決問題，這乍看是很簡單的事情，但延伸出來的是維護不易。介面與模組分開設計，就不要跨越這條界線，時間久了之後，你會以為模組出現問題，怎麼傳出來的值到介面上看起來不一樣呢？因為你已經忘記曾經添加了甚麼程式碼在這之中，還以為出現了錯誤。當然解決這類問題的軟工方法論已經被提出來了，叫做剖面導向程式設計（Aspect-Oriented Programming、AOP），有興趣的讀者可以參考http://aosd.net ，目前多以Aspect-Oriented Software Development（AOSD）稱之。

變數命名一致性是很重要的，最起碼採用微軟工程師所設計的匈牙利命名法，我相信你一定不喜歡看到程式用A、B、C來命名變數，你得花很多時間去猜測變數的功用，基本上筆者根本不會去看這類的程式，因為實在是太浪費生命了。與其去猜測程式的用意，不如重新改寫還來的快多了。在早期變數名稱命名是有所限制字元數，可是現在已經達到相當適用的程度，基本上命名已經算是很自由了，所以儘量是採取一致性的命名方式。

每一次的改版儘量將所有程式測試一遍，有時候一點小改版，我們會認為影響不大，甚至認為根本不需要做測試，這是非常危險的事情。如果系統很大，到是可以採用模組化的測試方式，但測試一定要做，特別是資料結構是別人訂定的情況下，你無從掌握到任何突發狀況，時常就算是測試過的軟體，也還是會出現小問題。但是測試是一定要做的，就算測試工作會延遲交期，你寧願延遲也不要儘量將有問題的程式交給客戶，那對於你的信譽及能力會有所損失。

避免Null的情況，在資料處理的時候，若遇到Null的情況，這是會增加處理程式碼，其實這是可以避免的，你只要在資料讀出後加入空字串或是空值，就可以順利避免到Null的情形，減少處理資料的程式碼。透過一點小步驟做個簡單的加法，以後就不用在處理到Null的情形了。

一定要做例外處理，一般來說我們寫的程式是依照正常操作的流程進行，可是交到客戶端之後，客戶的操作方式是你無法預期的，倘若不做例外處理，程式就會出現一連串的錯誤，你寧可將錯誤改成訊息，這樣也方便你去除錯（Debug），筆者所撰寫的程式幾乎都加入錯誤處理，而會帶出訊息，就不會因為錯誤而造成測試無法繼續下去的窘境。

每一次的改版都要先保留原始碼，然後再開始修改，這是非常重要的一件事情，在客戶還沒有看到雛型版本之前，其實客戶的概念還沒有建立起來，當他看到程式雛型之後，才會建立起程式功能的概念及需求，所以改版是必然的事情，因此我們倘若保留了每一個版本，其實這對客戶或是設計者都是有好處的，說不一定改來改去又改回來原先的樣貌也說不準。

最後，時時關心軟體工程的新方法，畢竟寫程式就如同工人一樣在施工，筆者在還沒有上過軟體工程課程之前，總以為寫程式是一種管理工作，就當教授說過一句話之後，筆者的價值觀才有所改變，教授說：「我們是一群工人，軟體工人，因此才要了解甚麼是軟體工程。」這也就是說，我們要學習如何去施工及規劃，讓工程得以順利進行，不同技能的工人能夠支援的程度有所不同，但是藉由軟體工程，你可以將工程進行管理，而不會亂了手腳。

13.3 轉型思考¶

在這裡我們不討論有關企業上的思考問題，轉型思考原來是為了企業而設計的思考方法，但是對於實際應用層面上，除非你與客戶都具備有轉型思考的概念，否則是無法進行的，任何一種軟體工程法，都必須雙方具備有相同概念下，才會成立，否則只是開發者自唱高調而已。因此本節我們討論的是個人的轉型思考，先由自己本身做起，當個實踐者進而影響他人。

坐而言，不如起而行。這是轉型思考的第一步，人擁有創造力或是靈感，但是若是採用文字表達的話，是非常容易忘記的，因此若能結合圖型與文字，就能夠延長記憶的時間，最近很流行圖解力，其實也是所謂的心靈地圖的演變，就是透過圖形來幫助思考及創意。

其次要獲得創造力的成長，有幾個階段，分別是擴張階段、延伸階段、演化階段。擴張階段就是基礎心智階段，首先基本的生理需求必須滿足，這時候心智才能自由的取用資料或是以往的經驗，而環境部分必須充滿了許多的感官刺激，例如參加訓練課程、閱讀、聽音樂…等等。而延伸階段必須透過與他人的互動才能產生，最好的方式就是參加團體或組織，例如參加會議、舞蹈、餐會…等等。演化階段就是要改變或突破限制發揮潛能，尋求自我實現以及服務他人。這時候必須與不同的團體或環境交換大量的資訊，並且刻意的改變環境或是試驗，但這必須符合安全的機制。簡單的說就是先藉由本身自我的調適，讓自己的身心都獲得滿足，才有餘力去做創意的工作，剛開始藉由個人的能力去收集情報，多加以充實自我，而後利用團體的資源，藉由他人的分析精煉，快速的獲得新的情報，最後以跨領域的模式，產生激盪。如此一來，創意就會自然的產生。

成長的模式是在說明創造力執行的運作方式，這是一連串的模式，由尋找、組合、調整三項組合而成。實際運作概念是以策畫、做、檢視的循環，這與企業管理一連串的運作分析技巧有關，就是分析、調理、判斷、執行、績效、考核、驗證。筆者認為這三項是有關連的，因為都是在做循環工作，甚至與軟體工程也有關係。尋找甚麼呢？尋找並發現成長的材料或者是資訊；組合甚麼呢？使用材料和資訊進行成長；調整甚麼呢？評估成長活動的效果，來做必要的調整。對於個人來說，就是以第二項的模式來實行，策畫、做、檢視。一般而言，大家只著重在策畫以及做的階段，很少人會去檢視效果，事實上檢視是最重要的一環，透過檢視才能調整自己的步伐，否則就是一昧的鑽牛角尖而已，檢視的來源可以是自己，但也可以是朋友、同事、親人…等等。總之你需要一些回饋，才能知道你所做的是否對自己有幫助，在這樣的循環才能夠達到正面成長。

仲裁者與生產者，六十年代的分腦研究發現，左右兩邊的大腦分別掌管著人類兩組不同的特質，其中左腦掌管著邏輯、分析能力；而右腦掌管著視覺、模型製作、直覺技能。因此我們分別以仲裁者與生產者來稱之，仲裁者強調邏輯性、實際面，並且樂於為事情做結論以及將事物拆成幾個部分做分析；生產者喜歡創造，它會將不同的事物透過前所未有的經驗做連結，而且不考慮任何實際面的問題。這兩個思考者結合起來就成為一個偉大的團隊，但是藉由學校的傳統訓練，仲裁者變得比較強勢，生產者逐漸被冷落下來。可是創造、創新都需要這兩名思考者合作才有可能，因此必須讓生產者與仲裁者互助合作，也就是說當仲裁者依照以往經驗分析過後，要請生產者協助產生不同可能的連結，因此提出思考的三個階段，觀念產出、觀念評估、觀念選擇。觀念產出強調發散，它是逐漸擴大的思考模式。而後透過觀念評估，強調整合，逐漸的縮小範圍。最後進行觀念選擇，強調出現，這時候是一種平型階段。其實無論是決定午餐要吃甚麼，或者是任何一種思考，幾乎都經過這三個階段。筆者認為這與數學上的函數論的定義似乎有關，假設B是對應域（co domain），也就是解（y）的集合；而A是定義域（domain），也就是自變數（x）的集合。而函數對應必須在１對１、１對多，方可成立。值域（range）就是完全對應到y的集合（經由函數對應所得之y集合）。由此來看，B像是所有可能性的集合，也就是觀念產出的集合；而值域就像是觀念選擇的集合；而A就像是觀念評估的集合。同理，許多的x帶入之後，會對應到y值，也許是１對１、１對多，這分別表示可能有一個解或是多個解。因此這個觀念是否成立，就必須檢視該函數是否能正確對應，而函數就代表觀念。筆者認為透過這樣的解釋，可能會更加清楚。

心靈地圖是一項可以快速抓住複雜想法的方法，一旦可以掌握繪製心靈地圖的技巧之後，就可以進一步產生出心靈景象圖。首先心靈地圖是一中心的圖像做開始，這是一個具有代表性的文字及圖案的組合。接著每一條線寫上一個關鍵字，這時候你會發現大腦經由一點點的提示就可以引發許多的想法，而所有的線段都是由中心圖向發展出來的，這些線段可以幫助我們再各種資訊間做連結。心靈地圖不是在考驗繪圖技巧，而是在透過大腦最熟悉的模型做思考連結的動作（學者研究出來的一種技巧），特別是當你有許多複雜想法的時候。練習的方式可以先由圖型來表示，而後透過色彩的加入就可以幫助組織。

心靈景象圖又稱心靈旅程景像圖，因為它就是一張旅遊的圖案，無論是去哪裡旅遊總是有需多事情需要準備，你才能跨出第一步，在旅途的過程中，你也許需要休息、紮營，每一個階段的告示牌都能讓你激發動力，因為你離目標越來越近了，而任何一個階段都有障礙，你必須知道如何解決障礙以及會有哪些障礙。其實透過圖像，可以幫助我們記憶或者是加強創意，出發地的箱子可以代表著你要準備的事物，休息或是紮營代表著你所需要的資源或補給，告示牌代表著階段的工作，而一些小石頭或是毒蛇猛獸可以代表著障礙，而透過心靈景象圖你就可以知道在這旅程中誰會幫助你、誰會與你同行、哪些原則或價值可以引導你、有哪些障礙、這趟旅程對你有甚麼意義、要如何衡量以及慶功…等等。心靈地圖與心靈景象圖的應用很廣，主要就是幫助你產生點子（Idea），並且找到方向。

透過電腦協助繪製心靈地圖，這是一件相當輕鬆的工作，至少對於常使用電腦的人來說。微軟的Visio中就有提供心靈地圖的繪製工具，它是被歸類在商業、腦力激盪圖。使用方式很簡單，首先放置一個主要主題，然後依照可能性再接著擴展出主題、多重主題，再用動態連接器把相關子主題連接起來，而互相有關係的主題還可以用關連線連接起來，以產生相關性。簡單的來說，你只需要用五種圖形就可以創造你的點子，進而找出點子的架構，這不是相當方便的一件事情嗎？除此之外，筆者建議繪好的心靈地圖可以印出來，收集成冊以便做為靈感的來源，或是回顧的歷史記憶。更實際面一點，筆者遇過停電的狀況，那時候的感覺就像是所有的靈感都被鎖在電腦裡，實在感覺很糟糕。就算未來會所謂的電子紙（一種低耗電量、低重量、以及可以任意彎曲的螢幕，外型如同一張紙一樣）能夠量產，也仍舊不能保證不會有電力耗光的情形，因此有時間還是用老祖先傳下來的方法吧，印在紙上面，保證不會有電力上的問題。

此外由網友Younba推薦的Freemind軟體是一套免費的心靈地圖繪製工具，因為專注於心靈地圖的功能上，所以顯得非常的好用，免費並不是最主要的重點，而是該軟體所提供的功能，非常適宜，相對於Visio而言是強多了。筆者學習Freemind根本不用三分鐘，因為它是多國語言版，可以顯示中文介面，再者幾乎所有功能都搭配一個易懂的小圖示，就算連中文看不懂，也是可以操作的非常順手，整個操作就是按下滑鼠右鍵，呼叫功能表，透過功能表的選項，幾分鐘就可以說非常熟練，而且加入圖示也是相當簡單，可以為您的心靈地圖添加美麗的畫面。

轉型思考不是筆者所提出來的方法，而是由許多學者所研究的方法論，雖然主要是應用在企業或組織上，但筆者將其轉換到個人領域上，也覺得是可以適用的。有興趣的讀者可以參考遠流出版公司所出版的轉型思考一書，該書是由Joyce Wycoff、Tim Richardson所著，許舜青所譯。

圖 15‑1 VB 2005 資訊系統快速建置方案 書籍大綱之心靈地圖

13.4 時間管理¶

這篇是為辛苦程式設計者所寫的文章，我們假設這樣定義，程式與心靈透過邏輯所產生出來的結晶，就叫做「系統」。因此與心靈在某種程度有著關連，首先人所皆知的生理時鐘，這是生為人所無法避免的一種天生循環，若要改變這種循環可能要經過幾百萬年的演化才有可能，因為演化的速度相當慢。作者曾經是個超級夜貓族，可以好幾個晚上不睡覺，熬夜寫程式，寫到腦袋幾乎麻木了，出去想買個東西吃，結果在自己家裡附近迷路。這就是過度熬夜的下場，可是許多程式設計師都比較喜歡在夜間工作，第一理由首推夜晚比較有靈感，第二安靜，第三可以放輕鬆的做。這些理由幾乎都與身心需求相關，難道寫程式就必須熬夜才能獲得以上的需求嗎？這不是和生理時鐘相違背嗎？如此忙碌的工作很容易老化，對於肝、腎等器官傷害非常的大，而且熬夜的時候難免吃宵夜，本來胃腸晚上須要休息保養，反到加速運作，長久下來真的不是一件好事。

但要如何獲得這三項身心需求？以滿足寫程式的條件呢？依照筆者的經驗，筆者以往就是違反生理時鐘，長時間下來結果免疫力系統降低，幾年下來有一天突然的了顏面神經麻痺，而這種病好發於過度疲勞者身上，雖然經過一年多的治療慢慢康復，但是至今在微笑的時候，仍可見到一邊高一邊低的尷尬臉型。因此筆者苦思另外一種工作模式，加強時間管理，以避免再次受害。

首先廣讀有關時間管理的書籍，甚至研究到關於大腦運作的機制，要寫好程式，筆者首推身心滿足，為有身心滿足的條件之下，才有清醒的頭腦，用不完的精力，進而創作出佳作。

在身理需求上，必須滿足一切身理要求，也就是說身體健康，而且在不飢餓、不飽足的情況下，手邊有至少有一杯水，這看似簡單，但卻是有其理由，飢餓及飽足都會使得血液集中到胃部，影響腦部血液的流量。而隨時補充水分是因為一般工作環境都是在乾燥的冷氣空調環境，除了加濕的效果之外，隨時補充水分，對於身理需求是一種調劑的作用。而且常喝水還可以代謝有毒物質，幫助毒物排出。程式設計師一般而言最喜歡喝咖啡，筆者以前也是一天要喝十幾杯的咖啡，結果越喝越猛，反到腦袋不清楚，而且有上癮的情形出現，這不是個好現象。除了骨質容易流失之外，對於咖啡的免疫力提高，常常喝一口氣要喝好幾杯才會滿足。至今筆者已經戒掉對咖啡上癮的情形，一天只喝兩杯咖啡，有時一天只在清晨喝一杯咖啡，反倒覺得腦袋清晰許多。不會一直念著咖啡。茶是一種好選擇，由其是綠茶，除了有抗氧化物之外，可以幫助延緩老化，並具有抗癌，代謝輻射的效果，但究竟要喝多少茶，才能夠感受到效果，這可能必須詢問專業醫師的意見，筆者只是就書籍研究的資料跟讀者們報告。

此外在心理需求上，大家最希望的就是保持一個清晰的腦袋，這是一致的希望，筆者也在這方面做了很大的努力，除了研讀許多腦部運作的書籍之外，對於心靈的研究也不在少數。最簡單的步驟就是依循生理時鐘建立起時間管理，因為天生的系統，你要去改變它，必會造成一些破壞。與其要有衝突，不如退而求其次，重新檢視時間管理，這樣要好得多。首先必須承認，一般程式設計師的確因為在夜間工作，能夠比較容易獲得身心滿足，進而創造出短期效率，為何是短期效率呢？綜觀熬夜的方式，長期而言對於身體傷害非常之大，常常變成未老先衰。因此筆者的建議是提早睡眠時間，提早起床工作。筆者患病後至今每天十二點睡，約四五點起床，就保持如此的循環，因為四五點的時候，其實也是可以滿足身心需求。若有事情真的很急著趕，在睡前心中默念明天要起床的時間，久而久之就會鍛鍊成生理時鐘，就如同筆者現在再寫的這篇文章，就是今天三點半起床開始撰寫的。而且腦袋清晰的情況下，工作效率相當好，文章書寫的很順利。當然您也可以提早時間睡覺，提早時間起床，依照筆者的經驗，大約一個月的固定模式之後，生理時鐘就會形成，就不會有剛開始起床昏昏沉沉的感覺。還有夢境也是個問題，人會作夢就是代表在淺睡期，其實腦部並沒有停止運作，因此醒來的時候並不會完全清晰，要避免做夢，除了可以請醫師幫忙外，在睡前使用冥想的方式入睡，這是有相當大的幫助。儘量告訴自己由頭到腳的放鬆，由腳到頭的放鬆，放鬆之後保持空，此時會有許多雜念出現，這時候提醒自己，這些事情沒甚麼大不了，醒來再做，身體最重要。當然您也可以用您認同的方式，目的只是要用潛意識的方法，讓自己能夠安穩的入睡。只要能夠熟睡，其實短暫的兩三個小時，其效益遠大於不安穩長時間的睡眠。這是有經過學者研究的結論。

接下來，就是遇到困境的解決方式，每天至少要規劃半個小時的無所是事，這是必需的，就甚麼事情也不要做，發呆也好、走來走去也好、聊天也好、運動也好。這是為什麼呢？我們一直在尋求靈感的來源，而靈感是藉由腦袋中不同神經連結而產生的，當我們一直處在既有的邏輯思維時，而這種思考方式無法解決眼前的問題，最好的方式就是嘗試不同的思考連結，來加以突破。而腦袋其實再脫離固定思維之後，會自動產生不同連結，因而靈感就會產生，這些不同連結是因為人腦是跳躍性的思考模式，當他遇到任何東西，都有可能跟毫不相干的東西產生連結，進而創造出靈感，因而人會有無限潛能，就是依靠這顆大腦。其妙的這種連結是腦部自動運作，不需要你加以控制，也就是當你轉換思維環境之後，再回來審視問題，你就很容易產生不同的連結，進而找尋解決問題的可能性，而並非一直鑽牛角尖。筆者親身經歷就是開發程式時遇到系統廠商提供的元件是有問題的，而且經過許多國內外程式設計師反應該問題，仍舊無解。但是結案日在急，除非提早退回訂金，解除合約；否則就是一定要解決這個問題，筆者就透過這種方法，解決了這個難題，在解決之前查閱相當多的資料，大約有115000筆相關資料，仍舊沒有人可以解決，而透過思維轉換，產生後的靈感，卻幫助了我順利的結案。因此推薦給大家。

對於事情優先順序是在許多工作管理書籍及研討會上的必要項目之一，很多對於優先順序的方法不勝枚舉，但是筆者專注於寫程式遇到的優先順序而提出看法，當我們透過任何一種方法去安排事情的優先順序之後，就是要達成目標完成使命。這是必要的一種思考，否則安排完之後就不了了之，那又何必安排呢？當然事情一定不會像原先規劃的那麼順利，程式寫到一半可能會卡住，這時候怎麼辦呢？筆者建議依照優先順序規劃的項目，從中挑選出核心的部分，以及困難的部分，利用模擬法將這些耗時間的苦工，先模擬出預設的結果，這代表著你可以很順利的繼續完成程式，並且有初版的展示作品，因為我們就是認定一定可以完成程式的使命，所以先採用模擬的資料結果，也是沒有關係的，回頭再來繼續開發較核心較困難的部分，進而將整個流程完整的結合起來，這樣反倒有助於工作的效率，而並非真正的那麼無法變通，一定要一項一項的完成。而且用模擬法的方式，讓你很容易看到程式完成的樣貌，進而幫助了解整個系統概觀，加速生產力。

計畫要清楚易懂這是非常重要的，有些人花了許多的時間與精力去計畫要完成的事情，寫的長篇大論，卻面臨無法執行的窘境，這多划不來。因此計畫要寫的非常容易了解，簡明扼要是最好不過了。透過電腦的幫助，有相當多的軟體可以協助，例如：MS Excel、MS Outlook、…、MS Project、等等。筆者最常用的就是Outlook，因為它可以跟筆者的手機同步，讓筆者可以很放心的在PC上安排工作，然後由手機提醒筆者，這樣的模式相當簡單，只要在PC上安排完工作之後，把手機線與個人電腦連接起來，自動就會同步與充電，隔天再把手機線拔掉，帶著手機就可以達到個人工作管理的目的了。計畫要寫得清楚易懂可以由兩個方式著手，首先主旨的命名，要能由名稱一下就能連想出這件計劃的概要；其次是詳細資料，透過詳細的輔助資料，所有能夠幫助執行計畫的資訊都必須記錄下來。這樣就能達到清楚易懂的模式了。而計畫撰寫的時間最好是前一天晚上，就把明天的工作都安排好，有個基礎概念，如此一來，你將會發現有許多時間是無形中多出來可以讓你自由運用的了。

最後，總結一下，首先筆者認為一定要在身心滿足的情形下工作，這樣才能確保工作的品質及效率。而後身理需求首推身體健康，接下來心理需求首推睡眠品質。困境的解決方式建議採用思維轉換，讓大腦自動幫你產生靈感，進而解決問題。而事情的優先順序我們建議越快能夠達成系統概觀的方式，就要盡力完成，跳過困難的部分，先完成大領域的事情。最後撰寫計畫的時候，計畫要清楚易懂的模式下進行，而且最好前一日就對明天的工作有所安排，避免到了每天早上，對於今天要做的事情都還是一頭霧水。這是筆者由失敗到成功的經驗，與各位讀者分享，也希望讀者能夠為我們這群軟體工人提出更好的生活時間管理建議，幫助大家在更好的優質環境中發揮潛能。

13.5 VB 6.0與VB 2005差異小結¶

選單的編輯

在VB 6.0之前選單的編輯都是採用編輯器，而在VB 2005上是直接在表單上做編輯，這不僅變得更直覺化，也方便許多。

引用元件的選單

在VB 6.0引用元件的對話視窗欄位長度是不能做調整的，因此若遇到命名比較長的COM或元件，您只能用猜測的。現在VB 2005變成加入參考的對話視窗，而且欄位是可以調整的，因此無論命名多長，都可以看得一清二楚，選擇上也比較便利許多。

可以收起與展開的程式碼區域

有時候我們在編輯較長的程式碼時，在VB 6.0中會比較不方便，尤其當程式碼超過上萬行時，要區分或者是找尋程式碼區塊，只能利用尋找功能或者是移動捲軸。而在VB 2005你將可以收起程式碼區塊，讓程式看起來比較簡潔。

支援物件導向設計

VB 4.0開始支援物件導向進行開發，採用方式以元件為基礎的設計模式。VB 5.0之後增加了一些特性來接近物件導向設計，但仍舊不是完全的物件導向設計語言。如今，VB 2005才真正的完全支援物件導向設計的所有層面。物件導向設計中有四個關鍵，分別是抽象、封裝、多型與繼承，而VB 2005都能夠做到了。

基於.NET的框架

在VB 6.0時，採用獨立的執行時期模組來做翻譯的動作。在VB 2005中，基於.NET的架構，因此執行時期是採用Common Language Runtime，因此VB 2005或者是基於.NET架構的程式，執行時都必須在支援.NET的系統上方可執行。

使用Win32 API

在VB 6.0時雖然可以透過宣告使用到Win32 API，但卻並不是完全支援，而VB 2005可以使用COM，透過使用.NET的類別或是pInvoke的方式呼叫Win32 API都是可行的。

VB 6.0與 VB 2005的抽象（Abstraction）

抽象是物件導向思考的關鍵之一，抽象是一種歸納法則，而在VB 6.0中類別是寫在.CLS的檔案之中，在VB.NET中可以透過程式碼直接寫出類別，這將會使得物件導向設計更加方便。而抽象的類別是不可以直接使用，必須透過實作產生出物件，才能以物件的形態去使用。在建立物件的語法上有很大的差異，以往的CreateObject已經不能使用了，取而代之的是System.Activator.CreateInstance。

VB 6.0與VB 2005的封裝（Encapsulation）

封裝就是把物件看成是黑盒子，使用者根本不需要知道裡面的構造才能使用，如同打開電視機，您只需要知道電源開關在哪裡，而不必了解電視電路板的設計。VB 4.0以後才開始支援封裝。

VB 6.0與VB 2005的多型

多型就是不同物件有相同特徵，但卻有不同的實現方法。例如：機車與汽車的物件都具有開車的方法，但實際上開車的方式卻不同。VB 4.0中透過使用Late Binding提供了有限的多型方式，VB 5.0後使用介面的另外一種方式做出多型的效果，現今VB 2005提供真正的多型設計，直接支援介面的設計。

VB 6.0與VB 2005的繼承

繼承是一種分類的思考方式，例如：人類是哺乳動物，而人也是靈長類，因此靈長類繼承了哺乳動物，人類繼承了靈長類。由VB 5.0版之後就出現了implements的陳述式，但卻無法繼承已經存在的類別。現在VB 2005已經達到真正實作繼承的功能了。並且新增了實現繼承的語法，請參考下表。

語法	內容	說明
Inherits	類別	繼承父類別
NotInheritable	類別	無法繼承
MustInherit	類別	該類別必須由其他類別繼承
Overridable	方法	該方法可以由其他子方法覆寫
NotOverridable	方法	該方法不能覆寫
MustOverride	方法	該方法必須覆寫
Override	方法	該方法覆寫父類別的方法
MyBase	程式	允許類別呼叫父類別的程式
MyClass	程式	允許類別的程式呼叫自己
Protected	函數、程式、變數、屬性	子類別可以呼叫

VB 6.0與VB 2005的介面

VB 6.0介面透過在類別中加入程式或者使用IDL建立。但在VB 2005上您就可以直接建立真正的介面，而不需使用模擬的方式。

例外處理大不同

例外處理也就是異常處理，在程式中佔有一定重要的地位。早期VB 6.0透過Error … 的陳述式來處理意外錯誤，而VB 2005已經採用Try…Catch…Finally的方式處理錯誤。這使得例外處理更加有可讀性。VB 6.0的例外處理是不一致的，處理DLL呼叫錯誤的是用Err.LastDLLError，COM錯誤的是用HResult。在.NET架構中，例外處理是類別的物件。

VB 6.0與VB 2005元件上的改變

WebClass在VB 2005中消失了，取而代之的是ASP.NET WebForm，類似WebClass，WebForm使得圖型設計與程式設計分開，變得更加物件化。

DHTML基於Internet Explorer上執行，而VB 2005提議兩種客戶端執行的模型，首先是JavaScript的DHTML的應用程式，其次是Windows Form上部署HTML。

ActiveX文件和DHTML類似，ActiveX文件被Windows Form取代。

ActiveX是指定遠端外伺服器應用程式，在.NET架構下，變成多執行緒，不受COM模型限制，對遠端外伺服器應用程式的需要減少了。

資料庫工具在VB 2005中有新的類別，以及Crystal Reports.NET的支援。

VB 6.0與VB 2005語言上的變化

筆者在這裡只列出部分比較常用的或值得注意的變化，供各位讀者參考。

VB 6.0或之前的語法	VB 2005新的語法
As Any	函數覆寫
Calendar屬性	System.Globilization.Calendar類別
Currency資料型別	Decimal資料型別
Circle陳述式	System.Drawing.Graphics.DrawEllipse方法
Date函數和陳述式	System.Data資料類別的Today屬性
Debug.Assert方法	System.Diagnostics.Debug.Assert
Debug.Print方法	System.Diagnostics.Debug.Write
Deftype	未被取代
DoEvents函數	System.Windows.Forms.Application.DoEvents方法
Empty關鍵字	Nothing關鍵子
Eqv操作符號	=操作符號
Imp操作符號	不是A Imp B，改採(Not A) or B
Initialize事件	建構函數
Instancing屬性	呼叫性限定符號
IsEmpty函數	未被取代
IsMissing函數	函數覆載
IsNull函數	Microsoft.VisualBasic.Information.IsDBNull方法
IsObject函數	Microsoft.VisualBaisc.Information.IsReference方法
Let陳述式	未被取代
Line陳述式	System.Drawing.Graphics.DrawLine方法
Go Sub陳述式	未被取代
Lset陳述式	System.String.PadLeft方法
MsgBox函數	MsgBox放在相容的庫中，框架中有一個MessageBox類別
NULL關鍵字	Nothing關鍵字
On…Go Sub結構	未被取代
On..Goto結構	未被取代
Option Base陳述式	未被取代
Option Private Module陳述式	呼叫限定符號
Property Get、Property Let和Property Set陳述式	新的屬性語法
Pset方法	System.Drawing和System.Drawing.Design
Rnd函數	System.Math.Rnd方法
Round函數	System.Math.Round方法
Rset陳述式	System.String.PadRight方法
Scale方法	System.Drawing和System.Drawing.Design
Sgn函數	System.Math.Sgn方法
Sqr函數	System.Math.Sqr方法
String函數	System.String
Terminate事件	Finalize方法或是System.Idisposable介面
Time函數	System.Date.TimeOfDay屬性
Type陳述式	Structure陳述式
Variant資料型態	Object資料型態
VarType函數	System.TypeCode
Wend陳述式	End While陳述式

Lai Tai-Yu (賴岱佑)

回到教材說明