關於時間管理的方法論，在網路上討論最為踴躍的有兩個：一為 GTD (Getting Things Done)，另一為科維 (Covey)「與成功有約」系列作者所揭露出所謂的第四代時間管理觀念。若以工具的實踐來看，前者有相當多 GTD-based 的工具軟體，包括免費與付費、線上與桌面等類型；後者則為作者本身所創立公司 (FranklingCovey)自行開發包括紙本的萬用手冊，與電子版的 PlanPlus 軟體。我也曾寫了一篇文章，討論該工具的應用：「利用 PlanPlus 規劃週計畫表的四個步驟」。

由於 PlanPlus 軟體我當時係採用 for Outlook 版本，但現在我已沒有使用 Outlook 了，Email 與 行事曆等，現在我都轉移到 Google 線上使用了。另一套 Desktop 版本，我有些捨不得購買，嫌貴了些 (需要 US$80 美金左右)。還有，我還是覺得該軟體有些不是挺滿意的地方，對於工作清單 (Task List)，我希望能有樹狀的階層結構，可以讓我容易去組織工作事項。所以後來我是轉由接觸 GTD 方法論，尋求是否有比較滿意的解決方案。 關於 GTD，國內推廣最力的莫過於 twhsi 了。而他也因為對該方法論的深入研究，而成為能打造所屬自己人生的時間管理專業講師了。而對岸則有兩個網站，也是致力於推廣 GTD， GTD Life 與 褪墨。這兩個網站整理了相當多很好的資源，尤以後者，作者不僅用心翻譯了許多國外時間管理專家的文章，自己也分享了諸多的心得，文筆非常精彩，內容論述很有條理，是相當值得推薦參考的部落格。

我著實看了諸多關於 GTD 的介紹，包括購買書籍與下載許多 GTD 軟體來使用。評估許久，至目前為止給我的一個感覺是，複雜了些。而且有個潛在的風險是，很容易被眼前許多細節性的事務給忘卻了中、長期的目標。這麼說好了，我會覺得 GTD 很適用在生活比較嚴謹有自律能力性格的人，以及在工作上比較負責的是行政事務之類的上班族。因為 GTD 會專注在對 "事" 的處理上，它不容易放過每一個細節；但是對像我這樣比較慵懶個性的人來說，觸發我主動做事的動力大部分不是上司的要求，而是基於我對個人所設定的目標實踐，以及對我所專注熱情的領域，例如軟體、期貨等。或者這麼說，如果我是一個殷實的上班族，工作內容絕大部分是來自於上司的交代，如何有效率地作好大小事情，我會利用 GTD 方法論來協助我整理與規劃工作上各類事物的輕重緩急；但是若只比較偏向那種以重點最主的做事，且經常會忽略掉細節性工作也不是那麼在意的，還有就是像我這種「目標導向」驅動的人來說，嚴謹地運用 GTD 方法論，可能不是那麼恰當。 當然，這可不是絕對，畢竟，GTD 必然也有它的精髓與諸多運用的方法，我們只是要瞭解與注意一點，不同性格的人，就會有不同的運用方式，「因材施教」，這點比較重要。

相對於 Covey 重視的是全方位的時間規劃管理，GTD 是比較有專注在 "事" 的處理上。我會覺得若能運用兩者的精髓，搭配與互補，恰恰能達成成功學常講的：「作對的事 (Do the right thing)；把事情做好 (Do the thing right)。」

我是有這樣的想法，但是概念還是有些模糊，還有我還是有那種「完美傾向」的性格，時常在找尋那種所謂的「完美工具」上，但是又知道不應該被工具給駕馭，希望能以簡單的方式達成我心目中對於目標規劃與時間管理兩者的平衡上．．．。 性格與理智上的衝突，總要要能打開心結才能化解矛盾。前兩天瀏覽到 褪墨 所翻譯的 ZTD (Zen to Done)觀念，作者正是與我的觀念不謀而合！！ 它確實就是崇尚「簡約之道」，而又能完美地結合 Covery 的全方位目標規劃與重視行動效率的 GTD 理論。 Perfect！！ 關於簡化的 ZTD 觀念，可以參考上述的網址，共有 十三篇 相當棒的連續介紹與說明。我這裡只是大概簡單說明一下我所體會的心得。

