[X] 網誌的最近變更

導引投影片下載頁面 [ 請按此 ]

功能真的是隨便用直覺式作法都可以完成
但是為了系統的彈性與品質，就需要額外投入時間來作設計
"做得快"與"做得好"，這兩個條件通常是互斥的
我相信－－
唯有適當的佈置與對應的工具，才有機會讓系統開發又快又好

[投影片進度]
已經製作單元 － 12 (完)
文章關聯建立 － N/A

[最近修改]
2009/07/14 － 導引投影片的內容製作完成。（還沒建立文章關聯）
2009/07/18 － IBM網站這篇MDD的文章 [原始網頁] 表達了程式碼與模型的相輔相成；RUP課程的講師的教授內容也很棒。
2009/10/24 － 推薦一篇文章：[別把專家當笨蛋] (吳俊瑩)
2010/01/13 － 兩個 Google協作平台都被關閉，發信詢問的回信：We disabled your Google Sites site for violatingone of our Terms of Service or our Program Policies。連放置自己寫的程式都不行？
2010/01/17 － 重新申請一個[協作平台]放置自製的投影片，至於程式產出就當作做開心的吧。
2010/01/20 － 如果感覺內容太雜亂，請先看[Y01]、[Y11]、[Y12]、[Y13]與[Y14]後再瀏覽[導引投影片]，就能大致明白我想做什麼。

X33 熱水器瓦斯氣爆的親身體驗

嚴重警告：此為極度危險之測試個案，沒有練過切勿依內容重現！！

緣由：在變冷的夜裡準備泡個熱水澡，卻發現熱水器的電池沒有電了

準備：將剩餘量大約2/3的20公斤瓦斯桶妥善連接到使用將近十年的瓦斯熱水器，點火用的電池先故意拆卸下來以模擬沒有裝好的狀況。

操作順序：先將浴室的熱水水龍頭轉至最大流量，大約15秒（最好不要超過，以免效果過強）後在瓦斯熱水器還有點火動作時將電池裝好，應該可以立即看到成效。（頭部距離熱水器不超過半公尺）

結束：此時的瓦斯熱水器的火依然沒點著，使用後切忌要將瓦斯關閉。（每15秒重覆裝電池的動作是否能持續重現同樣效果不得而知）

體驗感覺：以人體的五感加上發生前、發生時、發生後加以敍述。

●發生前
視覺：專注在安裝瓦斯熱水器的電池。
嗅覺：無。（若已能聞到瓦斯味，請立即中斷並在半小時後重新進行）
聽覺：無。
味覺：無。
觸覺：因天氣冷而感覺微涼。

●發生時
視覺：眼前瞬間冒出直徑接近一公尺的鮮黃色火球，並立即消失。
嗅覺：無。
聽覺：轟然一聲。因距離過近而無法判斷有多少分貝。
味覺：無。
觸覺：臉上有些微暖意。

●發生後
視覺：因視覺暫留而有短暫黑暗，約1至2秒後能再度看到瓦斯熱水器。
嗅覺：無。（如有焦味表示耽擱時間過久，可以考慮重做）
聽覺：聽到剛才的巨響在遠處傳來多次回音，並且夾雜數次鄰居開門或開窗的聲音。
味覺：無。
觸覺：臉上仍有些微暖意，不知是被火烘的還是怎地。

結語：前兩天才在電視上看過一段救難訪問，其中的消防人員說“明明目前什麼都很好，卻沒有辦法知道下一秒會發生什麼重大的改變”，現在深切地明白其中意味。

事件從開始到結束真的只是一瞬間的事，連眼睛都來不及眨而完整目睹過程；而且心裡並不像其他人所陳述那樣會將人生重要時刻快轉一遍，根本只是保持完全地空白。

最後，問了一下在旁見證的小朋友說我有沒有變捲髮？聽到“沒有”的回答並且到浴室鏡子前確認沒錯之後，留下了這份記錄。

後記：更換新的熱水器時，我同意安裝人員使用內附的瓦斯控制器。看到拆下的管線上連接著幾個月前購買的瓦斯防爆器，內心真有點五味雜陳；原來是是有這麼多的巧合放在一起才避免一場可怕的事……。

X32 程式寫作員的未來(10)──便利的學習

前幾天派駐國外專案的人回來，談到一位從台灣過去支援的同事學習上發生的狀況，同時提起國外客戶訓練新人的時間很短、而且訓練後人員的素質都有一定的水準；回頭看看自己的團隊，總是覺得距離那種程度還很遙遠，主要是因為沒法產生出有助學習的文件而只能請新人“自己看，有問題再問”的緣故。

在系統開發方面，可以想像新人面對兩種不同開發方式時所遇到的情況：在沒有工具的狀況下只從系統結構面切入，需要學習的深度與廣度範圍過大且不容易找出規則順序都會帶給新人很大的負擔；在使用開發工具的狀況下，對於需要關心的內容都已經被收集在工具裡，而且是順著思考邏輯（僅有少數實作被參考）編排，比較有助於新人進入狀況。



當新人比較瞭解開發規則後，都會需要跟隨著進入程式碼研究實作的方式，這時候就會遇到程式碼很難看懂的問題。連幾位資深人員都互相認為其他人的程式碼寫得很難懂，又怎麼能期望新人要快速看懂他們的程式？運用一些撰寫思考習慣的改變，鋪陳出任何一個“正常人”都能迅速讀懂的程式碼應是資深者的責任。將寫程式的目標從“電腦上正常執行”拉抬到“讓人一看就能懂”卻是極少人會去做的。

運用工具輔助開發人員明瞭系統開發的範圍與方法，需要深入研究時就由工具與程式實作的介接點進入，進入後的程式碼使用符合人類思考的面向編排並包裝。這樣的安排將有助於快速進入任何一個有興趣的區塊之中研究。

最後，故事再回到最原始的那張硬體架構圖。這個時候看著這張圖，心裡想架設在上面的系統是什麼模樣的呢？

X31 程式寫作員的未來(9)──知識的集中

要完成一件有目的的事，都需要知道其初始狀況、結束狀況與做法，還有必要的輸入資訊與輸出資訊；開發系統時自Use Case往下攤開更是有數不清地大大小小的事需要實現。每個人都各自負責一部分的事，但是要如何知道其他人是怎麼做事的呢？當然有文字與圖形描述的記錄會是比較容易看懂的。

除了如何讓成員心悅誠服地為了他人製作出符合範本的文件之外，怎麼妥善保存與利用所有有價值的產出也是個值得深思的議題。撰寫計畫書時需要某項產品的市場資訊，該市場共有三位業務負責，每一位都說不知道其他兩位有沒有更好、更適合的文件，寫計畫書的人要怎麼辦？某個專案開發時借用客戶的伺服器作為版本控管用，很久之後結案時沒有人備份下最後的版本，每位參與過的成員都說手上有他離開時的版本，現在有個問題需要修改最後程式再上版，公司該怎麼辦？

資訊的保存同樣可以根據共用的類型來決定存放的位置，從最底層依序向上（參考）或許可以分為個人、專案、業務、領域、平台、公司等，每一件事物都根據其應用的範圍放在對應的類型裡，輔以全文檢索的功能。每個人大多都會保留住經手的內容，除了分門別類之外甚至還會依時間版本存放，但是層級向上提升之後的資訊管理就不見得能夠做得理想。影響的因素當然很多，成員們是否認同知識管理的意義卻也佔了不少比重。

我們都習慣到Google搜尋不明白的事物，但是網路上絕對搜尋不到同事用什麼想法建置手邊的系統，也查不到某一段程式會這麼寫的原因，這些專案特有的人為動作如果沒有記錄就會是消失的謎團。正是因為經歷過不少這樣的謎，才知道知識的集中會是影響團隊戰力的重要因素。

X30 程式寫作員的未來(8)──重用的資產

運用交易開發工具可以加快開發速度並做到一致化的產出，如果再進一步分析出交易開發地圖讓開發人員按圖逐一填寫，完成後就等於完成一支交易的訪談。交易開發地圖與業務流程地圖雖然對象不同，但是在基本概念上是很接近的：都是定義其流程、各個步驟與步驟內應完成的事，而這些最終都對應到交易的各個組成單位。