從目標推回到現在要做的事情上，反過來就是說，你現在所做的主要工作，會是與你的目標關連。只要你認為做的這一件事，能讓你對未來所設定的目標往前一步，那就對了。例如，在人生規劃的目標上，希望能在中年約 50 歲前實現財富自由，然後在設定的子目標上，是以投機金融事業，包括股票期貨等為手段，那麼，你現在研究技術指標、交易策略與心法等，都是可以的，但是若你花了很多時間在打電動玩具上，那就很明顯方向有誤，相對你設定的目標，打電動是娛樂，那是在你完成某一個主要工作事項後給自己的一個獎勵而已。如何規劃與設定目標，這可以參考諸多成功學書籍，但有個最重要的重點是，一定要把它給寫下來 (Write Down)！！ 利用心智圖的圖像表達或是純文字的書寫記錄，都可以，但就是要寫下來，然後每週都可以隨時檢視與提醒自己，是否有往所設定的目標推進與調整。

知道自己的目標所在，你就容易可以分清楚事情的輕重緩急了，與目標相關的，就是把它視為是重要的事情，會優先排時間來完成它。在往目標前進的過程中，必然會有許多想法與心得，最好就是隨身有一本筆記本，隨時就是寫下來就是了。這也可以視為是 GTD 第一個步驟中所提的「資訊收集」，我是認為寫在紙本上會來得比較有感覺，而且又方便隨時隨地紀錄。對於筆記本的選擇，就是建議大小要能適中，可以把你的想法以文字記錄下來，甚至還可以素描畫圖。 Moleskine 這個牌子，也曾在電影與諸多畫家文豪的最愛，包括畢卡索與海明威等，都曾是它的用家，它可說是最被用來推薦記事畫圖的理想筆記本了。

從目標倒推回來，必然會分解成許多需要處理的工作事項，還有在現實上，也一定有不得不處理的雜務。如何讓自己能優先將焦點集中在重要的事情上，而不至於被淹沒在諸多繁雜的細節上，以 "週" 為單位的規劃，可以說是最理想的時間格局了。每一週的開始 (可能是從星期日)，花上 10~20 分鐘規劃本週最重要的工作，我個人是覺得大約 3~5 件就好了，不要太過貪心，而導致設定太多卻無法達成。大約分解許多小工作，分散在以 "日" 為單位的 "每日工作清單" 上。我個人的心得是，只要設定三樣即可！ 應該說，只要你能覺得當做完你認為是本日最重要的三件事以後，你會覺得會很輕鬆，有成就感，那麼，其它的細節性事務，就再也不會難倒你了，可做可不做，就可以很隨性而不會有太大壓力了。

如何規劃 "Weekly-plan" 與 "每日工作事項"，當然可以利用工具軟體來協助，未來得以隨時檢視與彙整。這裡我也是建議，應用簡單的工具即可，不要反被工具給駕馭了，而使得本末倒置。關於工具，到後來我其實主要只有一個需求，就是對於工作事項 (Task Item)，能具有樹狀的階層結構即可，如此我就可以決定是否要把工作事項再細分化，或者把諸多細節性工作整合在一個主要工作事項內。關於工具的簡單使用，就留待「工具篇」再來說明。

時間管理，是對自己的負責，而不是作給別人看，規劃太多或講太多，卻沒有付諸執行，那沒有用；但是規劃得太過詳細，凡事一扳一眼，造成自己甚至他人的壓力，那也不妥。我非常喜愛這一句話：
「生活原本簡單，是人們堅持要將它變的複雜。 —孔子」

【台北場】2008/04/12,13,20 (星期六,日,日)，共三日,１８Hrs。

農曆年後 HSDc 的第一場單元課程確定於四月份清明節過後舉辦。本單元課程是新設計的，我們希望能將焦點集中在系統分析三種觀點的設計與實現，也就是外部的功能觀點、內部的結構元素設計、與表達程式碼動態的物件互動；而這正是利用 UML 包括使用案例模型、類別圖與循序圖，號稱是 UML 三劍客所可以完成最精要的設計，也可以說這三者是在中小型的專案開發(我們定位中型專案在五千萬以內)最有效的設計利器。