關於“物”所能做的“事”，可以將物定義為一個Interface再將可做之事定義為Method，但是以Strategy方式設定會更有彈性。例如前面提到的身份證欄位，與其使用Interface包含validate、getLocation、getSex等三個方法，倒不如將之獨立為數個Class由工具列出來讓使用者自行勾選要執行哪些來得方便且有彈性。這幾個身份證欄位可做之事（Class）是每個系統都會再重覆用到的，因此需要Reuse Repository來管所有重用項目。



藍色的虛線框裡表示的是使用交易開發工具產出AP執行環境內容的開發模式，Reuse Repository的角色是提供重用的資產給這兩者，不管是加快開發時的設定或是減少測試的時間都會有相當的成效。

Reuse Repository會有一套進管的機制來管理所有的重用項目，同時也要有一套建立版本的機制──該機制會將儲存庫的內容產生兩種版本：一種是給執行環境使用的執行函式庫與預設參數，另一種則是給交易開發工具使用的畫面與欄位資訊以及搜尋用的關聯檔。



上圖是Reuse Repository裡應該管理的項目，以及各個管理項目之間的關聯；關聯的用途是在交易開發工具裡編輯該項目時會列出符合篩選條件的其他項目。例如要新增某個交易畫面時，會列出儲存庫裡該畫面內所有的欄位，開發人員只要勾選這次畫面要用的就能帶入原有的欄位設定；當然逆向的關聯也可以查詢，像是選擇某個欄位得知在哪些畫面裡存在、甚至哪些業務裡有用到。

Reuse Repository在交易開發工具裡是很重要的一環。若可以再堅持所有該管理的項目都被儲存庫管理，還能夠達成所有管理項目都有各自目的而完全沒有重覆的“絕對重用”目標。

X29 程式寫作員的未來(7)──完整的工具

（先聲明，工具的結構還是概念性的想法，還沒有完整地串接起來。若有不通暢的地方請自行想像並連結。）

Application Editor與Transaction Editor是提供給開發人員使用的工具，但是系統的開發必須倚賴系統如何架構，因此還需要有架構人員所用的Framework Editor（技術上的）與介接交易與框架間的Application Framework Editor。它們與系統架構的簡單關係大致上如下圖。



系統開發時除了編輯系統與交易之外，有些會直接引用框架編輯器來編輯與框架相關的內容，編輯的成果都會存放在開發專案的工作區裡；要匯出為執行用的資訊時就經由Deploy Tool根據選用的範本轉出對應技術使用的內容。各種編輯器、Deploy Tool與系統架構的概念關係圖如下：



建立系統架構就已經是一門大學問，很多時候得經過多次修修改改才能勉強順暢執行，要維持不變的定義又增加了一些難度；編輯工具的架構與抽換範本的功能之規模（如果想做到“萬用”的話）也是相當可觀的。會不會有哪一天，這樣的概念為人們所接受而投入資源進行發展呢？

X28 程式寫作員的未來(6)──系統的開發

曾經問過公司裡幾位資深的專案成員，請他們簡單描述心目中理想的開發工具是什麼？他們在開發系統上的期望都很一致：希望有個工具指引SA進行交易需求訪談的步驟，依序完成後可以自動建立可在系統架構下執行的交易骨架，同時產生需求規格書（給客戶驗證）與設計規格書（給PG開發），PG依據設計規格書將交易開發完成。



專案的開發模式為了爭取時效，大多只由SA根據需求規格書範本作訪談並填入結果後，就讓PG以人工方式建立所有相關內容並進行開發，設計規格書幾乎都從缺；測試出與需求有關的問題有時會發生沒有同步修改需求規格書的問題。從需求到可執行內容之間有很多需要記錄且有緊密關連的內容，全部交由人工製作時不僅比較花時間而且易產生錯誤，如果真的有這麼一種交易開發工具的話……。

公司裡較資深的技術人員的走向都是往快速建立可執行的系統架構，認為工具只能作為輔助設定的用途，唯有我在思考著定義可以增進開發人員產能的便利工具（我想，是因為從系統架構層層堆疊設計到工具並不在“可執行”那條捷徑上吧？），有時就會戲稱自己為“工具型”的資訊人員。2010年第一季試做了交易開發工具部分概念的POC，試用過的四位SA一致認為運用這樣的工具可以節省現行開發方式25%-33%的時間。

分析一個交易的組成單位大致有：主要的畫面、畫面邏輯、欄位、欄位邏輯、Context欄位、交易流程、交易參數（根據交易流程中使用的商業模組而來）以及次要的週邊控制、報表格式、電文轉換等。我認為不管要開發什麼用途的系統，幾乎都可以套用這些元素來定義交易內容，因此才會有“萬用交易開發工具”的想法；至於系統tier切割的差異，同樣使用替換“範本”的概念來對應不同的實作。

交易開發工具會有以下幾種不同的編輯器：
●系統參數（AP層）──編輯環境與系統面相關參數
●Context（AP層）──編輯Context欄位
●交易流程（AP層）──編輯交易流程
●交易參數──編輯選擇交易流程後所有商業模組的參數
●畫面──編輯畫面、畫面邏輯、欄位與欄位邏輯
●報表──編輯列印的格式與相關處理
●電文──編輯主機電文轉換與相關處理

X27 程式寫作員的未來(5)──不變的定義

系統架構必須在很多地方維持不變的才能持續運用相同的工具來開發，這在運用自己程式建立的系統架構上比較難達成。原因是在進行客製化的開發常會改寫原先的設計（尤其前次開發堅持只做滿足需求的最低設計時），要讓系統架構維持住原有的運行模式已經很不容易，更何況還要滿足讓工具持續原有的開發方式？工具有很大部分必須是依賴系統架構來決定作法，以滿足執行需求的想法來開發系統是不可能設計出好用工具的。



使用別人做好的框架可以加快開發速度，因為其他人已經將他們的經驗值包裝在框架軟體裡，甚至還提供對應的編輯器來輔助，這時工具的重點就落在框架上因應專案而自行開發的部分。開發者當然可以什麼都不定義而只確保系統能執行就好，但是若希望運用工具來管理更大的開發範圍，商業模組化的設計加上貼近開發人員思維的定義勢必是考慮的重點。



將使用與實作切割好的話，還有機會達成只使用一套工具卻可以產出不同系統架構使用內容的理想工具。在工具上定義好系統可以做的所有“事”，在將匯出編輯結果時根據定義好的範本（虛線框的部分）產生適合在不同架構下運行的內容。倘使工具的範本再進化為可以因應不同硬體架構且能夠選用不同技術組合的各種不同範本，那麼只要再管理好資料與程式邏輯部分，就有可能只運用一套工具來開發各式各樣的系統。



這個理想工具雖然目前只是推測，但是在邏輯上推演卻是有可能實現的，不過在沒有資源的狀況下，這種龐大且複雜設計大概就只能想想而已吧。

X26 程式寫作員的未來(4)──編輯的範圍

對工具的用途沒有深思的時候，通常認為工具僅止於提供較多便利的功能與加快使用者編輯的檔案編輯器而已；以這樣的想法定義系統開發工具，就會將工具的功能侷限於設定檔與流程定義檔的編輯。這些檔案只是整個系統設計所外露的一小部分，對於開發人員來說還是有很多難以瞭解的地方。

Maven很成功地將持續整合建立產出的目標，定義為多個抽象的步驟，開發人員根據專案的需要決定從程式碼到產出之間要經過哪些步驟、每個步驟要執行哪些活動、再為每個活動指定實作的plugin來進行。它的作法並不是把設定檔攤開，而是以開發者的角度制訂建立版本時想要做的事，那件事要怎麼完成就由plugin來進行。

思維從編輯檔案內容拉高到要做的事情後，可以用不同的視野來看。像是server url與port，原來看xml設定檔時只會想著：要改哪個檔案、節點的xpath在哪裡、值要怎麼放，換一種連線功能時得換哪裡；將實際的設定包裝在plugin裡之後，實作的細節由製作plugin的人關心，開發人員只需要在編輯頁面的對應欄位定義server url與port並選擇實作的plugin而不需要知道設定到哪裡去。

這個想法同樣可以應用在畫面上的欄位。例如與顧客身份有關的畫面都會有身份證（ID）欄位，針對欄位存取值是基本用法，但是欄位有哪些事可以做、怎麼設定要做的事卻是工具可以做的功能。在身份證欄位這個“物”確定之後，像是validate（檢查碼驗證）、getLocation（所在地）、getSex（性別）這些“事”都是它特有的操作，因此工具在選定身份證欄位後就能列出所有可做之事並勾選要做的。

若要將整個系統的開發範圍定義為開發工具的話，每一個集合範圍都應該要對應到一個專有的編輯器而不要混用。例如需求分析後定義系統層次為系統─業務─交易─欄位四種的話，就要設計四個對應的編輯器再依照擁有關聯定義串接的關係，這樣才會比較貼近開發人員的使用習慣。

X25 程式寫作員的未來(3)──想法的分享

交易的執行流程與使用的商業模組應由資深的SD來分析並依架構來設計，怎麼撰寫與如何使用也會關係到開發人員的運用程度，如果他們不懂就會做不好、做不對。若考慮專案開始時開發人員學多少東西？新進人員要多久才能獨立作業？建立執行架構與設計商業人員為他們準備了多少東西是很關鍵的因素。

身為資訊工作者，在使用別人的函式庫時都知道要看說明文件與範例程式，但是在自己建立架構或撰寫程式時卻有種種的理由敷衍地寫出根本沒用的文件。在維護時而看過幾種不同風格的程式碼，只能就不懂的部分逐一請教原來的作者；有能力足以獨當一面者嚷著不想看別人的程式的，也有人連自己以前寫的程式都不想看而叫別人先看再說的。

有許多資訊人員僅以“使用流行技術來達成客戶需求“作為成長的方向、精進自己的各項技術，卻吝於對其他人清楚地溝通或分享自己產出的成果。抱持著”我會的東西是自己花時間看來的，沒有理由讓別人不勞而獲“的想法固然沒錯，但是在一個團隊裡以這種心態相處到最後就會發現沒有人提升到能與自己討論的程度；只靠一個人的想法無法兼顧各個面向的需要，卻又沒有人能夠讓他領悟問題的所在（因為技術好的人通常會看不起技術差的人），問題一直都會是問題。

工具，有提升開發速度外還能夠呈現設定的範圍的效果，想想使用記事本與IDE撰寫程式的差異便能明白其中奧妙。工具要能存在，它編輯的對象必須是百分之百明確且固定，才能在其上設計出符合其特性的工具。可惜的是我們總喜歡用別人的方便工具，對自己的產出總是以能夠正常執行目標而難以維持規格一致，再加上工具是另外開發與系統運行完全無關的，以至大多數的人無視它的重要性。

X24 程式寫作員的未來(2)──框架的使用

經過同領域的數次專案洗禮，很快就會明白只管達成功能的作法會造成許多不一致的災難，包括想改一個問題得調上百個程式或是改問題就像倒骨牌一樣改好了這邊卻壞了另一邊，這時會開始使用框架的設計（當然，也有加快開發速度的考量）。無論是使用其他公司提供的或者是自己設計的框架，都會在系統架構上定義一些規範作為開發所遵循的標準。



對建立執行架構的人來說，使用框架的設計可以將一些通用的執行必須功能包裝在裡頭；讓開發人員從必須從頭到尾瞭解執行原理，簡化為只要知道如何設定且實作交易之所需。在沒有使用框架的設計，開發人員必須自己弄懂底層後包裝為可用元件並測試之；使用框架可以簡化開發的工作，技術比較好的架構人員必須去瞭解框架的原理與細節，開發人員就根據架構人員所定義好的系統架構進行交易開發。如此一來開發人員所需的技術門檻將會大幅降低。



從上圖應可概略看出開發人員減少需要技術的困難部分，但相對地需要知道要如何去運用底層框架──不管是框架本來就提供的功能或是架構人員因應專案所作的設定。因此，架構人員除了去瞭解其他技術並運用之外，還應該提供足以讓開發人員活用系統架構的教學與說明，才能發揮團隊的戰力。曾看過有人將流行的技術組裝出一個執行平台後，僅教開發人員說怎麼做可以正常執行而不說明其他可能的變化，到最後變化出現時不是沒人可處理就是自己還得再回去調整。

只留下一堆設定檔與程式的話，除了少數條件好的開發人員外幾乎無力改變任何東西。有些架構人員會說當初他們也是自己慢慢摸索出來的，但在我看來其話中的含意是說“條件差的就不要浪費時間再看，條件好的就跟著在他們之前摔過的地方同樣再摔一次吧”。以這樣的心態建立系統架構的話，沒有辦法快速拉抬開發人員的經驗與實力，自己也會感覺他們怎麼這麼不中用。

註：通用的Class應依照先訂Interface再設計開發的方式，這裡不再詳述。目前偏重架構上的描述。軟體架構要設計到什麼程度？是某本書的第八章，8.2提到高來高去式架構設計的症狀還真是很貼近我的體驗。

X23 程式寫作員的未來(1)──起步的時候

某天下午，Ａ主管忽然感嘆說當SA、PM幾年下來已經開始不知道未來要怎麼走，真有點想要退休（註：他未滿35歲），同時也感嘆部門裡的PG不管是過得爽的或是被操累的都有人嚷著要離職，聽他這麼一說，還真有些很多職務都做不久的感觸。同樣是從programmer一路走過來的，如今試著思考從頭再來一遍的話自己會做些什麼事。

以一個常見的系統架構作為來推演：使用者希望在client的畫面上輸入資料後，經由server送到host執行，結果通過server回到slient後顯示在畫面並從印表機列印一張報表。下面是大概的硬體架構，暫且只將重心放在client-server-host間的執行，不去考慮存取database的機制。



瞭解的技術還不多的時候，面對這樣的需求心裡想的只會是如何達成。最直覺的設計就是在每一個單獨的硬體上各自執行一支程式來處理，硬體之間的資訊溝通再另外找一個好用的免費函式庫（像是Apache HttpConnection）來連接。這樣的做法肯定可以很快完成系統的需求，但是應該明白會造成類似C06提到的邏輯綑綁問題；而且沒有明確的規範時，有多少人開發就會有多少種風格的程式碼存在著。

還是初學者時如果想加快開發速度，就會避免學習很多現在不懂的技術，最有可能的寫法就是Client程式、Server程式都各用一個Class寫掉，再將一些常用的程式抽取成為API重覆使用。

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]陣列控制顯示顏色的技巧。
●利用關鍵字的設定，快速地製作或調整多個輸入欄位的設計方法。

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

X18 隨時檢查自己做的動作

某天開會，幾位同事各在白板上寫了一些字。有位同事忽然用羨慕的口吻對我說：“你的字寫的好整齊，而且每個字的大小都差不多；不像我寫的字，不僅大小不一而且還會越寫越往下。”我微笑著說，寫成這樣並沒有什麼，只要在幾個下筆的時機做一些檢查就可以辦到。

●寫第一個字時，決定所有字型的大小
●寫第二個（含）以後的字下第一筆時，要決定與前字的間隔與水平位置
●寫字的每個筆劃時，都要寫出與字型大小相符的筆劃
●寫第二行（含）以後的第一個字時，要決定與上一行的垂直間隔
●總之，寫每一筆前的瞬間都先做一次檢查並調整

同事心存疑惑地在白板上依照這些原則試寫十多個字後停下來看了看，滿意地說原來自己的字也可以寫得這麼整齊。我回答道：”是啊，每個人下筆前隨時檢核自己要做的動作，就可以擁有整齊的字。 ”

前幾天有人要我依影印稿幫忙在電腦上畫出一張建築物的平面簡圖，當時所有的電腦裡都沒有任何的繪圖軟體，我回答道：“就讓我這個小畫家之王（因為我不會別的）用小畫家來畫吧！”。下方的平面圖是半個小時之後的產出：


用小畫家畫略為嚴謹的圖時，我遵循著兩個原則：
●先計算比例尺，計算出一公分的長度等於圖上的多少點
●該直的絕對是直的，該圓的也絕對是圓的；橢圓則先量出長與寬的數值

畫每一個線條時，先決定起點、再決定方向、最後決定長度。隨時對每一條線做以上的檢查，自然能保證該線條的正確性；每一條線都在正確的位置上作正確的呈現時，整張圖表現出來的自然就會是正確的結果。

註：十多年前工作上急需印出一張軸承的規格（必須用autocad畫），當時只有一張手繪的底稿，而且會用autocad的人全都不在，我只好使用小畫家彷照autocad的表示法慢慢地畫出該軸承的三視圖。最後，對方接受了那張圖。