我們一直主張，系統分析絕對不是與程式碼實作脫勾，在我們所揭露出的設計指引方針中，只要利用少數幾個設計原則，就可以很快速且直覺地從使用案例轉出到程式碼。而在其過程中，我們會建構代表每一個使用案例的控制物件，也可以把它視為是系統的代言人，先利用循序圖表達出參與者與控制物件的訊息互動，觀察出互動的訊息之後，再反回來設計分析性的控制類別，並很容易地就可以定義出它應該具備哪些 functional call。藉此，我們就可以利用如 EA UML 工具快速產出程式碼，得以建立程式框架。再來以後，我們就很清楚如何在控制類別的哪一個函式(method)上補充細節，包括演算邏輯、企業規則與欄位明細等。 系統分析與程式實作本來就是系統的一體兩面，若是無法保持這些設計產出間的一致性，那肯定是系統分析的作法有問題。

還有，我們從來都不主張寫文件，為文件而文件，那是最浪費時間與最糟糕的事。我們主張要做有效且精要 (essential)的設計產出 (artifacts)，量少質精，然後再利用如 EA UML 工具的 "Document Generation" 機制，絕對可以產出上百頁美輪美奐包括需求規格、測試文件、字彙表、結構設計文件 ...等，保證會讓主管滿意。而這些過程，只花不到五分鐘！

以功能需求為導向的開發模式，是順應國內專案短線的生態需求，所以我們先專注在建構分析性的類別，讓系統最起碼先有實體的 MVC 框架，能隔閡 UI 與資料庫的耦合；而
至於要讓系統能更順應需求的變動設計，則是在未來結構重整設計階段的課題—那是影響系統夠不夠有彈性，卻不是能不能做出來。我們主張務實，先做出來，並保留一些彈性，可以在未來資源充足與開發人員技能成長後，再施以結構的重整—也就是重構。

所以以功能為導向的系統開發，我們的兩個配套措施，一個就是分析性類別；另一個就是測試程式碼。這裡我們會揭露出 XP 最重要的設計精髓—測試先行 (Test First)，如何能確保爾後每次的需求變動，更改到程式碼時，就要確實能執行自動化的測試，以確保變更並沒有影響到既有的功能。

三天的課程內，我們除了會預先提供一個完整的案例，會帶領各位學員實際演練並產出設計模型與程式碼(包括測試碼)等，同時還會當場由學員主動提出案例，等於是出考題一樣，由講師當場示範講解，當然，還是從需求分析到程式碼實作，一氣呵成。

另外，我們單元系列的課程，均有免費提供下午茶點，包括小蜜蜂咖啡、茶飲、美味的吊鐘燒與餅乾甜點等。品味咖啡的同時，學習軟體設計思維，那會是一件令人相當愉悅的快樂學習之旅。

§課程名稱： 活用 UML 三劍客與實作程式碼

§課程簡述：
　o 介紹系統分析的設計觀點與 UML 三劍客觀念引導。
　o 利用使用案例來捕捉系統的功能性需求，並快速導出到程式碼實作，以及撰寫測試程式碼驗證功能的正確性。

§課程目標：
　o 讓學員瞭解系統分析的基礎觀點 (需求功能觀點、結構設計觀點、實作觀點)
　o 引導學員如何活用 UML 三劍客 (使用案例模型、類別圖、循序圖)。
　o 帶領學員建立使用案例模型 (Use Case Model)，並佐以分析類別與物件循序圖，快速導出到程式碼 (Java)的實作。

§課程特色：
　o 提供完整案例，示範與引導學員實際操作與練習。
　o 第一日上課時即會發送給學員教學光碟，內容提供 EA 7 試用版、JDK 1.6、Eclipse IDE 與本課程案例所有產出，以及研討會簡報等。
　o 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利，以一次低廉的收費，就可以擁有兩次上課的收穫，課程的師資、內容與品質，我們有信心是不會讓學員們失望的。

§準備教材：
　o 由授課講師提供講義，包括教材內容、案例分析與範例。
　o 學員可攜帶相關 UML 參考書籍，並對於書中內容有問題者，可以直接提問。

§使用工具： EA(Enterprise Architect) 7.0(Trial) UML Tool、JDK 1.6、Java Eclipse IDE。