Y20 錦囊之計 vs 設計程度

話說古代有位軍師總會在出征前拿個錦囊給統率的將軍，要他在不知如何是好的狀況下照內容做，就能逢凶化吉或是出奇制勝。

在此處暫且將時空切割為二：甲時空的軍師通常在出征前一刻根據最新軍情花一點點時間寫錦囊，將領大多時候依錦囊行事倒也正確，但是總有一兩成的機率無法應付現況，需要派人再回去稟報軍情後重新跟軍師拿一個錦囊；乙時空的軍師都會在出征前一天思考整個晚上後，在錦囊中寫下各種可能發生的情況並逐一列舉不同的應對方法，據說不符機宜的機率降低到半成以下。

在這裡說的將軍是在客戶戰場中衝鋒的專案人員，軍師則是指公司裡製作共用元件（錦囊）的支援人員。如果你是軍師，會想用多少精力寫出什麼樣的錦囊？如果你是將軍，又會希望拿到手的是什麼樣的錦囊呢？

身邊絕大多數的人都屬於將軍型，能夠快速使用資源做出客戶想要的結果，遇到不符需求的變化時也能快速地應變；只有很少數的人在面對需求時會如同軍師般思考各種可能情況再作整理設計。將軍型看軍師型會感覺在設計同樣的功能時花較多的時間且產出額外用不到的方法，軍師型看將軍型的產出卻又感覺思慮不夠周延又難以捕捉改變後的影響。更頭痛的是，有些將軍在拿到後方送來的木牛流馬時會嫌錦囊寫的文件看不懂，而且擔心萬一故障時前線不能修理將影響軍情，乾脆重新打造一套很類似卻只有自己懂的東西才會有安全感。

將軍型與軍師型的角色，在雙方的定位清楚並且相互信任的前提下，是可以發揮很大功效的。公司製作共用元件時依照標準開發流程控制品質，提供面對不同狀況下的對應參數；專案人員信任共用元件與正確性與方便性，快速地依客戶需要組裝出該有的功能。這樣不就是很有效率的開發團隊嗎？

註：某個功能在遇到例外狀況，而且從模組內修正那個例外非常麻煩時，將軍型通常會在模組外部添加某些東西，並在模組內部最前端加上判斷添加物是否存在的條件另外處理。軍師型則會堅持分析模組內的處理流程，直到找出可以明確判斷出例外狀況且不影響其他狀況的正解為止；如果找不到這樣的解答，會認為那個模組是個失敗之作。

Y19 First Practice(4)──設計階段

最近很努力地直接開發工具程式，眼看著功能慢慢堆砌出來，也逐步給專案人員協助作測試與試用。

兩週後的某一天，主管問這次開發的工具程式能否在未來重用其中的部分？我愣了一下，由於撰寫中逐漸感覺系統有種“被綁死”的感覺，便回答說這個工具已經因為趕時間而寫壞，不可能切割出可重用的模組。以下就是我給主管的原因：

●沒有全面定義與使用介面
直接寫程式時，對物件常缺乏時間定義應有的行為。在需要對物件新增方法時，會感覺介面得多花時間去設定與調整，再加上認定系統就只會使用這種實作的物件，就順手地將方式寫在Class上。我們都很明白沒有使用Interface會讓物件間的耦合度很高……。



●取得物件的途徑不一致
上圖是工具程式的顯示畫面，最外面的MainFrame簡單地分為左右兩個Panel再各自盛裝UI元件。最外層的MainFrame設計為singleton，在設計時希望一邊Panel的UI物件可以存取到另一個Panel上的任一個UI物件來操作。例如左邊的Clear Data按鈕要能操作到右邊的Table以便做到清除的動作。但是程式寫到一半會發現並不是每個Button“都一致定義”擁有Panel物件，再加上趕時間而“懶得”調整，因此取法變為兩種（甚至更多）：

1) getLeftPanel().getMainFrame().getRightPanel().getTable();
2) MainFrame.getInstance().getRightPanel().getTable();


●物件操作的方式未統一
原本定義了ModelService來負責變更Model的工作，但有時“難免忘記”應該經由ModelService來做事而直接呼叫Model的修改方法，形成跳層的使用。如此一來，層次間的關聯變得複雜，而且沒法保證要做的事都會經過ModelService。

●忽略行為的封裝
需求裡提到使用者按下Clear Data時要清除右邊的Table，所以開發時直接在它的listener內直接寫下：

getLeftPanel().getMainFrame().getRightPanel().getTable().clearData();

後來發現工具列上也有個按鈕具有Clear Data的相同功能，所以也直接在這邊的listener裡寫上這一行程式。後來使用者在測試時回饋說清空Table的同時，Delete Data應該setEnable(false)，這時候就直接在兩個listener（最好是還記得有兩個地方）內多加一行而形成：

getLeftPanel().getMainFrame().getRightPanel().getTable().clearData();
getLeftPanel().getMainFrame().getRightPanel().getDeleteDataButton().setEnable(false);

在趕時間的前提下，當然沒空在Right Panel上定義clearTableData()同時封裝這兩個動作，因而繼續讓重覆的程式碼散落在各地。

基於以上的快速撰寫方式，雖然讓我的工具程式在被壓縮到不合理的時程後還能如期完成，卻同時造就出一個內部脈絡極為複雜、等於已經僵化的系統。在快速開發的同時無法“完全遵循”某些設計準則，就會付出類似的代價。

Y18 First Practice(3)──分析階段

在需求階段接近尾聲時應該要確定系統的架構才能進行分析階段。根據自己幾年來的經驗，預先定義好Package的架構：（當然不用最複雜的結構，那根本是累慘自己）



●UI+Listener
負責畫面的呈現與畫面操作事件的處理。Listener部分會將View與Model都放在Action裡，同時指向Controller做統一的處理。
●ActionService
生成Action並執行的機制，編輯工具需要的Undo/Redo功能也在這裡管理。
●Action
實作處理邏輯的地方。同時握有View與Model，可以讓處理流程完整地取得需要的資訊，同時任意控制每個地方應該發生的變化。
●ModelService
原本為了同時存取多個Model而包裝的服務，後來加上所有儲存Model內容的行為。一方面包裝複雜的Model行為，另一方面提供統一的Model修改處而不致散落在各個Model。
●Model
資料物件。除了ModelService之外只允許讀取內容。
●Environment
環境相關的靜態變數與使用者設定的各種參數。

整個系統內區分為三種層級的操作：Project、Transaction與Field，也就是說每個Package內都對應著這三個層級有不同的入口，在結構上就需要控制 6 * 3 = 18 個群組。根據這樣的佈置就可以開始對每一個UI元件的操作繪製對應的Sequence Diagram。

聽起來似乎蠻不錯的，但是很快產生了變化：原本還有六週的開發被壓縮到兩週，眼看要做的功能實在太多了，所以硬是多要一週變成三週的開發加測試，不過這也足以造成每天加班到半夜的事實。所以跳過了分析階段，直接進入了設計與實作。

Y17 First Practice(2)──需求階段

專案上說還不到使用工具的時機，估計起來在十二週的時間內有八週可以開發，因此堅持需求要經過完全確認後才進行分析與設計。檔案轉換工具主要有三項功能：匯入交易的電文規格、提供使用者編輯功能、匯出XML定義檔與空的Class（當然，使用者還希望能自動產生規格書）。

需求訪談並繪製成UML用了兩週，但也足夠讓自己發現以往的經驗值有許多與理論不合之處：

●從使用者角度看Use Case
記錄使用者需求時，一開始我記錄的是系統要做出的功能：像是新增交易檔案、編輯交易說明之類的，很快地就累積了上百個Use Case。Ｅ主管review時強調Use Case是描述客戶完成一件有意義的工作，並不是對應完成工作的分解動作（雖然對系統來說是完整的工作，但應放在Activity）；重新定義之後的Use Case剩下六個。


●幫Use Case說故事
Use Case的Activity Diagram要從使用者的角度來陳述做一件事的經過，強調的是使用者做了什麼以及與系統的互動。對系統的操作只需說明（對使用者來說）要做什麼事而不用描述操作的更細節部分。用swimlane分隔使用者與系統更能清楚表達二者的互動關係。


●Activity與Domain Object無關
這個工具輸入與輸出的詳細內容已經確定，所以我很早就開始繪製Data Model並將之連接到會操作到的Activity。後來發現這是提早設計的混淆，因為在分析階段時才會運用Boundry-Control-Entity的方式定義Domain Model、接著在設計時再定義為Data Model；在需求階段應該只先收集系統詞彙作CRC分析。

●UI的Prototype
在需求階段的末期應該與使用者討論資料的呈現內容與功能的操作方式，雖然Eclipse上有Visual Editor可以快速繪製UI，但是使用與調整還是需要不少時間。同事推薦一個網頁版的UI Prototype工具，能夠在極短的時間裡儘可能地表達出畫面的模樣；雖然與實際畫面有點落差，不過使用者接受度倒是挺高的。

Balsamiq Mockups：http://www.balsamiq.com/products/mockups

X17 對事 vs 對人(3)

前陣子公司有討論Web技術的會議，召集幾位曾經使用Web技術開發的專案成員相互分享開發經驗，討論的焦點大多在於執行速度、開發速度、學習曲線這些標題。

會議即將結束的時候，還沒有Web開發經驗的我提出：希望將公司現有的UI編輯工具儘可能地擴充到幾個Web技術的應用，可以將工具繪製的結果與設定輸出為指定技術的html、CSS與java script。話才說完，幾乎所有的人都反應說現有的Web開發技術programmer都很容易學會，編輯工具也到處都是，根本不應該再加上一層公司的工具增加他們的困擾……。

有一位同事最後發言認為這樣的工具是有必要的，因為對於不懂技術的使用者與SA來說是很有意義的。沒錯，這正是編輯工具存在的意義！編輯工具除了設定畫面的欄位與屬性之外，還可以根據已定好的系統框架與交易開發模式，將相關設定與參數同時定義在畫面編輯的清單裡，這樣就能夠彙集為所有SA可遵循的訪談範圍；在訪談之後再根據使用的Web技術匯出為特定樣式的html、CSS與java script，除了可讓programmer立即沿用產出繼續開發，同時保證自動的產出具有一致化的格式與寫法。

一句“要將現有Client-Server的編輯工具應用在Web技術的開發”這樣不含對象的事，雖然是我陳述時表達不完全的缺失，卻很意外地立即得知各人心裡形成的重點：有些人看到的是技術上實作的難度（因為那是自己要親手下去做的部分）、而有些人看到的是可以開發流程裡產生什麼樣的助益（縱使是對別人有用而不是對自己）。

註：上個月與一位資訊業前輩開會時，他曾說研發的重點在於工具的設計。因為工具的內容是根據系統架構與開發模式而定義的，妥善地應用工具可以規範好必須定義的範圍，同時得到一致的產出。現在感覺越來越能明白他的理念。

X16 對事 vs 對人(2)

幫幾位沒有資訊背景且還不瞭解公司產品的新進同事介紹時，刻意避開了技術細節，改由“人”的角度來說明系統，果然讓他們更清楚公司的產品對客戶帶來什麼樣的幫助。在說明的過程中，找到兩個因為看待角度不同而產生落差的實例：

公司產品裡有主管授權的功能，使用者在遇到某些特殊狀況時系統會將畫面轉到主管的電腦，待主管確認通行後才能繼續執行。在設計上，畫面轉給主管時螢幕會有一個按鈕（類似收件匣）閃爍以通知使用者；系統上線沒幾天，就有主管要求我們畫面轉過來時還要發出聲音，工程師卻覺得按鈕閃爍已夠明顯，根本不需要有聲音，認為客戶很煩。後來我們實際過去拜訪主管，才知道她有很長的時間都在處理書面作業，並不像我們幾乎整天都看著電腦螢幕，造成使用者必須大聲叫她才知道需要授權的困擾，於是就根據該主管的需要加上聲音的播放。

主管按下閃爍的按鈕（或是快捷鍵）後會出現轉來的畫面列表，根據摘要資訊選擇要授權的資料後再按Enter（或滑鼠雙擊該摘要）就會開啟使用者原始畫面並詢問是否核可，核可後回到清單再選擇下一筆。有位主管說她們授權時全部都是先授權第一筆，希望我們改為按下按鈕或快捷鍵後就直接帶出第一個畫面，核可後再自動帶出下一個畫面，若沒有下一個則直接回到工作頁面。工程師聽到又快瘋掉，直說明明功能全部都正常為何要用開授權時要少按一次按鍵來折磨他？當然經過觀察就會發現操作越精簡時使用者的負擔就會變少。

在專案裡，這樣的改變都會被歸類於需求變更，但是貼近使用者身邊觀察時卻會發現：如果我是使用者的話同樣需要這樣的改變。這時候該怎麼辦呢？堅持依照原有需求做出使用者不爽的系統，或是配合使用者需要來微調系統讓自己累癱？

想像一下，如果這兩個原先沒有想到的改變在需要調整時都能不影響設計架構而輕易變動，會不會是理想的結局？

X15 對事 vs 對人(1)

Wii居然也能這樣用的影片：http://www.youtube.com/watch?v=bAWd9hh45Y8

同事介紹了一個使用Wii偵測使用者的指向位置讓畫面互動程式的影片網址。原理其實很簡單，就是將使用者原本使用滑鼠輸入的行為擴展為直覺式的互動操作，但是我欣賞的是開發者能找到使用者的需要，巧妙地導入紅外線的偵測讓使用者與系統有更直覺的互動。如果焦點集中在“事”，就會覺得這只不過用簡單的原理連接幾個小設備而已；但是焦點如果在“人”，就會認同這個發現帶給使用者的便利，像是成本更低的電子白板與互動式的電腦遊戲等。

2010春晚表演影片1：http://www.youtube.com/watch/v/UpqAfo56DWg
2010春晚表演影片2：http://www.youtube.com/watch/v/RloiWZQ4-Xc
2009春晚表演影片：http://www.youtube.com/watch/v/4A0WAsCDMGw

忽然想到劉謙在2010大陸春晚表演的魔術，過沒幾天新聞就報導有人破解其中原理。這同樣是看各人將焦點放在哪裡吧？對“事”者，會去想辦法破解其中的訣竅來說服自己一切都是幻覺，對“人”者就會沉浸在表演的氛圍裡感受魔術創造者帶來的巧思。

像平時解答邏輯問題一般，自己以往曾熱衷於積極對一些事物找出合理解釋（或是不合理的破綻）；當焦點不對、思考範圍很少的時候，看到的就只是局部的優缺點而已。曾聽一位資訊業前輩描述說，資訊工程師對其他人的產出常有“文人相輕”的意味，相互用自己看法的優點攻擊對方看法裡10%的缺點，就是想要證明自己提出的比較好，對於應該解決的問題卻沒有幫助。

認為有能力者，真的應該嘗試讓周遭的人在某些方面得到進步才好。覺得紅外線設備偵測的原理沒什麼的話，想辦法串接一些原理創造出其他讓使用者更便利的設備；熱衷於破解魔術表演破綻的人，想辦法設計出更華麗且更看不出破綻的魔術取悅眾人；一直說別人的看法哪裡不好的工程師，用自己所知修補掉別人看法的破綻使其順利執行。

合理解釋、找到破綻、指出問題，對於需要那些方案的人來說完全沒有意義。對人們來說，能帶給他們便利的一切發現或發明，才是有意義的。

Y16 First Practice(1)──檔案轉換程式

月初時有個檔案轉換程式交給我來開發，系統功能是要能匯入主機電文XML後提供編輯功能，再根據公司的系統框架產出相關的設定檔。這對我來說並沒有什麼難度，但是主管就長期的影響來看希望應用RUP的方式開發，期限就從四週延長為八週。（記得看過沒設計與有設計的開發時程大約是1:3的說法，我應該要求十二週才對的）

雖然之前已經上過RUP的教學課程，也算熟悉UML工具的操作，但是真的動手要做出精確的產出時才發現自己對許多細節的觀念並不清楚。由於平時習慣將需求在腦中直接消化為程式碼，無論是需求階段、SA階段或是SD階段我都不時直接出現完整的class細節；當內容在不應該出現時冒出來，接著就會感覺到有窒礙難行處，這些不適當的內容都經由不斷地討論與調整加以修正。