§授課講師：
　o 賴信仁(Ringle Lai) ,王克明(Kenming Wang) ,宋敏如(Cathy Sung)
　o 擅長以非常淺顯易懂的比喻及說明，將複雜的系統抽絲剝繭，重新釐清脈絡，讓學員一清二楚，並善於引導學員具備設計應有的反思能力。

§適合學員：
　o 系統分析/設計(SA/SD), PM, Programmer 等在職軟體開發者。
　o 學校資訊講師/在學相關資訊科系學生。

§課程費用：
　o ＄５,７００ (含稅)。
　o 曾經上課過本公司的「單元系列課程」學員，優惠 ＄５,１００，含稅。(請記得註明為舊生，本公司查詢確認即以優惠算)
　o 三人同行，或同時報名另一單元課程，亦比照舊生的優惠折扣，每位只需＄５,１００(含稅)。
　o 大學/研究所 資訊相關科系講師、助教或教授，出示相關證明，我們會以建教合作方式計費。(請另以電話聯絡)
　o 清貧或由家扶中心推薦，能出示相關證明，所有費用 免費！！

§報名資訊：

授課日期：
　o 2008/04/12, 13, 20 (星期六, 日, 日)，共三日。(AM 9:30~12:30、PM 1:30~5:00)
授課地點：
　o 開羅會議中心，地址：台北市光復南路65號B2 (光復南路、市民大道交接口)。
　o 參考交通與地圖。 http://www.hsdc.com.tw/education/cario_map

o 由於本站線上報名系統尚未測試啟用，煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫)，並以 Email 寄至： service.hsdc@gmail.com
　　-------------------------------------------------------------------------------------
　　* 姓名：
　　* 電子郵件：
　　* 聯絡電話：
　　任職公司與職位：
　　備註(請填上如 ATM 轉帳帳號(後五碼即可)與新生或舊生等資訊)：

　　-------------------------------------------------------------------------------------
　o 報名經確認後，本站即會寄送確認通知信給報名學員。
　o 為確保報名足額人數，煩請先以 ATM 轉帳預約費用($500)，並請於報名表備註欄位內，註明您的轉帳帳號末 5 碼與轉帳金額
　　(若實在不及轉帳者，仍可現場報名，但請在報名表內註明)。
　　ATM 帳號： 新光銀行 (103)　帳號： 0772-50-100979-9

【課程大綱】

※ 基礎觀念引導—UML 三劍客觀念引導
　o 瞭解系統的定義與系統分析的角度
　o 系統的功能需求—建立使用案例模型 (建立需求規格模型)
　o 系統的結構設計—類別圖 (建立分析性的類別)
　o 系統的物件互動—循序圖 (表達參與者與控制物件的互動)

※ 建立使用案例模型 (Use Case Model)
　o 利用使用案例圖表達系統的功能需求
　　o 如何界定系統範圍(System Boundary)
　　o 如何找出使用案例與參與者(Actor)
　　o 使用案例之間的關係— include and extend
　　o 利用使用案例圖表達架構觀點
　　　o 界定與分析使用案例模型的廣度的層次
　　　o 如何利用使用案例表達企業層次與應用系統面層次
　　　o 多個系統的使用案例圖架構設計
　o 從表達企業流程的活動圖導出到使用案例圖
　o 使用案例敘述(Description)的寫作實務
　　o 如何寫出高品質的使用案例敘述
　　o 如何依據使用案例範本完成使用案例敘述的撰寫
　　o 如何表達正常、替代、擴充與例外事件流程的敘述
　　o 寫好每一條動作步驟陳述的要領
　o 針對每一個使用案例，撰寫測試案例 (Test Case)

※ 從使用案例導出到程式碼實作
　　o 案例分析(Case Stydy) — 使用案例的實現(Realization)與實作(從使用案例到循序圖到產出程式碼)
　　o 設計與創建 Use Case 控制物件，以實現使用案例的功能需求
　　o 利用 EA "Code-generation" 功能產出控制物件的程式碼框架
　　o 測試先行—在 IDE 工具內撰寫該控制物件的測試程式碼
　　o 利用虛擬碼(Pseudo Code)撰寫程式碼內部的細節
　　o 實際執行應用程式碼的部署與執行功能測試
　　o 利用 EA 反向工程功能，在 IDE 環境內修改程式碼，並反轉(Reverse)回 UML Model。