慢慢領略到RUP的精神，同時也發現我們之前口中所說的專家理論其實是根據許多實作經驗後抽取的精髓。例如以一個Use Case來說，我們可以根據結果的描述直接寫出程式碼跑出符合的結果，但是專家們將之縱向切割為需求、分析、設計、實作等階段，每一階段都有自己的作法與產出傳遞到下一階段，同時在每一階段都平行考慮所有的Use Case一併考慮。只為一個Use Case寫程式碼的同時，時常擔心這些程式碼會不會因為下一個Use Case而有大變動，收集完全部需求後再作考慮不失為一個好方法。

在進行的同時，倒是有兩處令人頭痛的地方，希望在工作完成時能有新的領悟：
●記錄會用很多時間
　需求階段製作每個Use Case的Activity Diagram、每個Activity在分析階段要繪製Class Diagram、到設計階段要再調整，每一個步驟真的都需要很多時間。目前只有我一個人做。
●記錄追溯會用更多時間
　上一階段的一個Class到這個階段可能為了某個原因變成三個Class，這個變化必須填寫追溯表；某個Use Case分析設計使用到一些Class（的Method），要如何記錄這個使用關聯？反過來想，又要如何記錄某個Class（的Method）總共在哪些Use Case內被使用呢？

Y15 功能強大的音樂軟體──Max 5

有位同事感嘆說現在做電子音樂的人用的工具比我們寫程式的還要元件化，音色、節奏、和絃、鼓聲等等都可以使用類似製作流程圖的方式，拖拉元件到畫面上後定義參數與順序就可立即聽到音樂。同事在他電腦上示範編輯的方式，也試著從網路上下載別人做好的音樂流程直接播放出來，播放時甚至可以設定一些特別定義等待input event才發出聲音。

Max 5這套軟體看起來真的對音樂製作有很有的幫助，而且是完全免費的。不用懷疑，軟體真的是完全免費的，因為要收費的是可以連接實際音樂設備的元件，使用外接型的元件能夠驅動真實的設備使之按照設計流程發出定義的音樂（這是同事說的）。同事說他還付費報名了外面的Max 5課程來學習。

看過之後我們有了短暫的討論，好奇於為什麼能將某個領域的軟體做成這樣，反而自己沒有這樣功能強大的編輯工具可以使用？（討論時也提到範圍較小的LEGO Mindstorm作比較）初步有了以下的共識，但也發現這些因素會讓寫程式的行為變得複雜：

●必須完全清楚該領域要做的事，才有辦法定義出被使用者選用元件的完整集合。
　如果做功能時只是找出一條可以執行的路，肯定沒法收集到完整的集合。然而，程式碼裡會做的事太多了，如何收集得齊全？
●每個元件都要定義可以傳入的參數，以及傳回的值。
　在寫API時常感覺參數總是少一個（傳物件的話需要使用較複雜的編輯器操作），傳回的除了值還有可能是各種Exception，在流程控制上有很大的變化。
●每一個元件幾乎都獨立到與前一個元件無關
　音樂要動聽雖然有些規則，但是每一個音符的發生都是獨立事件；LEGO的行為也類似（譬如起重機的繩子一定要先放下才能升起，但是怎麼放下去的並不會影響升起的動作）。寫程式很麻煩的是還要讓後面的元件使用前面處理後留下的資料。

X14 做工作 vs 做學問

在職場工作一陣子後，都會發現湧過來的工作有如長江之浪一波接一波而來，有時甚至是好幾個浪一起打過來。除了要迅速完成各個交付項目之外，還要學習將每個交付項目切分為許多小階段，藉由多工處理各個小階段來讓每個交付項目都同時有完成的進度。

工作時滿腦子想的都是怎麼完成交付項目。我很同意聰明人（王文華）這篇文章裡所說的，“聰明人喜歡給解決方案，因為他們第二個特徵是凡事講求效率。”，快速地定義做到什麼程度叫做完成、同時定義出達到完成的最短途徑。例如前陣子在客戶端有個我負責的程式在換版本時發生問題，我希望在更新作法前與同事討論好各種可能的因應再換版，有人說直接放上去跑馬上就知道哪裡發生問題再繼續改，但是我顧慮客戶看著我們程式一直換來換去會有負面想法而堅持要先討論好。

用“效率”來看檢視程式碼檢查範本這件事，最適當的作法莫過於全部條件先打開後再根據眾人的意見調整，馬上可以開始用且很快就會有修正的回饋；這是強調建立初步雛型讓使用者體驗再改進的作法。不過在與理論型的Ｅ主管討論時，他認為規則範本定義的是標準，應該用最嚴謹的方式定義：也就是每一條規則都要明白後再決定要用或是不用！否則一個標準定義出去還修修改改的，會令人感覺很不舒服。

做學問就會像是Ｅ主管所說的那樣，面對一個交付項目就得找出與它相關的一切關聯並仔細地研究內容，同時註明參考與引用的出處，全部都弄明白後再根據數據來分析歸納出客觀的結論。在工作上一方面因為時間就是金錢，另一方面因為客戶要求的標準就只有那樣，所以很自然地就先找出最短的捷徑交出去，再視實際進行的狀況補上缺漏的部分；在經驗不足或考慮不周時，就常會發生被客戶指正的現象。

能把工作做到像做學問那樣通盤瞭解算是遙不可及的夢想吧？在快速提供解決方案的同時，我們還應該明白單憑個人的想法總是會有缺漏的地方，在溝通與討論中運用團隊的智慧補齊原先設想的不足，儘可能一次就交出設想完備的作法會是減少多次修正與增加客戶信賴的正途。

Z08 程式碼撰寫原則與檢查規則範本

程式碼的寫法就有如作文的風格一般，如果沒有規定就會有編排迥異的結果，因此出現coding standard的建議寫法，期望有比較一致的程式寫法（Sun的coding convention網址：http://java.sun.com/docs/codeconv/）。

工作團隊在數年前引用這個建議，搭配Eclipse的自動格式化功能，如今大家都很習慣規定的寫作風格而不致相差太多。然而建議只是建議，以往僅能在看到不合規定的寫法時告知往後要調整，專案裡繁多的程式碼中有多少沒遵循寫作風格的狀況根本沒人看得到，這正是為什麼要引進檢查軟體的原因；另外基於某些特定寫法在邏輯或效能上可能有潛在問題，也希望藉由類似軟體從所有程式碼裡自動找出來。

選用Checkstyle、PMD、Findbugs這三個檢查軟體在使用上分為幾個等級：
●安裝、設定、執行
　這是使用的最基本要求，所幸這三個軟體都很容易達成。
●勾選
　每個軟體都有各自的檢查規則，檢查時會根據規則勾選與否來過濾條件。有預設的檢查規則。
●自訂
　更進階的用法，可以根據規則的撰寫方法定義特殊的檢查規則。

在討論檢查規則勾選與否的課題下，本來想直接引用預設範本或是全部打開看哪些不適用再關掉，但是考量到定義應該嚴謹，因此決定逐條審閱是否適用。檢視規則時的想法定位於“在撰寫規則提到的狀況時，是否完全不應該寫成那樣”，上週用了很多時間將Checkstyle（128條）、PMD（247條）與Findbugs（369條）的所有檢查規則共744條說明全部看過一遍，最後定義出屬於自己的檢查規則範本。

這麼多的規則看完之後，雖然只能記得大概的內容，但是對它們的認知已不再只是“可以檢查寫作風格，同時可以檢查出一些問題”，而是”精確地知道哪些可以檢查、哪些不行”。另外對於一件事情的執行與落實，產生些許的不同想法。

Z07 Root(1)──最根本的的Interface

●ObjectInterface

我的程式碼處理工具將只針對自己定義的寫作規格處理，這是因為所有人的程式寫作風格都不相同，遇到一對多的定義時工具完全無法作任何判斷。最快區分程式碼是否符合規定格式的作法，就是定義一個介面來判斷。另外，在[M09]與[M10]定義過所有物件最基本的行為：生成與消滅，這兩個方法就是放在這個最根本的Interface。

在我的程式世界裡，將會有事與物兩大類。物件不會直接繼承或實作ObjectInterface，而會根據它是事或物的特性來繼承ProcessObjectInterface或是DataObjectInterface：

●ProcessObjectInterface

對於事的定義多了兩個狀態：開始處理與停止處理，也就是把[T13]裡的initial()與dispose()狀態拉到這裡成為startProcess()與stopProcess()。如此一來，所有屬於事的物件就擁有生成、開始處理、結束處理與消滅四個基本行為，這是根據一個機制要開始做事與停止做事所定義出來的時間點。