※ UML 三劍客 實務操作練習與完整案例演練 (利用 EA 7.0 工具)
　o 利用 EA 與 Eclipse 實現一個完整的案例 (從需求分析到設計框架到實作程式碼)
　o EA (Enterprise Architect) 的安裝與基本操作介紹
　o 利用 EA 繪製 UML 三劍客設計圖
　o 利用 EA 產出文件 (Document Generation)
　o 利用 EA 產出程式碼 (Code Generation)
　o 利用 Java Eclipse 修正程式碼並反轉 (Reverse)回 UML Model
　o 利用 JUnit 依據測試案例實現測試程式碼，並執行自動化測試

※ 課程回顧複習、問題提問與討論。

副標題：懂得從各問題領域的表象中跳脫，而能直指其核心的本質，才是軟體結構分析的根本所在！！

Object Models — Strategies, Patterns, and Applications 　----------------------------------- 　作者／Peter Coad with David North and Mark Mayfield /著 　出版社／Prentice Hall 出版 　ISBN／ 013-840117-9

內容簡介
Object programmers can now learn how to get faster results using the strategies and patterns (templates) uncovered in this book. Without them, however, the much-needed expertise is only acquired by trail-and- error. Using sufficiently detailed, real-life examples, this book/disk package shows how to build effective object models--using applications that occur in nearly every industry. Presents six chapter- length application examples of how effective, real-life object-models are build--e.g., point-of-sale, warehousing, order-processing, data acquisition and control, and sensors and diverters. Each application reveals specific "how-to" strategies (101 total) and patterns (22 total) that will help readers develop an intuitive feel for building object models. The diskette features an on-line verison of the strategies and patterns summary (in the form of a Windows help file); as well as C++ course files, illustrating a reasonable (but not the only way) to implement each pattern. --This text refers to an out of print or unavailable edition of this title.

前言

我擔任多家公司，包括各類領域(金融、鋼鐵、保險、零售、股票 …等)的系統開發顧問期間，遇到最常見的“通識”就是資訊主管幾乎清一色要求 SA 要能懂得相關領域知識 (domain knowledge)，認為這樣才能作得好系統分析。殊不知，SA 最多只能代表著操作人員 (operator)層級的功能需求分析而已，領域知識的核心，包括企業流程的制訂改善等，是由領域專家 (domain expert)所掌握的。 SA/SD 太偏重領域知識的結果 (在台灣，SA/SD 的分界一向不明顯，可能是 SA 與客戶訪談需求，然後由 SD 作 E-R Model 資料庫表格的結構分析)，卻忽略於軟體結構分析的技能培養，所抓出來的 Entity (經常呈現為資料庫表格)，往往就是耦合性 (coupling)太重，牽一髮而動全身，無法應付變動性。

個人經常奉勸 SA/SD 並不是具備領域知識，而是應該要懂得如何與領域專家的溝通合作，將其核心知識抽象而成為軟體系統的結構，所以要具備的應該是結構分析的萃取能力，那是一種可以獨立於各個問題領域 (domain)與 IT 平台技術的一種技能，我常之為“純”軟體的抽象分析的專業技能。聽起來很玄？ 好吧，套一句軟體界常用的術語，就是所謂的物件導向分析與設計的技術，但是那卻非從程式語言、平台技術、或者領域知識等從之學習而來的，那種抽象 (abstract)能力的培養，是需要懂得對事物本質的體悟、感知能力與大量的觀察及動態學習等才能獲得的。老實說，軟體的樂趣正在於此！

以筆者所擔任各大企業軟體顧問為例，起碼接觸到有 2、30 種各類不同的領域，我們是不可能具備各專業領域知識的，但總是能與各領域的專家合作，從三言兩語的對談當中，就能很輕易的抓出該領域的核心結構，並可以馬上就利用如物件圖的案例來檢驗其結構的正確性以及變動的彈性度等，是相當經得起考驗的。對這種跨領域與平台技術的抽象能力的建立，說真的，我們顧問的利器，最早是源自於對本次書評要介紹的主角，是有花了許多功夫的學習，並從實戰當中的印證體悟，才慢慢得以建立起這樣的技能。光是透過書中介紹的“交易樣式”，就得以讓我們橫跨各領域，抓出最穩固的核心結構元素，實在受用無窮。

直指企業核心的本質—交易樣式

本書主要的作者為 Peter Coad，最早研究所教科用書，有許多就是採用他的著作：“Object Oriented Analysis、Design ”兩本經典 OO 著作；不過軟體人員對他仍很陌生，那麼說出 Borland Together，就會恍然大悟，原來就是他創立的公司研發的主力產品 (後被 Borland 花了兩億美金併購)。

先讓讀者瞭解一下，結構分析主要就是抓各領域的穩定元素來建構軟體系統，而那往往就是常在溝通的概念術語 (concept terminology)。在設計階段一般是以 UML 類別圖 (class diagram) 來呈現，而具體化在應用系統中的就是所謂的企業物件 (business object)；與在資料庫的表格 (table)。兩者的差別主要在於企業物件尚需分析各個物件所應負擔的責任 (在程式語言則稱之為 方法, method)。分析領域物件與明確分派物件的責任，正是影響軟體結構彈性度的主要關鍵。

有別於絕大部分 SA/SD 是透過需求訪談記錄一個一個的抓“名詞”，雖然是行之有年，但那實在不是一種好方法，所抓出來的類別往往見樹不見林，無法有效的將相關的類別關連於一起。 Peter Coad 是直接直指領域核心，觀察企業行為的本質源自於交易。交易為商業利益交換的一種契約 (contract)，是一種非常必要保存的事件 (event)記錄，再由此為中心，來串連其它相關類別包括 參與者 (actor)，地點 (place)，物品 (item)，以及所包含的交易細項 (line-item) 等。這種先抓主幹，再抓枝葉的方式，正是相當著名由 Peter Coad 所揭露的 “交易樣式 (transaction pattern)”。

以最常見的訂購系統來說好了，“訂購(order)”就是核心的交易類別，再由其串連出來，就可以找出“訂購細項(transaction lineitem)”、“客戶(actor)”、“訂購地點 (place)”、“商品項目(item)”等；再轉分析另一個領域如保險業，“保險”絕對是一個顯而易見的交易類別，而“對保”則是與之有相關連後續的交易類別 (subsequent transaction class)；好啦，如果是要分析一個運動彩券投注系統，要你馬上抓出第一個類別，應該就知道該怎麼抓吧？ (投注, 派彩 均為該領域的核心類別)

不同層次，傳不同層次的法

我是從 amazon 購買 a4-size 的硬本精裝版，本書可是有著四顆半星的高評價，讀者對之推崇甚高。封面為樂高玩具，甚是有趣，看起來其隱喻應該是意指軟體的結構組成，就如同樂高積木般，一個個地給聚合組裝起來的。共有七個章節，前五章均為各自獨立的案例分析，後兩章為策略與樣式的整理列表。印刷很不錯，字體大小恰當且清晰，也有很豐富有趣的插圖。不過內容可是相當艱深，沒有充分的抽象與想像力，是不容易理解的。獨立閱讀本書可說是非常吃力，我是建議能有幾位同好們一起研讀，甚至以角色扮演的方式，來思考所抓出來的類別，以及所賦予其責任的合理性與正確性。

本書的類別表示法均是採用作者自創的語法 (Coad Notation)，它可說是自成一格，例如多重性(multiplicity)就剛好是與 UML 類別圖的表示法完全相反，所以一定要先閱讀附錄的語法說明。再則從每個案例研討的過程當中，作者總是會列出他在某個分析階段時所使用的策略或樣式，並將之編號整理在後兩個章節。這個相當的有參考價值，但不要直接就是翻閱這些策略與樣式列表，那可是相當的枯燥乏味，最好就是配合著這些案例的過程說明，久而久之，你閱讀起來才會習慣也比較能有感覺。

誰需要閱讀本書呢？ 我是覺得想立志當個真正的“軟體人”是必備的。要知道，軟體設計大概可以分為三個層次；1.把系統“做”出來；2.讓系統效能好一些；3.讓系統更有彈性，來順應變化。 第一個只要有不錯的實作能力，以及功能需求的分析能力即可；第二個則需要有對平台的專業知識能力，能充分發揮系統的效能特性；第三個那可真的需要對軟體的“道”有著長期持續的信仰與熱情方可。我是以為，若能進入到第三個層次，修練該層次所傳授的法，那絕對會是一種無以言語的喜樂。不過，現今國內軟體產業重視速食文化，大約只要求在前兩個層次，第三個層次，曠時廢日，不太容易短時間內有著顯著的實質回饋，因而堅持者甚少，殊為可惜。