util套件內的所有程式都會實作這個介面。

●DataObjectInterface

可以盛裝值是物的特性，每一個物應該提供的共通行為是setValue()、getValue()與removeValue()。對於所有的物而言，最單純的物就是只放置一個value。

這個介面未來會延伸到基本Data Model再擴充使用。

Y14 設計想法彙總(4)──事時物者為俊傑

[W02]裡的人、事、時、地、物五個元素，其中人與地偏向於能否運行的條件的定義，真正達成功能的要素還是在“於特定的時間點發生指定的事以影響對應的物”，因而古有明言：事、時、物者，為俊傑。（這……真是夠冷）

程式的執行的最終結果是為了操作資料，部分的人會將設計重心放在資料的存取，而我認同是事的處理過程才去影響到物，所以將設計的重心放在如何以人性的思考來鋪陳事的經過以及事如何去操作物，還有如何將事掛到對應的觸發時間點上。我們時常聽到“堅持做對的事”，這句話其實很適合運用在設計事的處理過程，再加上“所有的物只被事所影響”的限制，“堅持做對的事，同時讓影響的物合乎規範”就形成我最根本的設計理念。再多思考一下會發現，事隱含有處理流程（Flow）與分解動作（Action）二種元素，Action是真正做事的行為，Flow則是組合Action達成目標的完整經過，將兩者明確地分離對於動態置換有相當大的助益。

在程式設計領域裡有很多人提供非常有用的想法與工具（譬如最近亂翻過的新書──編程創藝：編寫出卓越的程式碼就寫得相當好），但是實在不希望程式設計永遠是那種不同人寫的不同、同一個人不同時間寫的也不同的那種混亂。我的目標是想擺脫“趕快用程式碼堆砌出功能就對了”這種思維的產出，而從順應事物運行的自然流動作為出發點來設計。事（Flow、Action）與物（Model）是元件結構裡的三個重要部分，希望只需要簡短的說明就能讓大部分的人寫出相同規格的程式碼。

要去布置妥程式碼會花較多時間，絕對沒有人會接受多花時間只能得到相同運行結果的，現今有些作法有令人頭痛的關聯追溯與文件問題，推論起來有機會在我的理念中全部自動產生；目前唯有讓自動產生內容節省的時間大於（大很多）布置程式碼時多用的時間才會有誘因。

科學的字義是：以一定對象為研究範圍，依據實驗與邏輯推理，求得統一、確實的客觀規律和真理。精確地100%維持每一個程式指令全部在對的位置做著對的事是極其困難的，需要團隊中每一位成員的堅持。暫且放下類似“人性不可能做到100%”的負面想法，試著思考“怎麼調整可以達成那個理想？”、“做到後是否真的帶來那些好處？”，積極地相信未來的願景才有可能在現下勉勵自己達成各項要求一步步的前進……。

註：努力的方向（[Q09]、[Q10]、[Q11]、[Q12]、[Q13]、[Q14]、[Q15]、[Q16]、[Q17]與[Q18]）記錄的是我想做的。

Y13 設計想法彙總(3)──唯一的資料物件

在執行的過程中模組與元件都各自操作自己的資料物件，在設計時會根據不同的需要定義存取方法，不過我想做的是在各自的資料物件包裝內全部使用一種實作──基本Data Model。

基本Data Model向下可以使用不同的Parser對應各多種儲存檔案：目前實作過XML、properties、text、CSV、excel，計畫再對應html、ResultSet、Model（使用XML字串描述而生成定義的物件種類）以符合更多樣化的運用；Parser應該提供這幾個基本功能：讀檔、存檔、傳入字串與傳出字串。再者就是能夠以對應基本Data Model的單一編輯器達到通用的目的。



向上則可以被繼承後依照個別的需要定義存取方法，宣告為元件結構裡的Model、Properties與Exception。另外，為了區分每種資訊被存取的差別，會要求必須擁有獨自的getter與setter，不得使用通用型的方法。

在執行期間只要更換Properties的內容（或是重新設置），就能夠改變元件內部的行為；不同模組或元件之間的資料傳遞也只需要取得基本Data Model字串再直接傳到另一處而變得簡單。如果需要當時資料物件的全部內容，經由Parser可以轉換為各種不同格式的字串寫在log裡，事後可輕易地回復為該時間點的執行資料進行測試。

在公司曾實作過一版最早版本，幾位用過的同事都覺得方便且容易操作，自己也滿意這樣的設計結果。雖然基本型態的欄位資料都必須使用String型態存放，但是在不甚計較容量與速度的執行環境下卻也沒有什麼缺陷。

與基本Data Model想法有關的文章是：[C22]、[E06]、[E07]、[E08]、[E09]、[E10]、[E11]與[E12]。

Y12 設計想法彙總(2)──遞迴的一致結構

規畫好放置框架後，接下來思考的是：現在每個模組與元件都只有近似的結構與寫法，有沒有可能定義出“完全一致”的適用規格？如果定義得出來，就可以把程式碼視為一種格式化的文字檔，撰寫很多工具程式來自動處理這些檔案內容。

根據這個目標，我認為需要的就是一致的元件結構與元件間的遞迴式呼叫。

元件結構的一致性，在[D06]、[D07]、[D08]、[D09]與[D11]有詳細提到切割的六個部分：
●Implementation
　管理元件內部的小型工廠與使用窗口。元件生成後，內部Flow與Action的生成與置換都由它處理；另外每一個介面方法必定要通過這裡的管理。（整個元件的生成應由元件生產工廠模組來統一管理）
●Flow
　元件內部處理流程統一放置的類別。應依照SOP的想法定義每一個方法的實作流程，在不同應用的需求下允許使用者動態改變流程類別。
●Aciton
　操作流程分解動作統一放置的類別。流程依照SOP的想法定義，流程中的每一個步驟都定義在這裡，在不同應用的需求下允許使用者動態改變動作類別。
●Model
　定義元件專用的資料類別。每一個屬性都要同時提供getter與setter。
●Properties
　定義預設生成的Flow與Action，以及其他執行期間需要調整的參數。由Implementation讀入並保留使用。
●Exception
　每個元件要有自己的例外。介面方法內部發生無法預期或難以處理的情況時，拋出內含相關資訊的例外物件。



完美地保持只呼叫下一層的遞迴型態，代表著需要嚴謹地定義每個套件的使用關聯，並補齊每一個層次原本沒有定義的元件空隙；只要有一個例外，就會造成處理程式的邏輯判斷錯誤。當然，也必須讓處理程式知道每個層次的定義與存取位置。自動產生設計文件的記錄在[P06]、[P07]、[P08]、[P09]與[P13]。

當元件結構的一致性與從上而下的遞迴規則定義好之後，可將足以得到很多現在難以自動產生分析、統計、追溯……以及各種想像得到的程式內容應用。

Y11 設計想法彙總(1)──層次與使用定義

這陣子會去思索至今為止我想做出來的設計到底是什麼？能否整理清楚並明確地傳達給別人？是否有足夠的理由與好處去說服周邊的人承受較多的不便去遵循？這些都盤踞在我的心裡。

首先是關於層次的設定，像下圖中這樣Business Module、Module、Component、Utility從上到下佈置下來的方式，雖然安排的層次上或多或少有所不同，但是由上到下的使用關係都是大家所習慣的作法。這裡我想要討論的是：需要開發電子日誌商業模組時決定要使用外面開發的DB存取元件，應該直接從電子日誌模組使用？或是定義一個自有的DB存取元件使用，電子日誌模組只呼叫它呢？（如果只看功能，程式怎麼布置都可以達成）



最快的方式是在電子日誌模組裡直接使用外部的DB存取元件，這意味著模組與外部元件有不可分的相依性，所幸這個問題在遇到第二種資料庫時就會因為想要抽換實作層而自己布置一個Component來負責。再接著會遇到一些通用機制需要設計（像是roll back、SQL command管理等），那些是所有使用DB的商業模組必須應用的，但是若想放在功能性強的Component又會感覺綁手綁腳的。



從上方往下看是這張圖中像洋蔥的結構，Use Case劇本呼叫的是Business Module的方法，再一層層地向內使用，外部元件全部由Component包在其內部使用，在其他任何層次都不會接觸到。在這種結構下，與外部的接觸點只限於Component層（Utility也可能會使用到外部Class），可以避免在任何模組或元件都能使用外部元件。