剛剛 (03/05 PM23:10) 左右，要向「博客來」網購書籍，點選購物車快速結帳(我發現到，名不其實，根本沒有快速)，光是要選個 {7-11 取貨門市}，點選了好幾次，網頁就一直在那邊轉著，沒有啥回應。吼，已經忍受他們不理想的購物介面好久了，此時實在不吐不快！

我應該算是他們多年來的忠實用戶了，現在買書，幾乎都是在該網站買書的，主要原因可不是方便，而是便宜。對我而言，只要書比外面實體書店便宜、取貨快速(這點博客來被統一集團併購後，透過該物流的確非常迅速)、再來就是買書時簡單乾脆，也就是購書的流程能越簡單越好 (喔，還有啦，最起碼基本資料也不應該被外洩的)。

其它諸如搜尋系統之類的，是另一回事，我主要最不滿意的，就是那個「選擇 7-11」的功能。吼~ 如此差勁的設計，幾年來還是沒有任何長進！！ 我知道他們的作法肯定是把所有的 7-11 店家，以及全台灣省鄉鎮縣市給全部塞到網頁這邊來了，大概就是利用 JavaScript 之類的動態網頁技巧把它給實現功能。介面要作得好，這其實設計與實作並不困難，從需求面來看，舉個例，我就打個 "興南"，就會列出 興字開頭的店家、或是興南路等都可以，簡單的說，我可以利用很隨性的打上幾個關鍵字來搜尋門市，就可以篩選列出店家。我只是列出其中之一的作法，其實要能設計更便利的介面方法肯定有很多種，任何一種我看都會比現在你要透過選擇框，先選哪一個縣市，再選路名，吼(再來一次吼聲)~，我們家中和，每次我要選到那個興南路，總是要用滑鼠拉著捲軸找好久，每次拉我總是嘴裡碎碎唸，什麼時代啦，還有這種介面啊。

我曾經寫過一篇：「Javascript 是爛東西？」，其實要提醒軟體設計人員，不要以為有些資料的取得方式是很固定，不容易變動，且可能資料量不大，所以乾脆先一次給全塞到最前端的網頁來，再透過具有動態效果如 Javascript 的網頁語言來操作存取，就是所有的動作都是在網頁(已經與 Server 無關)給全做掉了。在網頁塞了許多不必要的資料，或是讓網頁這邊處理企業邏輯等，這都不是好的設計方式。

無論如何，像這種大型的購物網站，是屬於交易型的系統，也就是稱之為 OLTP(On-Line Transaction Processing)的企業系統，除了在現實上，效能與穩定是必然的要求外，其實在設計上是蠻重視 UI 與在後端系統 (後端系統我比較偏稱之為 Application Server，而不僅是 Web Server)的互動過程，也就是需要向系統動態要求取得或處理資訊，這是一種屬於對話互動式的設計作法。所以當以 {選擇 7-11 取貨門市} 這個案例來說，使用者 (UI)會需要與後端 AP Server 一到多次(可能會有兩三次吧)的互動，才會取得最後的結果，反而這樣的方式在操作過程中，會比較順暢且簡潔。

我估其他們不這麼做的原因應該是考量到了效能 (performance)，其實這真的也蠻好解的，我再強調，是與後端 AP Server 互動，並不是每一次都要連到資料庫操作的。由於資料量實在不大，台灣全省鄉鎮縣市 加上好幾千家的 7-11，在記憶體也不會佔用多少。所以也可以利用如 "虛擬DB"，也可稱之為 MemoryDB 的設計方法來達成的，是絕對可以兼顧效能與彈性的，沒有問題的。

結果我這篇文章寫了一個小時，再去點選那個 7-11 門市，再一次的給它吼~ 還是不能點選耶！！ 拜託啦，這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果，嗯，相關單位對該功能還是不知道該如何設計與實現的好，歡迎來找我們聊聊吧，不是只有唸唸空談而已，如何提供具體的解決方案，這點倒是還瞭解的。