一致的層次設定與使用規則，是最開始就需要定義好的布置框架。

X13 簡單幽默之範例(1)──蚊子

以下內容一字未改，均為當時打字的記錄。

[同事]　蚊子是令人髮指的生物
Joying　蚊子.....正是夜晚穿梭我們"髮"際, 死於我們"指"間的......
[同事]　是半夜咬我們的害蟲
Joying　我家最近也很多
Joying　常常半夜起來, 臉上都一陣酥麻......
[同事]　感覺天氣回溫 害蟲就多了
[同事]　我每天半夜都被蚊子叮醒 睡眠不足
Joying　唉......
Joying　我看, 我們去買一個以往罩在餐桌上防蒼蠅的那種罩子
Joying　調整一下, 睡覺時罩在臉上吧
[同事]　去
[同事]　買蚊帳還差不多
Joying　嘿, 你想出好解法了 :)
[同事]　我昨天睡前 用電聞香薰過房間了 還是沒用
Joying　不然本想再建議西洋劍的面罩....
[同事]　你先試試好了
Joying　我曾幻想過
Joying　有沒有辦法睡覺時把捕蚊燈佈置在頭的周圍.....
Joying　像是把燈泡拿掉, 換成頭在裡面
Joying　這樣蚊子一過來就會先被電
[同事]　這...
Joying　不過, 所有人都認為, 頭會先被電焦　
[同事]　應該會
[同事]　翻身時就身亡了
Joying　好可惜, 那是最棒的解法說, 但有技術瓶頸沒法克服 :(
[同事]　最棒的解法應該適用蚊帳比較好吧
Joying　也有蚊帳裡飛進蚊子的bug啊
[同事]　而且就算蚊子飛到蚊帳裡 範圍也比較小 一下子就抓到了
Joying　呣....只好先選用這囉
[同事]　我個人是不愛蚊帳
Joying　也還有另一個方式喔.....只要讓房間比外面冷, 蚊子自然會待在外頭 (自然驅蚊法)
[同事]　這點我想過 很難　
[同事]　除非開冷氣
Joying　會被當瘋子吧 =.=
Joying　牆角放幾塊大冰塊還比較可行
[同事]　那才會被當瘋子
Joying　至少外人不知道啊.....開冷氣, 全街都知道你瘋了.....
[同事]　切

Z06 工作計畫(1)──第一階段（root）

依據腦海裡的最終目標，先切分可以逐步實現的小目標，再先根據各個功能的相依性定義出root專案應該要達成的工作項目：

●所有程式必須實作的Interface
原先只定義ObjectInterface，為了區分根本的事與物而再衍伸了ProcessObjectInterface、DataObjectInterface。兩者都繼承自ObjectInterface，處理資料的程式實作前者，放置資料（尤其是各種DataModel）實作後者。

●基本物件與工具程式套件
先布置一個util套件來放置所有純粹處理各類資料用（內部不放置任何資料的那種）的程式，像是StringUtil、ArrayUtil……等；另外還有object套件來放置與資料相關的程式，像是ListMap、StringTokennizerNew……等。

●定義Component的規格
這裡會定義Component的最初型態，目前定義了兩種：第一種是標準Component，會有Impl、Flow、Action、Properties、Data與Exception六個部分，主要目的是可以任意更換Flow或Action或Data；另一種是簡單Component，不會有Impl，Flow與Action合併於一支程式（方法需加annotation識別），Data可定義於外面也可藏於內部。

●基本Log元件記錄是追蹤與分析，因此log元件是第一個要製作的元件。這裡要做出的是可以記錄的機制，透過同一組介面讓記錄可以依設定選擇要記錄在console或者是檔案。

●基本Data Model + Parser
第一個要做的元件，因為未來所有模組與元件唯一繼承使用的資料物件。支援檔案種類暫時規畫有XML、Properties、Text、CSV、Excel這幾個原有的，在後面的階段會延伸到Java File解析的系列。

Z05 版權宣告與註解範本的內容

撰寫程式碼除了code本身之外，每一支程式都必須要有的部分就是版權宣告與程式碼註解。每支程式最前端都會有我自己的版權宣告段落：

/*******************************************************************************
* Copyright (c) 2010 Joying Lee
*
* All rights reserved.
* This program is free to use, but the ban on selling behavior.
* Modify the program must keep all the original text description,
* and can only comment out the original code (not allowed to delete).
*
* 保留所有權利。
* 本程式可任意使用，但是禁止販售行為。
* 修改程式時必須保留所有原有文字說明，而且只能註解掉原來的程式碼 (不允許刪除)。
*
* My Blog : http://ooadreason.blogspot.com
*******************************************************************************/

註解的定義根據[V01]的描述，區分為Class、Field與Method三種；註解的本體目前定義有摘要、描述與使用三個部分，再往下則是@開頭的Java Doc常用標籤。整理為出一份自己要使用的關係對照表如下圖，接著遵循這些註解規則建立Eclipse內的Code Template並匯出XML作為往後使用的標準。



最後定義程式中描述處理過程的註解與變更時與Trac ticket相關的標記註解如下：

/* 這是描述處理過程的註解，必須獨立存在一行 */
// 這是與Trac ticket相關的標記註解，必須在程式碼那行的最後面

註：在以下範例程式的三個註解位置，似乎各自代表不同的意義。我的解讀是：
註解Ａ－描述if那個指令的判斷說明。
註解Ｂ－描述if成立後那個block的說明。
註解Ｃ－描述return那行的說明。
/* 註解A */
if (isTrue()) /* 註解B */ {
　　/* 註解C */
　　return;
}
若依照我的註解準則與未來模組化的目的，應該變成可讀性略差的這樣：
/* 註解A */
if (isTrue())
/* 註解B */
{
　　/* 註解C */
　　return;
}

參考網址：http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

Z04 工欲善其事，必先利其器

新的年度開始，也該是進入新階段的時候。俗話說的好：工欲善其事，必先利其器，這句話的意思是說只要讓別人看到自己在準備工具，就會以為你要開始做事。咦？解釋的角度不對？總之，不管要不要做事，先把工具弄好就對了。

前陣子研讀Java Power Tool的經驗，剛好可以移植需要的部分到自己的開發環境。先列出必須要在Windows環境下安裝的應用程式：

●StarUML 5.0　下載網址：http://staruml.sourceforge.net/en/download.php
　Rational Rose不是每個人都有，還是使用免費軟體比較適合；這是我覺得比較適用的。
●JDK 6 Update 18　下載網址：http://java.sun.com/javase/downloads/widget/jdk6.jsp
　使用Java SE就能符合近期的需要。
●Eclipse 3.5.1　下載網址：http://www.eclipse.org/downloads/
　下載Java EE的版本。本來考慮用Modeling版本來畫UML，但是現在設計與開發還沒有很好的串接；也考慮使用可以開發plugin的Standard版本，這等到需要開發plugin工具時再說吧。
●VisualSVN 1.7.7　下載網址：http://www.visualsvn.com/visualsvn/download/
　Windows環境下很方便使用的SVN Server，安裝後可立即開始使用。暫時還不會用到版本控管，不過還是一起安裝。

以下是我在Eclipse裡安裝的plugin（在Eclipse上安裝plugin的方法請上網搜尋）：

●Subversive 0.7.8　安裝網址：http://download.eclipse.org/technology/subversive/0.7/update-site/
　版本控管的Client端。暫時還不會用到。
●Subversive Connector　選擇SVN Kit 3.0後會自動開始安裝。
●M2Eclipse 3.0.0　安裝網址：http://m2eclipse.sonatype.org/update/
　管理Maven專案的工具，除了plugin設定configuration還不能用之外是很方便的工具。在我的環境裡不打算安裝library server，直接上global repository同步。
●Java Doc：內建。
●Checkstyle 5.0.3　安裝網址：http://eclipse-cs.sf.net/update/
●PMD 3.2.6　安裝網址：http://pmd.sf.net/eclipse
●Findbugs 1.3.9　安裝網址：http://findbugs.cs.umd.edu/eclipse/
　以上三項是協助檢查程式碼是否符合一些常用規則的工具軟體。
●jUnit 4：內建。
●Eclemma 1.4.3　安裝網址：http://update.eclemma.org/
　檢查Unit Test涵蓋度的工具軟體。