從OOAD中領略人生的常理

[X] 網誌的最近變更

2010-12-31T23:59:00.012+08:00

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

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

[投影片進度]
已經製作單元－ 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 熱水器瓦斯氣爆的親身體驗

2010-12-04T01:44:00.005+08:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2010-06-30T00:00:00.001+08:00

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

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

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

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

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

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

2010-06-28T00:00:00.004+08:00

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

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

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

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

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

2010-06-25T00:00:00.002+08:00

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

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

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

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

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

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

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

2010-06-21T00:00:00.002+08:00

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

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

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

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

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

2010-06-17T00:00:00.003+08:00

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

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

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

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

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

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

2010-06-14T00:00:00.001+08:00

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

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

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

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

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

2010-06-11T00:00:00.001+08:00

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

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

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

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

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

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

2010-06-06T00:00:00.001+08:00

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

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

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

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

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

2010-06-03T00:00:00.004+08:00

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

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

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

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

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

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

2010-06-01T00:00:00.003+08:00

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

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

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

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

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

2010-05-21T00:58:00.002+08:00

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

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

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

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

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

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

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

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

2010-05-10T00:00:00.005+08:00

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

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

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

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

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

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

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

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

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

2010-05-07T01:15:00.003+08:00

新的公司標到某個縣市政府便民資訊系統建置的合約，其中包含一套公司內沒人會做的語音傳真系統，因此雇用我在五個月內無中生有地完成那一套語音傳真系統。在當年寫作風格還只是包裝常用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)──第一份工作

2010-05-03T00:30:00.002+08:00

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

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

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

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

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

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

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

X18 隨時檢查自己做的動作

2010-04-29T00:00:00.009+08:00

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

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

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

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

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

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

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

Y20 錦囊之計 vs 設計程度

2010-04-20T12:19:00.000+08:00

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

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

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

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

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

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

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

2010-04-16T01:43:00.002+08:00

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

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

●沒有全面定義與使用介面
直接寫程式時，對物件常缺乏時間定義應有的行為。在需要對物件新增方法時，會感覺介面得多花時間去設定與調整，再加上認定系統就只會使用這種實作的物件，就順手地將方式寫在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)──分析階段

2010-03-31T23:59:00.002+08:00

在需求階段接近尾聲時應該要確定系統的架構才能進行分析階段。根據自己幾年來的經驗，預先定義好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)──需求階段

2010-03-25T00:56:00.002+08:00

專案上說還不到使用工具的時機，估計起來在十二週的時間內有八週可以開發，因此堅持需求要經過完全確認後才進行分析與設計。檔案轉換工具主要有三項功能：匯入交易的電文規格、提供使用者編輯功能、匯出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)

2010-03-15T01:36:00.001+08:00

前陣子公司有討論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)

2010-03-12T17:53:00.002+08:00

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

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

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

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

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

X15 對事 vs 對人(1)

2010-03-02T15:37:00.003+08:00

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)──檔案轉換程式

2010-02-21T02:32:00.000+08:00

月初時有個檔案轉換程式交給我來開發，系統功能是要能匯入主機電文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

2010-02-06T00:00:00.002+08:00

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

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

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

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

X14 做工作 vs 做學問

2010-02-04T00:00:00.001+08:00

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

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

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

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

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

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

2010-02-01T00:58:00.004+08:00

程式碼的寫法就有如作文的風格一般，如果沒有規定就會有編排迥異的結果，因此出現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

2010-01-26T00:00:00.005+08:00

●ObjectInterface

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

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

●ProcessObjectInterface

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

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

●DataObjectInterface

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

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

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

2010-01-23T00:00:00.002+08:00

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

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

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

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

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

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

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

2010-01-22T00:00:00.006+08:00

在執行的過程中模組與元件都各自操作自己的資料物件，在設計時會根據不同的需要定義存取方法，不過我想做的是在各自的資料物件包裝內全部使用一種實作──基本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)──遞迴的一致結構

2010-01-21T00:00:00.000+08:00

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

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

元件結構的一致性，在[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)──層次與使用定義

2010-01-20T00:00:00.003+08:00

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

首先是關於層次的設定，像下圖中這樣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)──蚊子

2010-01-19T14:50:00.004+08:00

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

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

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

2010-01-18T00:00:00.002+08:00

依據腦海裡的最終目標，先切分可以逐步實現的小目標，再先根據各個功能的相依性定義出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 版權宣告與註解範本的內容

2010-01-16T00:03:00.002+08:00

撰寫程式碼除了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 工欲善其事，必先利其器

2010-01-14T23:14:00.008+08:00

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

前陣子研讀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涵蓋度的工具軟體。

Y10 用物來描述事，用事來成就物

2009-12-29T01:22:00.005+08:00

Ant、Maven這兩個好用工具的廣受歡迎，有人點出是它們能夠利用檔案設定方式將專案進行中的瑣碎行為定義標準，在需要進行那件事的時候任何人只要執行它就可以得到完全一樣的結果。這種方式與將每個時間點要作的事記錄成SOP要求遵照進行比較，除了必須先行瞭解新的工具用法之外，帶來的卻是便利與穩定等強大好處。

當事情可以用人或電腦來處理時，不同人、不同時間的同樣操作都有較高的錯誤與不一致機率，這些問題在利用電腦處理時可以大幅降低，只需要花一次時間精確地定義出處理的詳細規則；觀察許多工具其原始目的大致如此。Ant對於單一事件（通常是build版本）定義出詳細的處理過程，而Maven更進一步地定義出專案管理中的幾個階段，再整合其他工具、加上與程式碼相關的物件（library、testing、reporting……等），建構起一個能夠調校的自動管理系統。

收集軟體專案開發必須要做的事，定義出每個軟體專案能通用的開發流程、階段與當時可以做的事，同時允許使用者設定使用一般常用的方便工具，得到適用的客製化結果。當工具符合專案大部分的自動化需求時，即使需要額外投入學習的時間還是會加以運用。

回到自己部落格的內容，現在記錄的資料只是根據過去的零碎的經驗值推想一些改進的方法，沒有全面的整理與比較根本說不出這麼做的最終目的。此時的思緒已經逐漸清楚，明白自己是想定義用程式碼製作出來的全部事與物都有完全一致的型式與規則。如果像專案開發階段這樣令人感覺抽象且發散的事都能夠依賴設定之物來運作，試圖將程式碼轉化為某種特別的設定來驅動更豐富的自動化解析也應該是可以達成的。

這，正是我想逐步實現的理想。

X12 精確地拆解、完全地對應(4)──記錄的內容

2009-12-24T00:10:00.003+08:00

從寫計畫書時的拆解目標到記錄安裝手冊的步驟，最近感覺慢慢地開始喜歡撰寫文件。主要因為發現無論是目標的拆解或是一堆軟體的安裝，都是將許許多多的物與關聯運用平鋪直敍的方式來記錄；套用將人視為電腦的觀念，就像在制訂匯出的規範（決定匯出的順序與內容），讓匯出的資訊進到任何一個人都可以還原前人腦中的想法。

●第一個考慮的是全部的範圍。根據需要安裝的軟體、需要的環境設定、專案的參數定義與需要完成的特定事件來思考並加以歸類；未來每一個項目都要製作對應文件說明。在這裡可以想像是Use Case的定義與群組化，再加上循序漸進地順序佈置以建構閱讀者對整個平台的瞭解。

●對於每一個說明點的內容，意義上與用文字敍述的功能劇本差不了多少。準備的檔案與起始狀態、每一個步驟的忠實記錄並佐以圖檔、每一步驟後的狀態檢查、還有最後完成的狀態與驗證，都是需要記載於文件的內容。其中若有小目的需要用多個步驟才能完成，應加以群組起來說明較為清楚（很像是寫程式時將多行群組為一個方法）。

●有時會需要兩層式的文件才能說明一件事。例如建置一個Maven專案的流程要在Eclipse上新建Maven專案、設定subversion儲存庫再share project，倘使流程文件直接記錄每個步驟，就會發生其他流程要使用設定subversion儲存庫這個步驟的說明時，不知是要參照其中的步驟(只參考流程的一部分)還是自己建立新的說明（重覆的資料）好。我的解法是每個步驟都拆到對應軟體的操作手冊裡，再從流程內容參照過去；整個流程需要輸入的資料則記錄在流程文件裡，畢竟那是該流程特有的內容。

在移交開發平台的過程中，曾經為了兩個沒有記錄到的小步驟，用了一個工作天才感覺似乎少了些什麼，一天之後才確認真的有缺少。記錄兩個小步驟只是幾分鐘的時間，但是可以省下不應花費的一天；用這個例子提醒自己撰寫文件的價值與影響，自然會時常懷著戒慎恐懼的心態力求完整。

X11 精確地拆解、完全地對應(3)──經驗的留存

2009-12-15T13:08:00.002+08:00

先讓別人明白為什麼要做這些事之後，接著要讓別人知道為什麼會有那些物。將焦點放在搭配工具的那一欄：所有使用工具的聯集就是開發平台上應該安裝的全部。開發平台會分為Client端與Server端，專案起始的環境建置應同時準備好這些。前面提到的安裝文件就是描述整個平台從無到有的建置過程。

從使用者的觀點來看，並不需要知道開發平台是怎麼樣被建置起來的，只要提供一個能讓他們根據規定流程做事的東西即可。然而從管理面來看，如果設定需要調整要怎麼做？如果某個工具損壞了要怎麼安裝？如果某些工具有升級版要怎麼做？……用許多可能會發生的”如果”來檢視沒有完整說明的產出，就會發現根本不知從哪裡著手。

最近看了一些不錯的文章都有提到知識管理的重要性（高績效研發管理實務運作／李紹榮、研發人員常見問題之剖析與探討／吳英秦），這幾年我也體認到經驗的保存是很重要的事。為了特定目的如何定義需要的物、做哪些事可以得到那些物、怎麼設定能讓那些物具備功能、怎麼使用那些物可以達到我們要的目的，每一個想法與實現都忠實地記錄並收集起來，就能讓原先沒有參與的人很快地建構起與自己相近的觀念與成果。

這個開發平台現在連我在內一共有三個人完整安裝過，但是每個人都花了不少時間去詢問與搜索，像我就在網路設定上花費一整天才弄妥。做出一個完整的開發平台需要做很多的動作才能達成，我偶而會想：倘使幾個月後需要三個人根據自己手邊的記錄重灌一次的話，我們各自會花多少時間？如果各自找一位其他的工程師看著留下的資料重做的話，又需要多久？會問多少個問題呢？

有些道路是經過多次的摸索與碰壁後才發現到的最佳捷徑，沒法留下快速通往終點的記錄只會讓日後想走同樣路的人重覆花費摸索與碰壁的時間，如果那條路需要多人次的進行時更是重覆地浪費資源。留下足以讓後人快速達到終點的作法，可說是犧牲自己時間換取節省眾人時間的一種高尚行為──這是近來瀏覽其他人在網路上提供安裝設定方式與心得時，我心中所懷的敬意。

X10 精確地拆解、完全地對應(2)──目標的解析

2009-12-14T00:13:00.003+08:00

認為現有的文件寫得不理想時，總得說出比較理想的寫法才算是建設性的意見。依據前面同事留下來的資料重新安裝Java Power Tool中提到的工具時，一邊問他們當初沒有記錄下來的部分、一邊思索要用什麼樣的方式表達才能讓其他人全面地明瞭所做的一切，並且可以製作出同樣的結果。

今年撰寫的那份計畫書其實也是沒人想寫的那種，不過在構思的期間與大主管們有過多次的討論，學習開始去切割目標為多個小目標，再對每個小目標定義要做些什麼、要怎麼做等等的想法。我們認同程式碼品質這個無法直接度量的目標，可以用程式員日常工作的規範來間接證明，所以先列出程式員所有“與程式碼相關“的行為，根據每個程式員的行為定義相關的動作，再思考每個動作是否有適當的工具搭配以及操作的必要規範。

註：這只是大致上的示意圖，還不是完整的定義與對應。

這張圖是根據“程式碼品質”這個目標延展出來的四個群組：專案事件、程式員做的事、搭配工具與定義的規範，其間的每個項目都與緊鄰群組中的項目產生關聯。以往討論程式碼品質時都僅能就幾個點提出建議，但是參考Java Power Tool的內容卻可以就完整的面來探討：從專案與程式員個人事件發生的起點開始展開處理的流程與要做的動作，並針對每個動作找出最適合的工具來加快處理速度並減少錯誤，一步步使用規定的工具做完應做的事同時讓所有產出都通過檢查且符合規範。

針對一個較大的目標，完整地定義出點、線、面來全面涵括相關的事物，不是更容易規範出大多數人都能接受的標準嗎？

X09 精確地拆解、完全地對應(1)──遇到的現象

2009-12-11T10:15:00.002+08:00

公司前陣子陸續驗收了幾個專案，主管利用可喘息的空檔重新思考如何確保程式碼的品質。品質，無法直接以數據衡量其好壞，因而參考Java Power Tools這本書中的工具與作法，同時決定沿用同事已經先行研究一陣子的產出再擴展下去。

同事的作法是使用虛擬機器安裝Ubuntu作業系統後加上需要的應用程式，雖然他同樣參考過那本書，但僅是在虛擬機器上裝好書上提到的軟體。我們拿到虛擬機器映像檔時真的是有點愣住，因為根本不知道軟體安裝的順序、方法與設定（他的說法是使用者只要有能用的東西就好，不用管怎麼安裝的），也不知道Programmer日常工作要在什麼時機、用什麼樣的方式來運用各個軟體（他有說了大概，但是沒有確實的工作流程）。

那時我還在別的專案忙著，主管先找了其他同事來幫忙弄清楚虛擬機器上的每個環節，同時希望他們能定義每個工具使用時的規範（例如Subversion在commit時說明的範本），當時也言明在完成後會由我根據產出的文件從頭到尾重做一次來檢驗結果。但是這幾天自己下去重頭做時才發現記錄的內容感覺很不齊全，很多地方不知道從哪裡開始、不確定要做些什麼、不知道做了之後改變了什麼。

工程師（指我遇到過的以及我自己）撰寫使用手冊與教學文件的產出普遍不理想，主要原因是對於撰寫這些文件的態度為“把自己完全清楚的東西全部寫一遍，只是浪費做其他事情的時間而已”，於是就以自己的角度思考寫出能回憶到的部分。在很多時候就因撰寫者與使用者的程度與觀念落差造成無效的文件。

Y09 關於共用核心元件（Core Component Library）

2009-11-19T01:46:00.001+08:00

在因緣際會之下參加了經濟部標準檢驗局舉辦的Core Component Library（簡稱UN/CCL）座談會，才知道聯合國UNCEFACT已經提供一套方法，針對企業間電子商務行為關係將彼此的交易流程以共同同意之方式、順序及訊息格式進行整合。其範圍涵蓋了各行各業非常多的商業資訊物件，在最近的09A版本已經定義了五千多種。

UN/CCL主要的目的在於各國、各系統間的資料交換，翻閱過08A的中譯資料發現已經定義了許多曾經使用過的資料。席間有人發問說資訊物件內的欄位並沒有定義長度，學者回答資料若定義長度在語系轉換時會發生長度計算的問題，不過我認為資料在使用的意義上並沒有長度的規範，而是系統設計時因應儲存限制才加以規定的。

然而UN/CCL只是該組織計畫一部分，資料的定義用ebXML來描述，Business Process與Information Model會有UMM方法論，相對地這也是範圍更大、更難定義的部分。根據簡報的陳述，倘使各國的菁英最後能夠定義出絕大部分的商業流程與其對應使用的商業資訊物件，未來的電子商務相關系統開發模式很可能是：

●定義使用系統的所有Actor
●定義每個Actor所使用的Business Use Case（從清單中勾選）
●定義每個Business Use Case裡所需要的Business Process（從清單中勾選）
●定義Business Use Case裡的Business Process執行順序
●定義Business Process對應的CCL資料物件中的使用資料欄位（從清單中勾選）
●底層的架構會根據勾選的資料物件欄位產出ebXML傳送到另一端的系統

這個組織已經運作好幾年，但是以“Core Component Library”搜尋中文網頁時所得的資訊並不多。從另一個方面來看，自己定義的“人－事－物”關係能夠接近許多專家定義的“Actor－Business Process－Core Bomponent Library”精神時，總是對自我更多了幾分認同。

官方公佈UN/CCL版本的網址是 http://www.unece.org/cefact/codesfortrade/unccl/CCL_index.htm。

X08 批評學生不敬業的事件

2009-11-10T18:10:00.007+08:00

原始網頁：http://parenting.cw.com.tw/web/docDetail.do?docId=1844
學生回應：http://www.udn.com/2009/11/10/NEWS/OPINION/X1/5242253.shtml

聯合新聞網上刊登了這個事件，洪蘭小姐在訪視台大醫學院時對學生們上課表現出來的態度不以為然，在天下雜誌發表「不想讀，就讓給別人吧」一文，對此事件，台大醫學系系學會會長在新聞網的專題裡回應了一篇文章說明。我當然不懂學醫的人求學時會發生什麼事，不過我對每個人在不同情境下的思考邏輯很有興趣，所以順便探索一下。

洪蘭小姐的立場很簡單，她認為在求學時期應該對所有學校相關的事（包括與求學無關的）都應抱持負責的態度，更何況那是上課時間；學生的回應也很簡單，表面上承認態度的確有所不當，不過那些都是因為有更正當的理由才會造成那些現象的發生，如果在專業方面能有所表現的話應能體諒其他不拘小節的行為。

在許多人的觀念裡資訊人員是不拘小節的族群，以往的我就是落在這個集合裡，認為只要我能夠完成公司交付的所有任務就算是達成工作目標，平時上班穿著牛仔褲、涼鞋也不以為意。十年前應徵現在的工作被錄取時，詢問上班應該如何穿著，那時的Ｊ主管說：“你希望別人怎麼看你就怎麼穿”。從那天起，我每天都穿著長袖襯衫、西裝褲與皮鞋，因為我認同穿著可以反應出一個人的內心。我們在開會因為都帶著電腦，有時總會分心做些與當時會議無關的事，Ｊ主管有次生氣地說：“我放下手邊的工作專心地與各位開會，如果大家沒法付出與我相等的專心，我現在就離開“，自此之後我也不曾在會議上別其他事情。

我沒法認同學生的辯詞，因為我體認到在不同的情境下人都應該做該情境下應做的事，每個情境都是獨立存在的，不該拿其他情境的影響來解釋現在的錯誤。上課是學生與老師的互動，老師全心講課時，下面的學生付出了多少？相對地學生想來認真聽課時，敷衍的老師同樣對不起學生。上課會打瞌睡只是證明睡眠真的不夠，如果睡得夠的話看到看過的電影會拿起別的書來看；上課會吃便當只是證明不想犧牲吃的享受，如果時間真的不夠會寧願買個飯糰在休息時間隨便吃吃也不會想在課堂上分心。

在上課的態度不佳是事實，沒去承諾去努力改善這個現象，卻試圖用所有學生的“全”讓那些學生成為“偏”、用專業課程為重的“全”讓通識課程成為不重要的“偏”。一個小故事裡的壽司師傅在捏了上千個壽司後已經累了，仍同樣專心地製作壽司給關門前最後一位不重要的客人吃，旁邊的師傅說你已經很累了不如隨便應付一下，他正色道：“這個壽司只是我今天所做的千分之一，但對這位客人來說卻是他的全部。如果隨便做做，客人就會認為我做的壽司就是這麼爛！”

在想要合理解釋自己有問題的行為前，是否思考過洪蘭小姐所訪視的那一堂課就是她所看到的全部呢？

註：在電子工廠上班的朋友說，每批產品都會抽檢一定比例的樣品，只要其中一個有任何一個錯誤就會將整批產品重新作測試。每個人都可以決定要用什麼樣的標準來檢視自己！

Z03 振聾發聵的文章──別把專家當笨蛋(3)

2009-10-30T00:00:00.006+08:00

小朋友有天說出他被學校的同學在部落格上攻擊，我們發現對方的文章裡盡是刻薄的字眼。把小朋友叫來詳細詢問事情經過，他起初描述是因為小事有誤會造成的，但是根據小朋友的習性抽絲剝繭後才發現他的行為也不恰當。與老師溝通時，我們傾向於說小朋友目前還是學習階段都難免有錯，請老師教導他們對錯觀念再修正即可；不過老師透露當初看到那些文章時，倒很擔心雙方的家長會在學校鬧出風波。

有些人完全不想學UML，但是在認定UML無用的同時卻無法做出大多數人看得懂的文件；很明顯地這是因為心裡沒將製作文件視為自己該做的事，因而不想要任何對應的處理工具。各類的文件在系統開發階段中一直要求得具備，倘使心裡認定撰寫文件是浪費自己的時間，自然不會在意文件對於其他人與日後自己的影響。要讓一個人願意學UML必須要先讓他認定撰寫文件是必須做的，要能接受撰寫文件是必要的得瞭解文件在各個開發階段的應用，要是心裡打一開始就認定開發方法論無效，就跟之前的我一樣什麼都不用再談了。

“主觀”是個殺傷力很強的念頭，可以將小朋友間的爭執鬧到上法院，可以讓自己變成別人眼中的老頑固，也可以將旁人的心血說得一文不值。同樣是一個人，為什麼從小到大的立場會如此轉變？為什麼會從天真瀾漫變為結黨營私？為什麼在互動頻繁的人類社會裡能夠變得自我中心？不是心理專長的我當然沒有答案，不過我至少發現了一把可以改變自己想法的鑰匙。

人們總是習慣從自己的角度看待事物，唯有學習從不同人的角度重新審視原先熟稔的事物，才有機會突破自己預先設下的侷限，重新顯現出不同的格局。將自己放低後，其他人的經驗與知識自然開始源源不絕地流入，收集眾多的資源後就比較容易分析比較各項優劣。我已經相信這個道理並且開始實行，至於你相不相信？都是你個人的選擇。

Z02 振聾發聵的文章──別把專家當笨蛋(2)

2009-10-29T00:00:00.003+08:00

小時候遇到各種新的或不同的事物，總會很有興趣地去學、去瞭解，甚至還會提出一些新奇的想法來嘗試；沒想到這樣的熱忱於長大後卻大多演變為“我不需要”或“看起來沒用”的回應。小朋友前幾天對我說：“為什麼要學勾股定理？根本用不到嘛！”當時我心頭一震，彷彿看到在學校與工作時抵抗著其他知識的自己。我回答說：“學一些知識是讓自己擁有這個能力，未來要從事更高深的科學研究時就有機會用到；當然也有可能用不到，但是需要的時候沒有就是你自己的痛苦。”

同樣地，專家提供根據他們領域知識的精華，根據專家整理過的資訊能夠快速地提升自己的水平；要從一份整理資料裡去蕪存菁地擷取有用的經驗，還是要因為一些蕪而廢棄菁地整個丟棄都是自己的選擇。以往對一件事物習慣去看旁人對它的評論就吸收為自己的看法，藉此來決定是要接受還是抵抗，如今學會反問自己：“我完全瞭解它的意義嗎？能明確說出它的全部優缺點嗎？”，想要有明確而完整的答案，就非得親自去體會不可。

之前與年紀較大的同仁打交道時，總感覺他們的想法非常固執、極難溝通，現在的自己慢慢地朝高齡化發展，卻漸漸發現排斥其他想法與知識的行為與他們類似。似乎具有一種心態，認為某些事自己已經擁有很多的經驗值，如果別人隨隨便便提出幾句話就改變自己，會是很沒有面子的事，所以面對可能的改變時不是消極地掩耳盜鈴當作不知道，就是想出許多藉口來說服自己新的想法並沒有現在心裡面的好。

回憶自己的過去，故步自封的確是因為自己太有自信去控制一切，也就是過於輕視眼前的領域，不想接受其他不同的思維所造成。學歷可以無用，像在大學時我根本蹺課到等於沒去上課，現在的工作目標照樣可以用自己的方式達成；但是要能有良好的做事方法與產出內容，如今相信真的需要先參考專家們的經驗，再調校為適合自己實行的模式才會有機會更上一層樓。

Z01 振聾發聵的文章──別把專家當笨蛋(1)

2009-10-28T00:00:00.002+08:00

原始網頁：http://www.ithome.com.tw/itadm/article.php?c=57685

是否曾經有過這樣的經驗？有一個東西在身邊已經存在很久卻一直沒有什麼感覺，等到某天的一個場合再看到它或是某件與它相關的東西，心裡頭各式各樣的想法就不自禁地流動起來，翻騰到最後定型下來卻是另外一個層次的感動。我提到的那個東西並不是女友或妻子（雖然很像是），而是Ｅ主管堆在我桌上的一疊書，這篇文章就是引發我不同觀念的催化劑。

Sun的OO-226課程是我接觸OOAD的最初，開始時隱隱覺得這是很不錯的設計作法，但是實際應用在開發時卻有很多無法串連起來的缺漏；累積幾年的經驗後試著以其為藍本，再自行定義一些捷徑作法將所有的點連成線再到面而形成現在的想法。雖然有自信可以合理地做出一些不同的東西來，但是那畢竟只是“用自己的經驗湊出符合既定目標”的產物。

RUP一直是有名的開發方法論，不過很多人的評價都說它過於笨重並不適合實用。在與Ｅ主管討論方法論（他傾向用RUP）時我常搬出這類的評價來抵抗，他總會說：“你瞭解RUP的全部作法與其精神嗎？你說得出哪裡有問題？哪些作法適用？哪些作法不適用嗎？”當時我認為這僅是強辯時的說詞而堅持己見，每次的討論也常不了了之。然而我現在已經在閱讀RUP的全部正式文件，因為現在終於明白應該從一個穩固的基礎為起點再用自己的經驗來調校它，並不是自己創建一個全新的作法。

完整的開發方法論是一大群人耗費心血所完成的，定義出所有階段、所有角色、所有行為與所有的產出，相信那都是每個人的多年經驗與思索研究的精華，是一個人在一、二十年的經驗所無法相比的。專家的產出是將其自身經驗輸出為系統化、組織化的作法，進而建構起環環相扣的關聯，在某些細節上或許的作法或許不盡理想，卻也不應因噎廢食而全盤否定。

X07 規畫書撰寫實務課程的收獲

2009-10-26T17:06:00.001+08:00

公司打算開一門規畫書撰寫實務的課程，對象主要是業務與市場規劃的同仁。原本不在上課名單內，但是想起上回撰寫規畫書的慘痛教訓後著實希望自己具有這方面的基本能力，因此商請主管在上課的當天硬是向人事部門報名。

課程為十二小時，在授課的中途看著講師整理的投影片對應到之前的問題點時，才發現計畫書的編排除了把內容寫出來之外，是有目標、有架構、有不同角度與不同寫法的，同樣的內容必須根據不同的因素組合來調校。看得出講師在投影片的整理上花費了相當大的心血。休息時間與其他同事閒聊時，他們說雖然教材內容經過整理，但是提出的一些目標與原則感覺根本做不到，譬如說計畫書的內容要寫到能感動人心就太過理想。

認真觀察投影片的結構，慢慢領悟到：對一個難以直接達成的目標，可以拆解為數個可以分開完成的項目，每個項目有自己的作法、輸入與產出。概念就像是下面的圖所表示：

自行推想的思考原則如下：
●每個目標拆解出來的項目必須互斥。（項目拆解子項目時亦同）
●每個目標拆解出來的項目組合起來必須剛好等於目標。（項目拆解子項目時亦同）
●每個作法的輸出必須剛好符合項目的要求。
●每個作法內要有規定的執行步驟
●每個作法使用規定的輸入後，能夠產生規定的產出。

用簡單的一句話表示，會是“精確地拆解，完全地對應”，將目標分割為可以獨立完成的項目，每個項目全部完成後代表目標達成，輔以輸出項目的檢驗標準用以度量目標與項目的進度與品質。觀察自己身邊的許多事若能用這樣的原則處理，相信就會習慣用文件來記錄想法的拆解內容。

註：講師在投影片中根據經驗定義了評審審查的數個重點，根據每個重點建議一些適合的作法。如果定義的審查重點在邏輯上等同於那個目標，那麼針對各個重點的加強就能提升其效果，更有機會達到“打到人心”的目標。

Y08 不要只用技術的角度想事情(3)

2009-10-18T00:00:00.001+08:00

業務人員是最貼近客戶的，在拜訪客戶的同時蒐集客戶目前欠缺與可改善的資訊，回報給公司的市場規劃人員作整體性的計畫；以技術人員的立場來說，一直以來都認為這是最有機會瞭解客戶需要的管道。不過，得到的資訊與真實的差距到底有多遠？我在最近才開始體認到其中可能的誤差。

不管是SOA或是服務體驗，初接觸客戶服務時我都直覺地認為不過是“從客戶的角度來想事情”，然而在很多的時候我們只是“把自己視為客戶”來討論；即使直接對客戶訪談或作問卷調查，取得的資訊通常只是片面的資訊，因為得到的答案是經過思考（可能帶有修正）才輸出的。

德國的服務工程與美國顧客體驗洞察技術提倡的是使用科學化、系統化的方法，將客戶的真實行為模組化為數種Model再進行服務設計。剛開始時實在不以為然，甚至萌生不知道為什麼要學習這種東西的負面想法；隨著漸漸瞭解服務的本意，才慢慢明白要用什麼樣的立場與方式去思考客戶的事。現在與技術人員開會（我當然還算是技術人員啦）時，時常會感覺他們看事情的立場有很大的差異，才猛然省悟原來自己以前也是這樣！

從完全不懂到能初窺其奧妙經過至少四個月，心態上也從抗拒轉變接受並嘗試；回首歷程，能不能聽懂是第一個關卡，想不想接受是第二個關卡，會不會去做是第三個關卡。倘使不去嘗試、不去吸收、不去思考、不去改變，是永遠不可能走出現有模式的。

事情常有一體兩面，以往自己獲知一件事時最先想到的都是找出其問題點並提出難以施行的障礙，現在則會先考慮可以順利執行的狀況然後想出困難點再思考克服的方式。從負面指出哪裡有問題的確是技術人員（與政治人物）會最先想到的，我覺得這才是想事情角度不對的最大癥結吧？

Y07 不要只用技術的角度想事情(2)

2009-10-16T00:00:00.002+08:00

與不同的同事們聊天時，才發現每個人的設計想法差異很大，最常見的設計想法是將執行交易種類次數報表與記錄模組全部都綁在一個模組裡，然後套用“只作出客戶需要的東西”這個說法。如此一來，這個模組的存在最差的情況下只符合這一個報表，而且記錄的資料元素很可能因沒妥善思考而不足，根本沒法應付未來的各種可能。

不去想其他可能而只注重單一功能，進行速度當然可以很快。但是在未來有需要修改記錄的資料元素才能產生的報表時，就需要改動最底層的模組，連帶地影響其他原本可以正常運作的報表；為了隔絕對舊有系統的影響，唯有copy-paste出另外一套來修改。這樣就產生了號稱絕不疊床架屋的設計──只是同樣的東西有很多套而已。

交易記錄模組是需要良好的設計來提供最大範圍的支援，報表部份則從底層模組取得資料只作客戶所需要的就好。底層的模組用最大化的可能設計來應付未來需求的改變，實際的呈現則只實作客戶提出的部分即可；雖然客戶想要的可能會增加，但是多送他不需要的東西也絕對不會收的。

觀察主管的感覺，發現他們通常會先定出做事目標，然後會陳述做事的順序與原則，但是對於每個步驟所需要用到的資源與可能的困難點幾乎都不涉獵，通常變成很理想化的想法。實際做事的人需要顧及每個步驟的可行性、風險與替代方案，這些都不是只談原則就能夠順利推動，而是需要精確地衡量與思考才有可能做好的。

在主管的想法與實際施行有衝突時，實在有股衝動想跑去主管面前大聲疾呼：可不可以拜託你們從技術的角度來想事情！

Y06 不要只用技術的角度想事情(1)

2009-10-14T00:00:00.001+08:00

從程式員的角色成長後，慢慢會接觸到業務與主管等非技術的角色，有時在討論對事物的看法時，他們總會冒出一句：“不要只從技術的角度想事情”。任何事物當然都有不同的切入角度與思考觀點，其他人說這句話時多少都否定說自己提供的僅是片面的想法。然而，只用技術的角度來想事情就表示有缺漏嗎？

在開會時思考系統可以加強的地方時，我想到之前很需要但是沒辦法產生的一份報表（註：不能描述太詳細，就暫時以執行交易種類的次數報表稱之），連帶地想到產生該報表時需要配合記錄Log的各個時間點，並想這個想法整合為一個Log記錄模組的概念。後來將這個概念私下陳述給Ｅ主管聽時，他回答說：不要只用技術的角度想事情，不要習慣從bottom-up思考而應該是top-down。意思是說概念要思考能符合客戶的需求且賣得出去才算是成熟的概念。

當時我的腦中忽然發出像是什麼斷掉的聲音，立即有了否定的回答。

現在我需要一份現有系統無法產生的報表，便開始思考要怎麼做才可以滿足自己的需求；發現報表所需要的資料可以從增加特定時間點的Log來取得後，就認為應該有一個專門負責記錄Log的模組來收集各種資料。這個模組概念的產生是由我自己（客戶）需要的報表（需求）所引導出來的，完全符合由上到下、根據使用者需求而出現的想法。

目前其他客戶想要什麼樣的報表我們都不可能知道，即使今天訪談了十個客戶所收集到的報表種類，在找到第十一個客戶時還是有可能要之前沒提過的報表；就算我們想從客戶的角度來思考，也不能肯定思考出來的範圍是不是百分之百。在無法肯定未來變化的現在，我只能以現有模組的角度來定義其中的資料元素（譬如人、事、時、地、物），期望在設計的同時可以有最大範圍的排列組合，而未來客戶想要的報表儘可能地落在設計的範圍裡。

用最小的額外花費涵蓋最大範圍的可能需求，不就是設計的目的嗎？我這麼反問Ｅ主管，他沒有反駁。

Y05 都只是為了完成功能……

2009-10-10T00:00:00.000+08:00

對程式設計人員來說，被要求的結果就是要寫出能達成需求的程式碼，而最尋常的情況就是遵循最簡單的道理：產出一堆可以完成功能的程式碼交差。暫且不管程式碼對於功能是否有多餘的設計、也不管程式流程控管的處理是否完善（這些是程式碼與功能的內容對應），光是“程式碼為可見之物”這個事實就會衍生出一些管理的事。

就像作文一樣，看到題目之後心裡就要先有文章的架構鋪陳；功能明確之後同樣會有執行的順序。如同作文時的擬定大綱，設計程式也需要概略描述達成功能的過程。作文的大綱完成後要開始逐段、逐句、逐字寫出文章，程式碼的產出也是如此；其中的差別在於作文強調的是從頭到尾、一氣呵成的感覺，寫程式除了這個感覺之後還有逐步的例外處理。

寫出程式後需要經過測試來精確地保證功能可被達成，測出錯誤會使得程式碼有再次的修改，每次修改都會有版本的記錄；每個版本各修改了哪些地方，造成什麼影響都必須要能迅速查詢到。怎麼佈置、怎麼撰寫、如何保證與如何管理，是因為有程式碼的存在所連帶產生的四件事情，標準化的做事會有方法與準則，這意味著還要定義出至少四組的做事方法與做事準則。倘使做這些事的過程裡需要有其他的物（工具）協助時，還會再衍生更多的事……。

只是為了達成一個功能，在產生程式碼的過程需要考慮很多其他的事，可以想見如果沒有全面性地看待而只注重在如何完成功能，就會造成除了執行正確之外的全部都有潛在的問題。雖說完成功能是最終目標，然而考慮程式時常被修改的特性後應同時注重其他方面的要求。

X06 建立小朋友的能力架構

2009-10-06T17:11:00.002+08:00

在小朋友的成長過程裡，父母總會希望他們具備各種能力以應付日後社會上的各種競爭。有些父母會以“多才多藝”作為小朋友的學習目標，但是學習項目過多會使得小朋友們失去童年的時間，因此我的想法在於建立他們的能力架構。能力架構倘使可以適當地建立起來，日後可以根據個人的興趣喜好選擇適合自己的項目，再經由這個能力架構達到更快速的學習與產出。

能力架構的想法類似於電腦的架構，在最底層的需求有輸入、記憶、搜尋、運算與輸出五種能力。每種能力根據自己的認知定義應該要學習的技能。

●輸入：單位時間內傳入的資料量越多就有機會攝取更多的知識，速讀可以提升傳入資訊的速率。速讀的訓練可以從國小低、中年級開始。
●記憶：傳入的資料需要被記憶下來才能在日後再度使用，速記可以提高傳入資訊被記憶下來的比率。坊間的速記課程也包含了速讀，同樣從國小低、中年級開始。
●搜尋：根據現在的情境到腦中的龐大記憶裡搜尋各式各樣符合的資訊運用，我不知道學習什麼技能才能提升這項能力。或許，這是倚賴天份的？
●運算：年輕時跟算術有關的運算都會佔據考試很多時間，學習珠心算將運算時間降到最低，自然有充分的時間驗算並思考其他更有意義的問題。從剛學會筆寫阿拉伯數字的中班年紀開始。
●輸出：思考的結果會經由肢體創造出一些產出，其中很大的部分會是文字，現在電腦的使用佔了很大的比例，因此打字可以提升輸出文字的速率。從認字與注音都稍具基礎的國小中年級開始。

在這五項基本能力之上，我認為還有三個概念性的能力需要加強：

●輸入準則：閱讀能力有助於拆解文字（或圖形）成為腦中可記憶的儲存想法，拆解得越多越可以看懂更多其他人所想要表達的想法。
●輸出準則：作文能力有助於將腦中儲存的想法用文字（或圖形）組織為別人可以看懂的內容，想法描寫得越詳實越有助於讓旁人的腦中建構出與自己相彷的想法。
●規劃能力：利用棋牌類必須規劃佈局同時推算對手各種對策的規則特性，養成每一步進行都先思考各種可能的習慣；同時等待對手回應也能夠培養等待的耐心。

建立起基本的架構能力後，其他需要輸入、記憶、運算與輸入的技能都能有事半功倍的效果，同時運用輸入準則、輸出準則與規劃等概念性的能力還能夠再加強這些架構能力處理資訊的品質。這樣的道理與架構的設計不是很接近嗎？

Y04 POC的產出不適合直接使用

2009-09-30T00:00:00.001+08:00

有些專案在競標之前會先製作POC（Prototype of Concept），等到專案開始後會有人直接拿POC裡的產出放到真正執行的環境裡。理由當然是說這個功能在POC已經做出來而且可以執行，只要再加上相關環節後就能擴充到足以驗收的程度。

這當然是從“可以驗收”的角度來看待POC的產出，但是深入一層去想，POC這個名稱已經很清楚地說是“概念的雛型”，目的在於驗證想法是否可被實現。在架構已經選定的前提下，自己在製作POC時思考的是：
●什麼時間點需要執行這個功能（入口）
●執行這個功能時需要哪些步驟（流程）
●每一個步驟各需要什麼元件來支援（動作）

決定執行的時間點後可以導向入口，在專案裡掛上功能的入口很簡單，但是需要調整傳入與傳出的資料。流程是功能進行的順序，在POC時幾乎都只製作正常的流程與幾個需要呈現的錯誤，要在專案實用就得加上所有的錯誤控制。動作方面大多會使用到其他元件提供的功能來組成自己的分解動作，倘若是第三方提供的元件使用的方式會比較固定，但要是使用元件預定是在專案內才設計的就會有被變動影響的風險。

達成目標經過的每一步以及收送的資料內容都需要經過設計，這些並不是在製作為了測試概念能否執行的POC時會考慮到的，僅求一時之快將POC的內容直接引用，未來勢必會出現設計想法不同的落差。能夠只作些小修改就融入專案設計算是最好的，但是大多數的情況還是需要打掉重做才能符合專案需要。

曾經在專案後期被POC改寫的元件卡著上下不得：想作些專案需要的修改時覺得綁手綁腳，想重做又會浪費重新測試的資源。捨棄POC所寫的功能而僅參考執行概念再重新設計出新的元件，是我決定的作法。

X05 積極主動的態度

2009-09-28T00:00:00.000+08:00

在前面的例子裡，為了同步同一階層人員的想法建立的同步機制，相當於建立了一個“物”；而一個新“物”的產生所增加的“事”，至少需要讓不同角色的人知道怎麼使用，還有維持其運作的管理與維護。使用關係到個人怎麼操作，是每個人都必定要會的，但是管理與維護的工作卻不是明確屬於任一個人的。

在一個團隊裡要做的事非常多，明確屬於個人的責任就是自己所該做的，另外還有許多是沒法歸屬責任或是多人共同用到的。觀察人們面對那些公共事項時的反應是很有趣的，當然大多數人的心態是多一事不如少一事，拼命地閃躲或是推卸責任讓別人來負責。從個人的角度來看，會有這樣的反應是很正常的。

將視野提升到專案來看，當人們都自掃門前雪時就表示著那些事可能落在不適任的人身上，或者是被敷衍地完成，進而造成做出的結果並不符合眾人真正的期待；倘若很不幸地這些公共建設沒有做好時嚴重影響到日後每個人的工作方式與效率，就會造成深遠的影響。對於管理者來說，看著成員們動不動就說“那不是我負責的”或“我不知道”時，也會有深深的無力感吧。

在專案裡客戶會打電話過來問些問題，若詢問的對象不在，接電話的人通常會說那是誰負責的，然後就幫忙留話。這樣做當然沒有錯，假如態度積極一些，直接問清楚要問的問題後再問負責的人細節後再回覆客戶，對專案來說代表著反應機制的迅速，對個人來說可以多知道一件事情。具有如此積極態度的團隊，無論士氣或是效率都會提升很多的。

X04 同步的速度與內容是團隊戰力的關鍵

2009-09-23T10:19:00.001+08:00

用這張圖簡單地描繪專案裡的人員階層與關聯，從人員間的關係可以看出訊息的傳遞普遍存在於每個人，同樣一個訊息需要根據不同的對象各自傳送一次。今天領導者A解決某個重要問題時剛好成員B不在身邊，他就將原因與解法對成員A與成員C說明，這個時候就造成成員B根本不知道發生過這件事。

將事件與對應的處理讓其他人知道的最佳解決方式是留下記錄。如果有個機制記錄每一天發生的事情與對應處理，那麼成員B回來後只要查詢一下就能知道那件事；如果有個機制記錄特定事情的歷史軌跡，那麼任何一個人都可以交待那件事的來龍去脈；如果有個機制記錄事情的類型，那麼可以延伸查詢相同類型的事件都哪些……。

記錄的類型與管理方式會造成不同的效果。電子郵件、文件、程式、錯誤回報系統都可能會有事件的記錄，假如保存與歸類的機制都沒有定義，所有的記錄就形同一盤散沙般無法整合。我們不應從記錄的角度來看待說只要在相關的地方註明清楚即可，而應該從事件的角度來看如何從一件特定的事件找到所有相關的一切，像是處理方式、前因後果、改變與影響等等的資訊，如此才能全面性地來看待該事件。

這正是我重視知識管理系統的原因，因為它提供的是記錄內容的整合。一個歸類後的題目，可以在類型與事件中交互查詢，也能深入一個問題內找出所有的關聯、追查所有的產出，更重要的是累積下來的資訊都可以在任何時候給任何人作為處理事件的標準參考教材。（當然，資訊的關聯都是由人所建立的，唯有全部成員都有正確的觀念後才有可能施行這個想法）

可以試著想像在需要某些資訊時，不知道放在哪裡、不知道是否完整、不知道為什麼要這樣做、不知道做了有什麼影響這些狀況都會影響一個人的認知與反應。從需要者的角度建立好他們需要的資訊是一種只需建立一次卻有永久影響的花費，資訊在成員間同步的速度與內容將會決定該團隊的戰力強弱──因為團隊的能力強弱並不是看最強的有多強，而是看最弱的有多弱！

X03 定義出正確的客戶並找出全部的需要

2009-09-21T00:00:00.000+08:00

已知有一個重要的功能即將交給自己開發，這個時候在心裡盤算的是些什麼呢？大多技術人員都知道需要定義出功能清單作為開發的基準，功能清單應由提出需求的人認可才算數。但是若承接的功能是屬於底層架構的功能，未來會有許多專案人員根據這個功能來開發許多程式，這個時候心裡應該盤算什麼呢？

優先考慮的當然是誰來驗收這個功能？從句意來看很明顯地有兩類客戶：
●使用者：需要這個功能可以正常執行的人。
●專案人員：基於這個功能來開發其他程式的人。

做出可正常執行的功能給使用者驗收是一定要的，因為你的東西一定要先能用才有可能收得到錢。但是專案人員是使用自己產出的功能予以加工而包裝出使用者要的東西，需要考慮的項目就多很多。像是：
●功能的目的與限制條件
●使用方式與範例
●定義檔的格式
●設計的過程與想法（維護需要）
●輔助的設定工具（使用方式太複雜時需要）

雖然對專案人員來說提供這些是正常的，但要讓專案人員能熟練地使用必須要額外付出不少努力。聰明的人自然會提出能讓自己信服的理由：“這個功能最終目的是要讓使用者正常地執行，因此只要符合這個目標即可”，所以就縮小了客戶的範圍與要做的事；主管們當然很高興聰明的人可以用很短的時間“做好”這個功能而且驗收，可以繼續處理下一個功能創造更多的產能。

主管只看產能且設計者只看驗收的情形下，專案人員需要的東西大半被忽視，難以訓練成用快速的方法做出正確的東西，工作久了自然會有嚴重的倦怠感。專案人員在主管眼中僅是可被取代的生產工具而已，發出的聲音幾乎都被忽略，在此狀況之下公司的開發團隊文化就只能取決於聰明的人怎麼做了。

X02 領導的風格決定了文化

2009-09-18T00:00:00.000+08:00

迪爾（Terry Deal）與甘迺迪（Allan Kennedy）在“企業文化”（Corporate Cultures）一書中明示：“企業文化是公司員工上下一致共同遵循的行為準則，一套做事情的方式”。企業文化也代表“在這裡，事情如何完成”與“組織成員間的互動關係”。

工作上有時遇到某些事情沒處理好，會聽人講起公司文化的影響與重要性。原先認為公司文化是種虛無的概念，在無形之中慢慢自行形成的；但經歷過一些狀況之後卻感覺到文化的形成主要在於“上行下效”，每個團隊的領導者如何做事連帶地會影響到團體內所有成員的做事態度。這個感想也剛好對應了前面的企業文化定義。

領導者在意的面向會影響成員的做事方式，絕大部分的領導者基於成本與績效的壓力，想法都是目標導向的。僅在意“事情何時完成”時成員就會找出最快符合驗收條件的方式來做事，連帶地成員之間在分配任務時也只在意自己的目標何時可以達成。每個階層都用自己的目標來檢視所有的事，眼光就逐漸變為短淺，落在自己頭上的事才算事，別人的事能夠不沾上邊就不要去碰，久而久之自然就會形成冷漠的公司文化。（切割系統介面如果也能切割到這麼乾淨的話，會是很令人佩服的事，可惜二者總是恰好相反）

領導者普遍在意的還有“解決眼前的問題”，資源的調度都是為了要快速地解決會影響驗收與成本的問題，只要搞定跟錢有關的問題就好，其他的都看不上眼。若是再搭配之前形成的冷漠文化，公司的氣氛低迷，團隊的士氣渙散等現象自然會跟著出現。更重要的是問題的根本原因從來都不會被搬上檯面來討論，也沒去研究未來如何要如何避免相同的現象，成員就這樣眼睜睜看著幾個同樣的原因造成各種不同的問題，令人疲於奔命。

希莉格在“真希望我二十歲就懂的事“書中說：“聰明的人往往陷入一個陷阱：他們寧可做〔聰明〕的事，而不是〔正確〕的事。所謂聰明，就是最符合自己的利益。”如果要提出公司文化形成的最重要因素，我深深地認同這一句話。

X01 系統的功能來自客戶需要的服務

2009-09-16T14:40:00.002+08:00

系統的開發大多著重於系統如何滿足使用系統者的需求，對系統使用者作需求訪談後就會往下展開系統內部的相關分析設計。近幾年IBM提出服務導向架構（Service Oriented Architecture）的想法，資策會也在推廣服務體驗工程（Service Experience Engineering）的方法，最近剛好有機會接觸到這些從不同角度看待事物而產生的概念。

開發系統的時候注重的是從使用者角度做事時系統提供的功能；在以使用者為中心處理一件事時，系統提供越大範圍的支持會讓使用者做事越輕鬆。然而在很多情境下，像是銀行、電信局、郵局等等的櫃檯人員，使用者會做什麼事情是根據臨櫃的客戶的需要而決定的，使用者端提供越快、越正確、越完善的服務就有助於客戶的認同。（此時的系統只屬於服務的一部分而已）

既然發動使用者做出對應行為的真正原因是客戶想要的服務，那麼研究客戶端的需要便形成了現在的趨勢。定義出客戶在特定情境下想要達成的目標，洞察客戶在該情境下的行為、對四周人與物的互動，從中找出可以改善現有服務或是建立新服務的地方，就有機會提供給客戶更好的服務體驗並有機會為公司帶來更多的客戶。

在系統的關係圖上從Actor一分為二，在系統方面需要的是方便好用的整合環境，在客戶方面需要的是提供更切合需要的服務。原則聽起來並不難，但是要從原本的技術角度轉換到客戶角度來看待這層關係，視野很容易就被原有的思維所限制住而難以突破──至少我就經歷過這段痛苦期。

所有的事都發生的原因，也有其完成的目標，發掘出最根本的需要並依此展開為實行的細節就更有機會真正地滿足原始的需求。這不是很簡單的道理嗎？

Y03 與理論型同事對設計作法的討論

2009-09-14T14:57:00.001+08:00

Ｅ主管是之前提到過的理論型同事，在技術部門裡可以說就只有我與他有把握能夠將分析與設計全部轉化為可以實現的作法。最近我們在參考RUP想要定義出一套可實現的OOAD作法，但是為了用什麼而做的議題有了一場“熱烈”的討論。

他的想法主要是參考大師們的說法，因為那些都是根據有經驗者的智慧結晶而定義出來的；不管是分析設計時應該做的步驟、使用的工具與應有的產出等等，都鉅細靡遺地遵循書上的方式。我則根據部落格上的心得，先把使用UML工具會作出的產出定義為程式碼，再逐一將分析與設計的想法衍伸在程式碼裡。

我們的分歧點在於“不應該用程式碼作設計”。Ｅ主管的感覺是直接產出程式碼而不先模組化就會回到以前設計不良的窠臼，同時也提到以前在學校若先寫出程式碼會被教授責備根本不作設計的事，當然也聽不進去我希望解決之前使用UML工具進度緩慢、達到分析與設計模組追溯的目標，因為他暫時落入“馬上有程式碼絕對作不出好設計”的想法中。

爭辯了一陣子雙方僵持不下，最後我只好換一種方式說明。先解釋說，現在有一個功能與Rose完全一樣的UML工具，採用的OOAD作法也與RUP完全一樣，然而那個工具的存檔格式剛好與Java程式碼一模一樣。今天我們的OOAD作法每一步應該做什麼就同樣地在“程式碼”會有什麼，這樣一來無論分析或是設計都能夠採用我計畫的工具作出全部的管理與追溯；分析的“程式碼”則在build產出時不處理而僅作為模組化的分途。

Ｅ主管認同了我的說法，但有個前提是：要先明確定義好OOAD的詳細步驟後，才能逐一定義與我想法之間的對應。前面的討論對於modeling來說都只是產出的物，先要有應做之事與其順序後再去談應有之物；這也正是做事的基本前提。

Y02 如何寫出難改又難懂的程式碼？

2009-09-09T00:12:00.004+08:00

一直都在談如何作好分析與設計，這回就來個逆向思考的建議。

●目標：如何寫出難改又難懂的程式碼？

想像公司早上第一個到的人所要做的事如下：開鐵捲門、用識別證開門、開一號盤的15個電燈開關(1-15)與二號盤的15個電燈開關(16-30)。現要設計一個功能來實現這些行為，建議使用以下推薦的方式來撰寫程式，保證可以達到難改又難懂的特殊效果同時不會影響功能的正常執行。（此等技術暫時命名為程式碼的人工混淆化）

●Class、Method與Field的隨興命名
　效果：讓人即使看到名稱也不見得知道這就是他要找的程式。
●Class隨便放到某個Package裡
　效果：與上一招同時施展，可以讓人感覺Class在某個雲深不知處的地方。
●Class、Method與Field內外完全不寫任何註解
　效果：讓別人從眾多的程式碼反推你原本想要做什麼。如有人能完全識破此機關的話一定要選為衣缽繼承人，因為那是萬中無一的奇人。
●執行的大大小小步驟都寫在同一個Method
　效果一：搭配前一招時可以讓邏輯處理的焦點忽大忽小，明明在講進門要做的事卻一下子跳到拿出識別證的動作，完全不知道在幹嘛。
　效果二：可以保護自己想出來的程式解法，例如自己發明一個很帥的識別證拿法就可以直接寫在Method裡，其他人想要用就只能copy（因為要抽方法就得幫你改寫程式，以我所知沒幾個人有這閒工夫）；有天你發現姿勢可以更帥時可以保證只有你知道，因為別人抄到的是你前一次的姿勢，跟你肯定沒得比。
●不要花時間去想執行發生錯誤時該怎麼辦
　效果一：程式碼裡一定存在著錯誤，這樣一來可以用更多的錯來證明這句話是極為正確的。
　效果二：搭配前前招使用，可以讓別人在不知道處理邏輯之餘更不知道發生錯誤要怎麼辦？同時讓老板知道只有你能搞定這樣的錯誤處理問題。（註：平時常逛逛求職網站是有助益的，因為總有一天會發生連自己都搞不定的重大問題……）

採用以上方式撰寫程式碼，將會產生下列各方面的效益：

●個人方面：
　加速個人的效率與產能（不用抽Class與Method可減少思考與重構時間）
　提升個人在開發團隊中的重要性（沒人有把握修改別人的程式）
●公司方面：
　加強與其他公司合作的意願（即使程式碼外流也毌用擔心技術被學走）
　減少額外控管程式碼的成本（只要從jar file反組譯回來就是完整程式碼）
●產業方面：
　創造更多的營業額（因應提高開發與維護的成本會增加系統的售價）
　提升開發人員的素質（無法看懂別人程式碼者會被淘汰，只留下適任者）

註：最近一個多月狂寫公司某份計劃書，因而導致這篇文章的風格被影響。

Y01 程式設計是藝術創作？

2009-09-04T10:40:00.004+08:00

Ｋ主管常說一句話：“程式設計在實質上是一種藝術的創作，同樣的需要被不同的人實現時會有不同的產出。”就我所知有不少人都贊同這個觀點。前陣子我也認為這個說法挺有道理的，可是總覺得似乎有哪裡不對勁；思索幾天之後終於有了不同的想法而與Ｋ主管聊起這件事。

我提出的切入點是人像的雕塑，這很明顯是屬於藝術的範疇，每一位作者都可以任憑喜好去製作各式各樣的人像。接著提出同樣屬於人像創作的秦朝兵馬俑，我們都曉得兵馬俑的數量很多，雖然姿勢、表情與裝扮都有不同，但是服裝與身材卻是大致上相同的。再極端一點可以想像有一國的統治者想在全國各地放置出他的雕像，於是他穿上最喜愛的服裝並擺出某種姿勢，要求全國所有工匠全部都得做出一模一樣的人像。（以上的前提建立在工廠出現之前，所有的人像都必須經由手工製作）

從上面的說法，我們可以發現隨著要求的規格越來越多，每個藝術家的創作也可以從依各人隨興而作演變為具有統一規格的產出。同樣的道理也適用在程式設計之上：在沒有規範時每個人寫出程式碼的想法與風格會是相異的，隨著種種規範與規格的建立將會調整每個人的想法與寫法，漸漸演進為所有人產出的程式碼每個人一看就明白。

Ｋ主管認同了我的看法，想法調整為：遵循規範與規則的部分像是工程，其他的部分則屬於藝術的創作。然而隨著規範與規則訂定地更加完整，藝術創作的範圍勢必越來越小；等到某一天程式設計的一切都有人定義出良好的規範與規則時，programmer是不是真的就會像作業員一樣，每個行為都只能根據該生產線的SOP找出適合的零件來組裝產品呢？

W26 一名家教班裡的小三學生

2009-06-30T00:00:00.005+08:00

不久之前造訪一位朋友所開的國小家教班。在裡面遇到一位小三女學生，她的基礎非常不好，面對簡單的加減應用問題時，是用猜的來決定要用加號或是減號。我試著用數線的方向性來對應加減，也試過讓她固定用大的減去小的來得到答案，但是沒有真實理解數的概念時，一切的說法都沒法讓她解出任何一個類似的應用問題。

周遭遇到的小朋友都還算聰明，很訝異還是有小朋友的理解力如此不佳，這時不禁連想到李家同先生的文章與他所堅持的教育理念。會去留意其他人的的退休計劃，有不少人認為勞碌了大半輩子後，剩下的時光想要過輕鬆的生活或是享受異地的旅遊。

對妻說過，退休後想每年都住在一個不同的偏遠地方，一方面體驗不同環境中生活差異，另一方面就是主動地為附近的小孩進行課業輔導並傳授做人做事的方法。教育的平均有兩個方向可以努力，一個是提升偏遠地區的教育資源，另一個是提升資質較差的小孩到平均的水準，每年旅居到一個不同的區域協助當時所能遇到的所有人，這應該是能力範圍內所能做到的。

資質不好的人因為聽不懂而無法改變自己到能理解的程度，但是聰明的人反倒因為聽懂而更無法改變到更進一層（為他人服務）的程度。缺乏＂吸收資訊，判斷對錯，調整自己，成就他人＂的成長彈性，到底只能讓自己的聰明才智僅讓自己獲得利益，同時還認為其他人的改變也只是為了他自己而已。（奇怪的是，反倒是心裡有不好的想法時大半會說是因為別的某某事件被連帶影響的）

今天的我對於系統開發與人生想法是如此。明天呢？後天呢？想法還會有再度改變的那一天嗎？

W25 My Object = Data + Behavior

2009-06-29T00:00:00.001+08:00

在與兩位同事討論時，其中一位同事說，每個行為包裝為一個方法的想法很像Behavior Driven Design（後來查過資料，發現應更像先不看架構的責任導向設計－－Responsibility Driven Design）。Object一直都是包含資料與行為，既然具有這兩類元素，Data Driven Design與Behavior Driven Design就應該同時注重。

角色、物件、大小事都對應到各自的Object（或是元件）並依其特性抽取共用是我的設計基礎，資料結構與處理步驟全採用一對一的對應設計是我的堅持，符合原始特性的定義才能夠將改變局部化到最小區塊，進而得到最少化的測試範圍。這些好處的相對代價是開發人員要額外作設計，必須花費較多的時間為自己與別人安排程式碼。

對於OOAD的題目，我一個人思考了兩年，提出的經驗與作法盡可能涵蓋到工作中所經歷到的各個角落。有一位喜歡看書的理論型同事是我經常討論的伙伴，從他那裡聽說到許多不用功就不會知道的名詞與作法；共事的同事們是我主要的經驗來源，由於他們現有的產出我才能明白各個角落的好處與缺失；專案上的同事則是我琢磨想法的對象，常問他們現在的作法與優缺點是什麼，同時提出我的作法詢問是否能留下好處並改善弱點。

每個地方的說法我都推論與驗證過，雖然能有可以解決的方案，但是我相信並不會是最佳的作法。許多同好都投注許多心力鑽研軟體工程的各個方面，沒有道理我只用兩個人年就有最後的結論。目前差不多是我的極限了，未來除了製作對應的工具之外，更需要的是有其他相信這一條路的人一同討論每個角落的最佳化。

這十年來在工作上所遇到能夠抱持相近努力方向的人，實在是屈一手之指可數呀。（當然不包含發現專案有問題時才喊著要好好設計口號、作下一個專案時又開始計較時程與產出的那些人）

W24 成敗的關鍵(2)──看待的角度不同

2009-06-27T00:00:00.002+08:00

收集一些在專案開發期間常聽到的話語，用類似的語意表達如下：

●專案經理：專案的目標在於系統的準時驗收，任何可能影響時程的額外活動最好避免。
●前來支援的架構師：我已建立好可以執行的基礎架構，只要這樣這樣使用就可以。至於元件要怎麼安排、程式怎麼規定，那是專案團隊的事。
●系統分析人員：每個交易或功能的需求訪談都已經完成，並彙整到各自的需求文件裡。
●系統設計人員：根據每個交易的需求文件，已經設計並開發好對應的程式。同時單元測試過的內容都正常。

表面上看起來沒什麼問題，對不？每個人都做好每個人自己應做的工作。可惜的是，即使每個人都努力地讓產出滿足驗收清單上的每個檢核項目，卻還是有些莫名其妙的問題跑出來、客戶也會莫名其妙地抱怨系統品質不大好、每個人也莫外其妙地幾乎不懂別人負責的部分。

專案裡的產出，不管是文件還是程式都有許多共用的部分，每個人都用自己的角度處理共用的部分當然很容易令其他人難以使用。共用的地方最好是可以符合全部人都方便使用，那是需要投入時間去整理與調整（設計）的；但是＂為了公眾的利益去作設計，會影響到投入自己的工作的時間＂卻是一種衝突，在管理上不去注重共用的部分而強調個人產出，終究會使大家只留意被要求的地方。

我在Ｎ年前也還是可以用極快的速度達成個人產出目標的，不過每次完成工作後再回頭為新需求修改程式時，總是發現內部已經錯綜複雜到難以變動；這樣的經驗累積幾次後終於覺悟自己還缺少了些什麼。現在的我在進行某個步驟時，都會額外花一些時間去整理共用的部分，但是在與其他較年輕的人討論類似話題時，總是發現他們雖已知道現況有些窒礙而還看不到我所注重的地方。

我並不清楚每個人看待的方向是訓練出來或者是依檢查標準而定，但是消極地不想去碰灰色地帶的心情卻感受得到。每戶人家都自掃門前雪時，共用的通路肯定是不會有人去清理的！

W23 做人的方法(16)──態度與高度決定一切

2009-06-26T00:00:00.002+08:00

態度：接收到外來資訊後能與自己想法比對並朝最大的最佳化加以調整。越自我的人越不容易改變。
高度：從不同人的角度來看待一件事物並朝對最多人有利的方向改變。越自我的人越無法從別人的角度看待事物。

這些當然是我自己的解釋，不過卻是從一些事件裡得到的結論。

團隊裡有位超強的工程師，能夠快速地選擇對的技術作出功能，也能夠快速地判斷問題提供作法；聽起來一切都很好，但是唯一的問題是方法沒有適當切割且沒有註解，就造成沒有人的理解跟得上他的思緒。有位專案經理跟他說，寫出讓其他團隊成員可以快速理解的註解與寫法，讓多一點人瞭解他的產出未來可以讓自己輕鬆一點，他回答道：我不會UML，也不會寫敍述性的文件。

2009/05與大主管面談時提到對現有設計的改善作法，他說能夠瞭解我想法帶來的好處，稍晚他安排我與兩位資深工程師討論我的想法。在聽過我的敍述之後，他們說：我們可以聽懂你所想要做的事，但是看不到好處在哪裡？我的作法對做事的人來說是浪費一些時間來換取更多的人快速知道自己做了什麼，看不到好處的意思很可能是因為他們並未從旁人的角度來看待。

前面的工程師留下了很多作品，包括我之前維護的那個產品；這個產品應用在專案時的使用門檻很高，目前被重用的其他工程師都花了很多時間去摸索程式碼。他們異口同聲地說，想要深入瞭解這個產品沒有捷徑，一定要自己下苦功。不過在面對同樣沒有註解且風格與自己不同的程式碼時，那位工程師終於說：看不懂他寫的程式！

有些懷疑現在的大師們是否都在開發上具有強大的能力，以至於他們從未完整維護過全由別人所寫的程式碼？賦予自己的責任是開發系統時自然會專注在這個課題；至於怎樣讓別人容易維護程式碼？管他的，反正我自己維護完全沒有問題而且不會找我去做。

W22 成敗的關鍵(1)──開發速度的考量

2009-06-25T00:00:00.003+08:00

專案裡需要一個分析資料結構的功能，該結構裡的ParentDataModel與ChileDataModel是從屬關係，但是都具有相同的屬性存取方法，需要寫的功能是處理多個屬性的集合，從兩種Data Model取得屬性的設定值來檢查是否Class字串。

由於這個功能時間上比較趕，撰寫ParentDataModel的時候就直接只思考它的特性，將完成該方法的功能填在一個Method裡。等到撰寫ChildDataModel的時候發現與前一個方法似乎只有傳入的物件不同而已，但是再抽取前一個方法似乎要浪費一些時間，於是copy-paste後再修改了幾個地方。用極快的速度寫好這個取得屬性的功能。

認真地分析一下，這兩個方法只是傳入的物件與紅色框內的程式碼不同，其他的內容幾乎一樣，裡面包含了兩個分解動作與一個迴圈。開發最快的方式是像前面一樣直接複製後修改物件名程，但是就有一堆重覆的程式碼。理想的作法應該再切分為兩個小方法並串連呼叫才對。下面是把分解動作另外抽出方法的結果，同樣是沒有註解的程式碼卻具有很高的可讀性。

之前提過曾把一個元件的View與Controller寫在一起，寫的時候連測試用了三小時，改寫時連測試又多花五個小時，但是一開始就分開撰寫的話估計應要五個小時；概略計算的話，如果沒有修改可以省兩個小時，修改時要多花五個小時。觀點拉到有100個元件的系統來看，假設未來因需要而有20個需要重構。直接作的時候省下100 X 2 = 200小時，另外花費20 X 5 = 100小時重構，整個開發與測試的投入反而省下100個小時。

這是專案開發裡的數字迷思，缺乏彈性的快速設計反而會比設計充滿彈性的作法快200小時，即使面對需求改變還是快了100小時。以前我估計的設計時間常被說為留有buffer，因為別人估兩天可完成的東西我需要五天；如果你是專案經理的話，會用什麼角度思考而出抉擇呢？

W21 記錄的設計(2)──交易記錄Data Model的集合與應用

2009-06-24T00:00:00.000+08:00

經過適當的設計，我們可以從server的Log檔案裡用工具取得所有使用者的交易記錄。雖然從電子日誌的資料庫也可以拿到類似的項目，但是在一個嚴格控管的環境裡並不是隨時都可以接觸到資料庫且隨心所欲地下達想要作的指令。

分析出來的交易記錄可以用人、事、時、地、物各種不同的角度去篩選範圍內的資料，如果篩選的條件有適當的分群可以有更方便的應用，像可選擇從個人角度與單位角度去篩選資料。對於一個時間範圍內（通常是給定的Log記錄範圍），較常見的需求是交易的執行種類、執行次數與執行時間，這可以反應系統的使用效益與效能，也可能被要求作成統計圖表以方便查看。

就曾因交易執行時間過長的問題被要求分析Log，當時拿了五個工作天之間的四台server與十台client的Log記錄後，利用之前寫的分析工具來處理上千萬行的Log記錄，最後得到了客戶反應時間慢的區間內的各種數據用以佐證對於問題所在的推測。另外，查看個人在某個時間點所作的事情序列，也是除錯時重要的資訊。

概略說之，全部Log記錄檔還是以Data Model的方式來看待，裡面包含的每行Log記錄組合為一個個的交易記錄Data Model後，就能夠像是搜尋資料庫一般篩選出任何需要的資訊──當然，前提是Log記錄的內容要能確切反應出該時間點的系統執行資訊。

W20 現在的執行位置──getClass()與getMethod()

2009-06-23T00:00:00.001+08:00

在Log裡的記錄需要註明程式的出處時，一定會用到getClass()，經由這個方法可以取得Class名稱；但是再細部定位到程式的發生點時就只能拿到行號，然後再找程式碼看看那一行是在做什麼事。

為什麼拿到的資訊不是Method Name而是與程式碼內容無關的行號呢？在執行時有getClass()與this可以取得現在執行的物件資訊、卻沒有getRunningMethod()與thisMethos（二者均為虛構）等取得現在執行方法的功能呢？推測應該與程式設計者較注重結果卻不注重過程有關係──因為只要知道確實在哪裡出錯就好，不需要知道原來想要做的目的。

若去詢問什麼樣的程式碼需要被抽取到Method存放？一個很尋常的答案是＂發現某一段程式碼在其他地方存在且完全相同時＂，這就是我感到奇怪的地方。檢查兩段程式碼是否相同的觀點僅是查看其外表，但是我一直認為程式碼被群聚為Method是它們屬於分解動作之一才會被提出的。重構的觀點提到＂有一行註解之下的一段程式碼可以抽出為一個方法＂，這比較接近事實，不過要如何保證一行註解之下的是＂一段程式＂而不是＂三段程式＂？

Method抽取時依這樣的概略原則拿到的可能是錯誤的對應：或許是應該在一起的程式碼被拆開，或者是不該在一起的被放在一起，這些都會在某些場合下造成系統的複雜調整。當每個Method都是依照負責某個行為的目的而被建立起來之後，才會有對getRunningMethod()的需要。

註：目前的getRunningMethod()可以利用Exception裡的printTraceStach()來達成。將這個內容輸出為字串，就可以解析出指定位置的完整method call stack，利用此方法可以省下在很多方法內插入Log的時間。

W19 記錄的設計(1)──記錄行與交易記錄Data Model

2009-06-22T00:00:00.001+08:00

系統執行狀態與歷史的內容能夠提供許多分析的資訊，這些資訊我們習慣在執行中隨時記錄為Log。不過Log的特性是一次記錄一筆與上下文無關的文字，所以如何在一行文字間涵蓋到重要的資訊以及建立起前後Log的關聯，是定義記錄內容的重要關鍵。

對單行記錄而言，人、事、時、地、物五個基本資訊加上想要記錄的內容應是最基本的構成。記錄的內容原則上是由能識別系統行為的關鍵字，加上進行該動作時所需的相關資訊所組成；這部份最好是格式化為固定字串，能夠轉換為基本Data Model會較容易處理。

在一個交易期間會有多行的記錄存在，因此要定義交易開始與結束的記錄內容，夾在這兩行之間的表示為同一個交易期間。以範圍框住同一交易的想法雖然沒錯，但是遇到多執行緒執行交易時會發生兩個交易內容混雜產出的問題，因此記錄行必須再定義一個交易序號的資訊以供識別。此外多行交易記錄經過處理應該能夠取得一個交易記錄Data Model，具有從交易方面看待時應有的執行屬性。

記錄行的意義與達成目標的分解動作是很相似的，記錄的是單一動作的執行內容；交易記錄的意義則像是功能的定義，在裡面可取得執行時的相關資訊。記錄行主要提供的是有沒有進行該項動作、有沒有錯誤發生，交易記錄主要提供的是該交易的基本資訊、輸出輸入資訊與結果；前者是系統人員所檢視，後者則應用在使用交易的記錄分析。

W18 快速開發的工具(3)──進化為系統分析工具（SA Tool）

2009-06-20T00:00:00.001+08:00

限制整個Workspace的UI編輯工具為只能編輯專案層級的元件時，編輯的對象就會只有Use Case下的流程，選用的範圍則是該tier提供的Activity。執行流程的定義只是SA的一部分，所有與交易相關的定義都應該被容納到系統分析工具裡才是完整的SA Tool。

這表示交易相關的輸入與輸出都要被考慮，像是畫面的設計、列印的格式、主機電文的切割定義、主流程的功能選擇、輸出入欄位與Context的對應……等等都應該呈現在工具裡。另外整個系統的設計也應該被定義，像是角色的定義、交易的定義、資料的定義、以及任二者之間的關聯……等等。SA Tool的好處在於進行需求訪談的同時，可以利用系統收集全部相關資訊並立即使用，在快速定義交易的同時盡量避免產生一些已知的問題。

上述每一個編輯項目都應該要能嵌裝與拆解，施行時視系統實際的架構關聯來設定SA Tool應該具有哪些模組。這是一個更龐大的工程，系統開發時所需要的一切概念組成的架構與關係需要精確地定義與設定，再根據這個架構去設計呈現的UI編輯工具；我們當然明白，只要那個架構有所變更就會影響到SA Tool需要再度改寫。換句話說，除非能夠研究出開發系統時會有的所有定義與關聯，要不然SA Tool應該是個會被改來改去的玩具，或者是寫死為只適用在自己專案裡某部分的特定工具而已。

＂可被遞迴處理的元件結構＂是對程式設計的目標，＂通用的系統分析工具＂則是對系統開發的理想。縱使這兩個想法的背後都需要艱難的分析設計與實作，不過若能確認能夠解決大部分的現有問題而沒有邏輯上的破綻，這個決心是不會變的。

W17 快速開發的工具(2)──Project、Workspace元件的UI編輯工具

2009-06-19T00:00:00.001+08:00

Component結構UI編輯工具是針對單一元件的設計，但是將系統用tier與layer切割之後會發現每一個格子都具有相同的特性，與同一層及自己繼承的元件都擁有類似的關聯。根據這個特性，只要詳加定義可以使用的範圍，就可以在指定編輯某一格子時只顯示出有關聯的其他資訊。

設定關聯後顯示相關的範圍是這個想法的核心。目前的想法是用一個設定工具將Workspace內的每個Project都對應到一個tier-layer切割出來的格子，每個格子可以引用的範圍是同layer、同tier的合部與同tier、下一個layer的全部；然後再更進一步地對每一個格子裡的Package定義使用關聯，不在使用方向下的Package都是不能呼叫的。

編輯工具的元件索引區應列示現有的所有元件以及它們所在的格子，選擇一個元件就會開啟它的結構與方法列表；選擇一個方法後在旁邊列出所有可選用的元件與API，可以為方法繪製流程圖並引用那些元件方法與API來組裝。依此模式來設計全部元件的每一個方法。

與註解有關的功能部分可以加在這個工具裡，像是編輯Class或Method的註解與自動產生基本資訊等。或許還有更多的部分還可以加上，目前對於這個龐大的工具只有初步的輪廓知道可行，但是還沒有很清楚地定義各個細節。

W16 快速開發的工具(1)──Component結構UI編輯工具

2009-06-18T00:00:00.000+08:00

在資訊業裡的大多數人員都有著一個夢想：是不是哪天能夠出現一個工具，只要根據需求勾選一些選項或是畫出流程圖後，就可以自動產出能夠達成功能且具有一定品質的程式？雖然絕大多數的人覺得這像是被工作壓榨過度後的囈語，但是我這兩來年在心裡盤算與推演卻感覺那是有機會達成的事。

回憶一下設計一個小方法時自己的行為。首先先根據需要所要處理的資料來定義處理的迴圈、決定每層迴圈內所要執行判斷條件或動作、針對每個動作挑選出最適合的API方法、最後再將處理結果或例外傳出去。簡單地看，設計的過程只有流程順序的定義與動作方法的選取而已，不是嗎？（不存在的動作方法可以宣告一個新的，再回歸為選取）

印度公司的電文處理流程定義與IBM的SOA概念，多少都幫助我更完整地思考這個可能性。想像有那麼一個元件設計的UI工具，在設計方法時的主要編輯區是繪製流程圖的區域，我們可以先在這裡決定方法內處理迴圈，之後要定義處理動作時右邊有個區域列出允許呼叫的全部元件方法與API，只要從中挑選出想要使用來組裝。（宣告與給予初值也視為一種動作）

對於程式人員來說，用工具來產生程式的效率實在是慢太多了，倒不如直接寫程式省事。用工具的好處是可以降低學習的門檻、限定使用方法的範圍並產出結構與寫法一致的程式碼，這都是寫程式時難以達成的標準。把程式碼倒回工具產生流程圖倒也可以，順便篩選那些無法倒回流程圖的程式，那表示撰寫時並沒有按照一定的規範。

W15 令人感到麻煩的設計(16)──固定值與固定常數的意義

2009-06-17T00:00:00.000+08:00

在設計與實作的時候，所有的固定數值與字串都應該被抽取為常數，使用的時候就將固定數值與字串置換為該常數。原本我也依這個方式使用常數，但是不久前製作計算function points工具程式時卻發現不同的用法。

上下傳電文欄位是功能點計算的來源之一，第一個專案的電文定義檔命名規則是在交易代號後加上u或d來表示，因此將上下傳檔名另外用常數代表，取檔時就使用txnNo+UPLOAD_FILENAME+".xml"來組成完整檔名。程式拿到第二個專案就發生了錯誤，因為檔名是以別的名稱識別，只好直接修改常數內容讓程式可以正常執行。

依照事對物的想法，有UPLOAD_FILENAME的存在就應該對應存在一個getUploadFilename()的事存在，之前在檔名裡直接嵌入UPLOAD_FILENAME的作法是一種綑綁。＂取得上傳的檔名＂應是一件事，其中包含的是一種規則，雖然在大多數的情況下規則是直接取得UPLOAD_FILENAME，但是規則總有變的一天，將改變的規則限定在一個給定的方法裡可以增加設計的彈性。

那個工具程式後來作了一個改變：收集所有在專案裡可能有所不同的規則，定義一個Interface容納取得那些規則的方法，看要執行哪一個專案的內容就使用該專案特有的規則定義。

得到了寶貴的經驗：每個常數都應該轉換為具有該層級元件意義的名稱與存取方法，以便操作時明白其含義。呼叫時可直接在參數裡引用常數，但是在取用時要使用存取方法，因為取用時隱含規則，規則都可能改變。

W14 專案的開發(6)──Component的方法設計

2009-06-16T00:00:00.001+08:00

每一個Component Interface Method都可被視為該元件的一個Use Case，在設計時同樣以輸出輸入為起點，再決定內部的處理流程與動作。

設計中若需有其他元件的功能支援，必須是位居同一層次的元件才可以；讓同一次層次負責該項功能的元件集中管理達成功能所需的資源，可以有效減少上下層的交互關聯。如何明確切割出有對應意義的分解動作、動作要放置自己這一層還是父元件，這個作法的好壞會影響到元件變更時的彈性。應切出方法的動作沒切分而直接實作在原有方法裡，會讓多個動作混在一個方法裡；應放置在父元件的方法沒拉上去，會令方法的功能對應在錯誤的層級上。

從上而下將所有元件的方法逐一設計出來、收集每個元件內的所有方法、記錄每個元件方法與其他元件方法的關聯，這些是設計階段所要做到的事。將方法的設計依＂達成目標的SOP”之思維組織，並將動作放置在正確對應的位置，會得到較有組織化的程式結構。

看過物件導向程式的九個規則這篇文章，看起來像是從程式碼的呈現上去避免或改善一些寫法。比起＂看到某種狀況就改用另一種方式做＂，倒不如＂依其需求的想法作出對應的寫法＂能夠更教人明瞭其中含義。例如以下列出的幾個規則：
●每個函式裡面只能有一層縮排，如果需要多一層，請多寫一個Method去呼叫
●不要使用else這個關鍵字
●所有基本型別都包裝成物件
●保持東西輕薄（Class不超過50行，每個Package不超過10個檔案）
●使用第一級collections

遞迴設計所有流程元件的每一個方法，直到剩下要實作功能元件為止；功能元件應由該功能領域的專家設計實作或是由元件庫裡挑選適合的元件使用。經過基本設計概念課程與系統領域教學的每一個人，應該都有能力進行流程元件的設計。

W13 專案的開發(5)──決定完整的Component Diagram

2009-06-15T00:00:00.001+08:00

首先要進行整個系統的元件佈置。一開始先參考架構先定義好系統的tier，再根據L05的切割層級（參考上圖）來定義layer，如此可以得到一張矩陣圖。

●分析的Component Interface必須放在專案的那一層，根據發生的地點放到對應的tier裡
●研判是否有相似度很高的Interface或Interface Method，在此先作調整
●每一個Component Interface都要繼承一個上一層級的Component Interface
●循環繼承到最基本那一層，不能有跳層或是沒有繼承的Component Interface
●一直review這張圖直到大家都沒有異議為止

系統這張Component Diagram非常地重要，因為一旦要移動位置或是調整繼承的話，基於這個靜態佈置上所作的動作設計全部會因架構變動而重新調整，影響是非常巨大的。還有在設計的時候每個元件都只需要放置一個Component Interface就好，不用顯示方法（方法可以在接下來的階段移動）。

定稿之後，可以再使用一個小工具讀出Component Diagram內所有的Component Interface與繼承關係，再呼叫Component產生工具一次鋪設出所有的元件結構。只要這個元件結構能適應未來的變動，那麼一切的工作都只有在元件與其繼承的元件內部設計而已。

W12 自動收集或產出系統需要的資訊

2009-06-13T00:00:00.000+08:00

在開發階段會陸續建立新的message id，一般作法是用人工將新的message id貼到properties檔案後再放上詳細的訊息內容。漏掉時就看哪一個message id不存在再另外補上。

現行的ResouceBundle作法令訊息檔的內容只能讀出而無法寫入，在基本Data Model加入PropertiesDataModelInterface為了改善這個現象，讓訊息檔可以新增並寫入。基於這個設計可以再往上包裝一個訊息元件，在開發與測試時設定參數為可增加模式，把找不到對應訊息的message id加入後立即寫回properties；在正式執行時再設定為ResouceBundle模式加快速度。

系統開發的時候還有很多自動化收集的機會，只要是用人工重覆輸入的都有機會寫出輔助工具。像是系統的參數設定也可以設計類似的作法予以自動新增、收集後群組化的Data可以利用工具自動轉出資料庫用的DDL檔案、Actor列表與Use Case列表、Actor與Use Case使用關聯可以產出權限定義資訊……等等，還有之前提過將所有Activity對應設定為Component Interface Method後再自動產出Component Interface。

分析完這次Iteration裡所有Activity並定義妥全部Component Interface後，就可以進入設計階段。

W11 專案的開發(4)──Use Case的結果與訊息

2009-06-12T00:00:00.000+08:00

做每一件事都有成功的結果或是失敗的原因，這同樣是每一個Activity所應考慮的範圍。使用者操作時必須明白操作的結果，因此每一個Activity都應該要有各自的回傳結果，在Use Case結束時顯示相關訊息讓使用者看到。

底層的錯誤要到設計時才會詳細定義，但是在使用者端還是會有明確的狀態可收集。像從密碼輸入器輸入密碼來說，使用者很明顯地可以考慮到沒有接續、無法按鍵、逾時未輸入等等的錯誤，這些都應先收集起來成為message id。

message id最好是每個Activity都擁有自己的編號而不要共用，這樣做的目的是可以在一拿到編號就知道是在哪裡發生的問題；當然，不同的id可以指定顯示相同的名稱，因為使用者只是需要知道有錯而不一定要知道在哪裡錯。密碼輸入器與鍵盤輸入的逾時理應有兩個不同的message id但是在顯示時可以只有＂密碼輸入逾時＂一種敍述。如果二者的message id都相同，要是哪天客戶希望二者顯示的訊息不同時，又會令人跳腳。

軟體的複雜度其實有很多是人為造成的，其中又有很大部分是把多個來源混雜成為一個定義。在系統沒有變動的時候，因為執行的結果全都正確所以這種定義並沒有問題；但若有問題或變更造成的修改落在原來的多個來源得分割為不同的定義時，真的是改的越底層就陣亡越多人。忠實地用一個定義對應一個來源是降低這類風險的最佳作法。

讓每個Activity都只擁有自己的message id就毋需製作追溯表，因為這只是一對多的擁有關係。message id與實際顯示的訊息內容是多對一的關聯，不過在實作時會因為properties的作法而被攤平為一對一。

W10 專案的開發(3)──擬定流程與收集Activity、Data

2009-06-11T00:00:00.000+08:00

統合看待已經找出的Use Case，接下來要詳細分析每一個Use Case內部的必要執行步驟（視為該Use Case的SOP）。進行之前的前置作業是準備系統詞彙表的收集處，這在進行分析時會逐步新增。

盡可能地收集每一個Use Case的完整執行劇本，定義出劇本中的分解動作，請記得要以使用者的角度來看待每一個Activity，同時從數個劇本中分析出必要流程與選擇流程，盡可能製作為一張Activity Diagram。只製作成一張Activity的目的是在後面要直接轉成程式。

每一個Activity如果牽涉到資料的變動，就從需求文件裡找出定義的名詞，一方面加入系統詞彙表，一方面註明Activity-Data的關聯。（目前的UML沒有這個記錄，只好自己作Activity-Data的垂直追溯表）分析完全部的Use Case後，收集的系統詞彙表可以用CRC Card的方法定義彼此的關聯，藉以產出Data Model的定義。

繪製Activity Diagram的時候如果Activity已經有了＂絕對＂要使用已經存在的，因為那才是實際有的關聯；如果畫成兩個就會讓關聯分開到兩邊而產生不正確的結果。Activity的package佈置就偏向設計，將類似作用的動作集合到同一個群組裡。像上面兩種密碼輸入設備的Use Case若Activity放在同一個package就較容易看出相似性。

Use Case下的Activity Diagram裡擁有的Activity可以產生Use Case-Activity垂直追溯表，也可以產生流程程式；記錄Activity-Data的關聯，可以產生Activity-Data的垂直追溯表。根據一層層的關聯，最後可以得到Use Case-Data的垂直追溯表，就能夠清楚地知道二者的完整關聯。

W09 專案的開發(2)──決定系統的主要架構

2009-06-10T00:00:00.000+08:00

Use Case收集到一個程度，需要開始分析Use Case間的關聯，目的是檢查被定義為include或extends次數多的Use Case將之納入主要架構的設計。

直接查看Use Case的關聯（項目）看哪些拉出很多關係當然可以，不過製作出Use Case-Use Case水平追溯表（清單）會更有一目瞭然的效果。UML工具應要支援關聯的記錄與存取的API，那麼就可以撰寫工具程式直接產出為Excel檔案並註明include或extends的關係，再運用Excel的功能作排序、計數等等的運用找出適合納入主要架構的Use Case。

在主要架構裡會有些隱含的Use Case。像是在client-server架構下，如果沒有採用現成的framework勢必要自己設計一個收送的功能，即使客戶沒提也一定要有記錄log的功能，這些都是必須額外加上的Use Case。在這裡加上的Use Case大多與設計有關，必須視使用的framework予以調整到完備。另外還有一些event時間點的處理功能，也要一併納入考慮。

從UML model裡再轉換出Actor-Use Case的垂直追溯表，可以定義出執行功能的權限管理。在分析階段收集範圍後再追溯關聯，可以精確地得到相關資訊作為架構設計的依據。

W08 專案的開發(1)──收集Use Case

2009-06-09T00:00:00.001+08:00

在開始之前，先讓觀念作點轉換：
人＝Actor
事＝Use Case
物＝Data
時＝Use Case Entry Point
地＝Use Case Precondition

在系統分析時對Actor與Use Case應進行的步驟如下：
●收集全部Actor與Use Case以明確定義系統可以做的所有功能
●建立全部Actor與Use Case之間的使用關係
●分析Actor之間的使用範疇有包含關係者改為繼承
●所有Actor區分群組並定義在其所屬的Package下
●分析Use Case之間的使用範疇有包含關係者改為繼承
●分析Use Case內是否能拆解出include或extends關係的子Use Case
●所有Use Case區分群組並定義在其所屬的Package下
●明確定義每一個Use Case的發動時機
●明確定義每一個Use Case發動前的狀態
●明確定義每一個Use Case發動後的狀態
●收集每一個Use Case的所有可能劇本

在抽取共用Use Case的同時，思考的是＂某種特定的使用者目的＂。例如最近幫客戶設計晶片卡密碼驗證的功能，其目的是把使用者從密碼輸入器輸入的密碼傳到晶片卡模組去檢查，這雖然可以是一個獨立的Use Case，但也可以將用途切割為＂取得密碼輸入器上輸入的密碼＂與＂將密碼送到晶片卡模組檢查＂兩個Use Case，後者include前者。如果輸入密碼的方式又多了＂從鍵盤輸入密碼＂，由於是二擇一的關係，關聯就要更改為extends。

對設計者而言，Use Case與Activity的抽取常會混淆，Use Case必須從Actor的角度看待，其目的是＂對使用者有意義的獨立行為＂。上面若將不同的密碼輸入功能合併為一個＂從輸入設備輸入密碼＂就會有點模糊，因為輸入設備只是個概括的名詞（除非再另外定義輸入設備包括哪些）；若在其他功能內只允許用密碼輸入器輸入密碼時，這個Use Case就會變為不合用，重新定一個會造成功能重覆，修改原來的又怕會影響之前的Use Case造成問題。

沒有作好一對一的分析與設計，就常會有這樣的兩難局面。

W07 一般工程設計與軟體設計的不同

2009-06-08T00:00:00.003+08:00

最近參與公司內的討論，聽到了＂因為軟體本質上的不同，所以一般工程方法難以適用在軟體工程＂的話語。發言者強調軟體是易變的，所以無法像工廠一樣產出固定不變的元件，同時設計也常因需求改變而隨時變動，建立在易變產出上的方法自然無法固定。

依照慣例，我還是仔細地思考了一下話中的含意。

根據自己的經驗推論，建築工程是三度空間的設計，但是軟體設計就像是四度空間的思考。像建設高速公路時只要在必要的通道上設收費站就一定收得到過路費，但是軟體即使規定好設計的層次，但任誰都可以修改為完全不經過那一個點而進入；汽車的動力從引擎經過傳動軸再傳到輪胎，但是在程式定義上直接讓動力直接轉動輪胎也是可行的作法；還有就是蓋房子時九樓往上一層一定是十樓，但是在軟體裡卻可以跳躍到任何一層，完全不受空間限制。

就製作的成本考量，一般工程需要零件時因為自己開模製作很慢於是會開好規格訂購現成零件，但是軟體元件卻因程式修改快速且成本不大，所以就在該要的地方直接作出可以應付的結果，全然不去考慮日後重用的兼容問題，反正複製一個後再改程式微調差異即可。

只注重結果的思維造成跳躍式的使用、零成本的修改（指非人力的）造成隨意的改變，雖然執行的結果相同，卻使得產出的程式碼有難以統一的多變風格、修改時也不易找出問題的真正原因。也由於同樣的需求會觸發各種不同的想法與設計，我們又無法像一般工程那樣證明哪個作法是最好的而規定下來，更增加了產出的不確定因素。

邏輯上只要檢查不出錯誤就可以說是對的。在沒法證明哪一種作法具有全部好處時，大家只能針對自己著重的方向使用自己覺得好處最多的方法。然而在對應種類眾多的時刻，選擇作法時比照一般工程嚴謹地讓每個零件限定只能接續特定的零件，是否就能適用一般工程的作法呢？

W06 做事的方法(16)──對小朋友所說的做事接物摘要

2009-06-06T00:00:00.001+08:00

●使用一個物時一定會有一個連帶的動詞，該動詞稱之為一件事。
　例如：拿剪刀、穿鞋子、背書包等。
●物要固定放在一個地方，需要的時候只要找一個地方；如果平時物隨意亂放，需要的時候就得找很多地方，而且不一定找得到。
●每一件事都有一系列的動作要做，而且要依照一定的順序。
　例如：用剪刀時要將拇指與食指伸入剪刀的圈圈、把要剪的東西放在另一側的兩個剪片之間、拇指與食指用力夾起。
●直接使用一個物的事稱之為小事，包含數個小事的事稱為大事。
　例如：整理書桌是大事，因為包括了整理小書架、桌面、抽屜與桌下等四件小事。
●指派一件事時要有能力把它拆解為小一點的事，並各自一直循環到最小的事為止。
　例如：要你整理房間時，意思是要你整理書桌、整理書櫃、整理衣櫥與清掃地面。
●指派給你的大事拆解的定義要跟我想的一樣；當然，會先告訴你定義的範圍是什麼。
　例如：要你整理房間時，不要只整理好書桌就回報說已經做好了。
●做事的範圍要看實際的物有些什麼而加以變動。
　例如：現在的書桌上有小書架，如果換了一個沒有小書架的新書桌，整理書桌時就不用整理小書架。
●要能判斷自己應該做的事是否需要立即動手去做。
　例如：感覺書桌有點亂時，不需要人講就應該自己收拾；睡前與出門前檢查應帶的東西是否都已放入書包。

生活上接觸得到的事物很多，要一件件都在適當的時機做而且要做得好，實在是不容易的事；大人都已經是如此，更何況心性未定的小朋友。整理出做事與接物的原則雖然可以比較明白其原理，但是對真正要做事的細節並沒有很大的幫助，因為會忘的還是會忘、不做的終究不做。理論與實作，不就是像這樣的對照嗎？

W05 三看簡單型Component

2009-06-05T00:00:00.001+08:00

運用人、事、物的想法再回頭來檢視簡單型Component。如果直接可以操作物的只有最小的事，那麼先將之定義為Action，其他無法直接操作到物的事則是不同層級的Flow；這麼一來除了最底層的動作要包裝為功能元件之外，其他各層級的流程應該都只是流程元件？！

這樣的切割法又讓我對元件的結構有了不同想法。依這裡的思緒我應該包裝出只有Action的功能元件，使用Action的流程再另外包裝出流程元件；不過在特定需求的系統裡我也可以產出一個包裝不同流程元件與功能元件的複合式元件，依參數調整內部使用的流程元件；流程元件操作功能元件時，也可以依設定更換不同實作的功能元件。這樣的作法將可以提供更靈活、更多樣化的組裝。

程式解析工具在元件分離的情況下依然可以運作：流程元件只需要處理流程方法是原本就要做的，動作方法不需要做所以不存在也沒關係；但是功能元件內部就需要再拆解出與執行流程相關的方法，標示給工具去解析。不過基本上並沒有很大的影響。（唯有元件產生工具需要調整）

註：人、事、物的關聯一開始只是為了對小朋友講解做人做事的基本原則所整理出來的想法，卻沒料到完全適用在元件結構的應用，這是原本始料未及的。

W04 我的設計準則(6)──追溯關聯

2009-06-04T00:00:00.001+08:00

所有的單位在操作或使用的同時就發生了關聯。無論是一對一、一對多、多對一或是多對多，關聯都是追蹤影響的最重要依據；唯有透過關聯的追蹤才能發現某個單位的變動範圍到底有多廣泛。

收集範圍與追溯關聯是在求快速開發的同時最易忽略不做的工作。由於程式碼經常變動造成使用關聯頻繁變化，使得修改追溯表的速度根本追不上變動的頻率，長久下來完全沒有人可以追蹤出任一個底層API修改之後向上隔了數個層次的Use Case到底有哪些會被影響。縱使現在的IDE工具可以查出全部的呼叫歷程，但是在出版本前的迴歸測試要如何取得幾十個變更的影響範圍？

無論人對事、事對物、地對事、時對人與事或是事與事之間的全部關聯都應該要記錄下來，不管是做事的SOP或是程式的呼叫也都有使用的關聯，如何快速列出能夠操作目標單位的全部集合雖然不易，卻是在某些狀況下必須得到的結果。程式碼中快速且正確地列出使用集合，正是我要定義程式結構的主要目的。

針對UML裡的Use Case我實測了三種UML軟體：Rose 7.0.0.0、JUDE Community 5.5與Star UML 5.0.2.1570，測試範圍是Actor與Use Case的關聯、Activity與Activity的關聯。Rose明確地標示出三種圖示與兩種關聯；JUDE連Activity都沒被視為保存的單位（這表示activity無法分析是否重用），更不用提關聯；Star UML標示出三種圖示，也在各圖示內管理自己的關聯。

忽略多個Use Case之間的使用關係時，雖然對於單一Use Case可以快速開發，但是就沒法作出最佳化的分析與設計（如果向下的層次也不追蹤使用關係的話）。使用關聯的雜亂是專案產出的品質難以控管的重要因素之一，卻是被許多人所忽略的。

W03 我的設計準則(5)──收集範圍

2009-06-03T00:00:00.000+08:00

分析設計時的人、事、時、地、物都需要各自收集範圍以便定義各自的邊界，收集的好處在於接觸到某一個單位的同時能夠立即知道它是否在該單位的集合，已存在的話可以直接重用，不存在的話就必須另外建立。這個方式對於reuse的幫助很大。

收集起來的單位數會非常多，因而需要建立各自的分類方法依特性分群組放置，這樣可以加快定位的速度；當然加上搜尋的功能也很好。在＂事＂的分類佈置可以衍伸為Package的定義，搭配Component工具就能夠將所有新＂事＂的定義直接匯出元件程式結構，舊＂事＂則依設定參考原有的元件功能。

觀察到很多SA、SD與PG的想法都偏向輸入與輸出，在意得到什麼樣的輸入且應有什麼樣的輸出而忽略了處理輸入輸出的做事流程。在明確定義做事流程的方式下可以得到處理的SOP，進而與其他做事流程共同抽取相同的部分成為API；忽略做事流程的作法下任何想法都以湊出對的結果為目標，雖然效率很好，但是僵化、綑綁與難修改都會跟隨其中。

這是可以套用在任何地方的想法。分析時一個群組（例如會計室）收集的應做之事就是該群組的功能，一個單位（例如出納）收集的應做之事就是這個單位的責任；每一個群組與每一個單位都依其特性給予它應有的責任範圍，並要求該責任只有這個單位具有而其他單位都不得處理。

每個部份要先依其大小意義定出有多少層次，在收集範圍的同時都要依層級分開收集在不同的層次，唯有將所有單位都分門別類地放置的一致化作法才能夠再定義出更上一層的存取規則。這也正是各種工具程式的操作依據。

W02 Use Case裡的人、事、時、地、物

2009-06-02T00:00:00.001+08:00

＂人＂必須透過＂事＂才能操作＂物＂是分析與設計的根本，某個物被改變＂必然＂是因為某個人做了某件事，確定了這個關係後就可以很容易地接受Actor、Use Case與Data的說法。再加上該件事發生的時機與執行的地方，就構成了人、事、時、地、物的思考模式。

在系統裡通常會用角色來取代Actor，當某個角色發動做某件事時，權限控管會根據角色與功能的關係決定是否允許。功能被執行後會進行一連串的動作，執行動作的流程會被編輯為Activity Diagram，而被執行的動作就是Activity。

事件可以區分為一次操作一物的＂小事＂與一次包括許多小事的＂大事＂。舉例來說，整理書房是一件很大的事，至少包含整理書桌、整理書櫃、清掃地面幾件較小的事；整理書桌又包含整理書架、整理桌面與整理抽屜三件明確的小事，每件小事都關聯到一個物件。切割範圍的思維一致後，每個人對事物切割範圍的誤差才不致大大。

單位切割之後要處理的是每個單位的分類方式，如何訂定各種存放類別、單位存放時如何分類也是必須同步的想法；另外單位之間原有存在的關聯都是必須保存下來的資訊。

W01 公司應有的文化──所有人員的想法與行為一致

2009-06-01T00:00:00.001+08:00

公司的CMMI導入團隊說現在訂立的規範都只強調精神，各專案要根據自己的特性予以調適；由於沒有提供一個基本的範本，造成每個專案各做各的沒有交集，等於是沒有規範。也由於各個專案作法與產出不同，卻擁有相似的問題──沒人看得懂，修改沒品質，無人想維護。

敏捷開發的原則非常強調開發成員間的想法同步。2006年開發UI編輯器時小組裡有四個人，我們每天上午十一點與下午五點都各開半小時內的會議，內容為核對進度、提出問題與回饋作法；目的是讓所有人都對不熟的技術與平台獲得同樣的了解，當時我覺得效果相當好。可是當時的主管有天卻問我這句話：你們一天到晚常常開會，這樣進度來得及嗎？

一間較大公司內會有數個專案，一個較大的專案下會有數個小組，把眼光提升到公司的層級就會有一個疑問：要怎麼做才能讓公司內所有專案、所有小組、所有角色產出的內容與品質接近一致？採用CMMI的流程控管會有許多繁瑣的手續耗費開發的時間，使用快速的方法可以讓開發迅速卻讓其他人難以瞭解系統。

無論是人為的控制或是自由的開發都有可能因為每個人的思考方式不同而導致結果有差異。要能同步所有人的思維，應從瞭解設計的本質開始，再搭配每一個階段、每一個步驟為什麼要這樣做，這樣做有什麼樣的好處與壞處著手。讓所有人打從心裡相信雖然自己多花一點時間，卻能夠留下足夠資訊達成各個面向的要求。

做事方法與思考原則的完全一致化，會訓練出有紀律的團隊，同時會有讓所有成員一看就懂的產出。

V22 程式碼註解解析工具的後續連結

2009-05-29T00:00:00.002+08:00

這張是程式碼與相關文件經過程式碼解析工具處理後預想的關係圖，在理想的作法之下應該滿足全部相關部分的需要。簡單的說明如下：

●UML工具：從UML工具內讀取有用的資訊加以轉換到其他產出，或是從程式碼裡取得必要的資訊放到UML工具裡。除了程式碼與Model之間原有generate code與reverse之外，可以再擴充其他元素的雙向存取。

●各種文件：主要是要產出符合CMMI需要的設計規格書與追溯表，必要時也可以有流程圖。如果專案上有其他的需要，也能夠另外再設計不同的產出。一般會匯出的文件格式會是word、excel與pdf。

●元件庫：專案中適合reuse的功能元件要有納入元件庫的機制，屆時需要產出軟體元件的規格；專案在使用軟體元件時可以再匯入之前產出的元件文件作進一步的分析與追溯。

●問題單系統：搜尋特定的修改註解取得修改的程式與說明，自動填寫到問題單系統內同一單號的說明。這需要問題單系統提供API或是直接修改其資料檔內容。

●版本資訊：搜尋指定時間範圍的修改註解取得修改的範圍與問題原因（搭配問題單系統取得），以及受到影響的所有方法作為參考資訊。

●知識庫：搜尋指定時間範圍的修改註解取得修改說明，列出作為是否進入知識庫的備選。知識庫管理人員可以取得知識備選清單並與現有的知識庫內容作比對，以決定要不要放入知識庫並加上補充說明。這需要知識庫系統提供API或是直接修改其資料檔內容。

●系統測試：參考判斷條件、使用關聯與流程圖來決定如何編排測試個案，以涵蓋每一種條件變化的流程為目標。

V21 敏捷開發原則與CMMI精神的共存

2009-05-28T00:00:00.000+08:00

閒暇時偶而會與同事或管理階層的人談起開發時程與彈性設計的問題，也會上網搜尋一下目前其他人對於設計的看法（中文網頁裡的）。得到的大致說法都是敏捷開發的原則是以快速滿足需求與變化為目標，而CMMI的精神會以檢驗各個步驟的產出來確認軟體製程的各個階段；前者認為軟體設計是多變的心智活動，後者則相信軟體可以像產品一樣由工廠來開發組裝。

某天與其他部門主管聊起時，談到OOAD設計與這兩者的關係，我強調說設計的物件能否完整地一對一對應到真實的物件才是最重要的關鍵。今天一個有三層結構關係的物件在設計的時候被縮減為一層，無論用什麼樣的方法論作出來的程式都會在需要切割時出問題的一天；反過來說只要物件結構能正確對應，無論用什麼樣的方式開發都不會出現切割的問題。

乍看起來敏捷開發與CMMI是沒有交集的，快速開發可能造成佈置的雜亂（所以需要重構來調整），設計的完整會耗費許多時間製作文件，因此幾乎所有人都不認為它們可以相輔相成。經過這兩年的思索，我認為唯有使用＂固定且具有彈性的統一軟體結構＂才能滿足快速與完整的並存，同時再夾帶讓全部開發人員（不限同一個開發團隊）能快速明白設計概念的好處。

將軟體切割為靜態結構佈置與動態方法設計，作好完整的靜態結構佈置後以敏捷開發的原則進行動態方法設計，通過各個階段測試之後再運用工具程式解析以產生CMMI需要的文件。這些想法的關鍵都已經在這兩年陸續在實際工作裡加以驗證，有絕對的把握可以實現。

雖然要事先開發好所有的工具的確需要不少時間，不過在下一章會先說明專案開發時大致的流程、作法與需要的工具，並且構築出一個完整的開發roadmap。

V20 修改的追溯(3)──系統追溯總表與關聯搜尋工具

2009-05-27T00:00:00.000+08:00

在系統要出一個新的版本時，輸入上次出版日期與這次出版日期，修改註解收集工具應該要能收集到程式碼內的所有修改記錄，進而輸出在Use Case層面的追溯總表。這份表格可以作為迴歸測試的參考標準。在理論上還可以更進一步作出每一個修改所影響的是呼叫它的方法裡哪一個判斷條件，這將是最為精確的結果。

應該追溯的當然不只是系統的Use Case，呼叫的歷程中每一個部分都應該要能夠被定義出來，這樣才能夠對中間的所有元件重作單元測試。如果有作好Unit Test的話只要知道元件後自動重作全部測試觀察是否有錯誤，然而有時還是得知道到底是哪裡被影響到。目前的IDE工具可以直接看到呼叫指定方法的全部關聯，卻仍無法向下呼叫的關係。

我的想法是製作一個工具，先分析出系統元件間的使用關聯。使用者在系統元件樹狀圖裡選擇指定的數個方法（或從產出的修改彙總表匯入）後，就直接在向上區與向下區用樹狀結構的方式表示各個相關的呼叫結構。其間也可以用滑鼠點選擇集合裡的任一個方法限制只顯示與之有關的。最後還可以匯出找到的關聯集合作為參考或正式記錄。

V19 修改的追溯(2)──時間與空間交集的修改集合

2009-05-26T00:00:00.000+08:00

對系統來說雖然切割的單位是Package，但是在意義上應追溯到Method才是最精確的。然而一般的作法光是追溯Class都已經很難正確，更何況是要到Method。一個略具規模的完整Class-Class的追溯表大概可以到1000 X 1000的矩陣，到Method更不用談了；不過追溯並不是一次要看全部內容，而且侷限於需要看的部分。

需要看的追溯通常有兩種：從上往下的追溯與從下往上的追溯。想要從功能面上取出一個獨立的模組或功能時同時需要哪些物件，可用自上往下的使用關聯取得完全的集合；想要從中間一個方法得知在這個系統裡，總共有哪些地方的方法直接或間接呼叫到它，就是從下往上的追溯。理想的追溯是指定一個方法之後同時追查出所有向下與向上的全部關聯。

對於修改歷程的集合，除了要可以定義變動程式碼的範圍之外還要可以調整時間的範圍，這樣才能夠定義時間（像版本之間的時間）進而找出變更的空間（異動程式與向上追溯）。在任意變換的定義時間帶與定義的Project裡找出變更與影響集合用人工是很難作好的，無法正確地定義影響的範圍正是為什麼造成品質不佳的原因。

把這個很花時間的功能自動化後，任何時候都可以查出當時有哪些修改；唯一要多作的只是多註記問題單的編號註解。

V18 修改的追溯(1)──修改處的註解與收集程式

2009-05-25T00:00:00.000+08:00

一個系統上的問題通常會在問題單系統裡建立一張問題單並給予一個編號，程式人員會針對解決這個問題而修改一些程式碼。以往的作法是填寫一份問題報告，描述問題的產出與解法，並記錄改了哪些程式；程式部分也另外填寫到一份release notes等到要上新的版本時，可以知道共有哪些程式需要更換。

版本-問題單-修改的程式是除錯與維護時物件的關聯，其中最基本的是問題單與修改程式間的關係。假設有一張問題單單號1234的錯誤在於初始值給錯，那麼就用根據本章前面所提的註解原則來修改程式並填寫註解。
　　/*
　　 * 記錄索引的變數給予初值.
　　 */
　　// index = -1; /* IR=1234 */
　　index = 0; /* IR=1234 */

原則固定之後，註解處理工具就需要多設計一個程式來收集這些資訊。從最底層起要做的事有：
●每個Method裡為了每張問題單所修改的全部程式碼。
●每個Method內處理過的問題單集合。（回填到Method註解）
●每個Class內處理過的問題單集合。（回填到Class註解）
●每個Component內處理過的問題單集合。（回填到Component Interface註解）
●每個Package、Project直到workspace內處理過的問題單集合。（回填到對應的註解說明）

確認每個階層可以收集到所有填寫的修改註解，同時更新到Method、Class的註解裡是這個階段所要達成的目標。

V17 Sequence Diagram──一次只能表達一種呼叫順序的圖表

2009-05-22T00:00:00.000+08:00

雖然Sequence Diagram是UML的一種標準圖，但是由於它只能表示在某種情況（通常是導向正確結果的流程）下的物件互動順序，沒有辦法表示分歧點判斷後的差異，因此我並不喜歡使用這張圖而寧願用Activity Diagram或流程圖來完整地表達。

有位曾共事的同事在討論時喜歡用Sequence Diagram表達物件的關係，無可否認地依序表達物件的合作關係時是非常清楚的，轉換為Collaboration Diagram時也可以立即知道達成功能時所需物件的關聯，然而無法立即由一張圖就知道整個功能的處理流程是十分不便的。

在不想繪製這張圖時，許多IDE工具提供在執行同時產生Sequence Diagram的功能。在IBM RSA 7.0（含）之前的版本是從頭到尾的呼叫流程都擠在一張圖而無法分割，這樣的圖表更是難以看懂其中的設計。不過這麼鉅細靡遺的圖表放到CMMI的設計規格書裡倒是挺適合的──反正許多規格書都只需要填滿指定的章節就好，並沒有人要求內容的正確性與適當性。

我認為Sequence Diagram如果增加branch node與merge node的定義後就會非常理想，但若是在分析設計Method的同時，把每個Activity都一對一對應到一個呼叫的Method的話，Activity Diagram就等同於Sequence Diagram的意義而不需要再重覆製作。而且這張圖表可以藉由程式流程Data Model自動產生出符合該Method層級的流程圖，比較起來反而可以省下更多製作圖表的時間。（若應用swinlane區隔出每一個不同activity所存在的物件，同樣也能夠產生Collaboration Diagram）

對於這種區解原意的應用，應該會有理論擁護者發出不平的聲音。理論難以應用時應該修改理論使之符合實用，而非堅持大師的想法造成無法進行的瓶頸。

V16 流程的存取(3)──從程式流程Data Model產出流程圖

2009-05-21T00:00:00.000+08:00

一個Component Interface Method的實作會產生一組對應的程式流程Data Model，這個集合的內容應該產生一張對應的流程圖。同一個Component的流程圖要收集在一起，因為那是元件內部的完整流程說明文件。

處理的過程其實不難，依下面的順序進行：（依集合內程式流程Data Model的順序）
●逐一在流程圖上建立對應的節點，並標示節點名稱。
●根據程式流程Data Model內的關聯定義建立節點間的關聯，並標示關聯資訊。
●自動排版所有節點。
●自動命名與存檔。

困難的其實在於工具的配合，在2009/04看過幾套UML工具只有JUDE/Professional有支援API存取物件（US$ 280，但不知是否支援繪圖），其他像Rational Rose、StartUML、JUDE/Community都只能在產生報表時選取輸出的物件而沒有提供操作的API；即使是Microsoft Visio也只有data link API而沒有提供圖表的。

目前的潮流是先畫流程圖再產生程式，如果找不到用程式產生流程圖的免費工具，未來在實作這個功能時真的得另外製作一個用API畫流程圖的工具了。

V15 流程的存取(2)──Flow與Action方法的處理原則

2009-05-20T00:00:00.000+08:00

處理的範圍限定在Component內部。首先要將Component內部的Implementation與Flow兩類方法收集起來，這是流程進行的範圍；Action方法原則上不用處理。倘使Action方法也有製作流程的需要，則把被Flow呼叫的Action視為範圍再進行Action方法的流程分析。

一開始要定義一個迴圈逐一處理每一個Component Interface Method，先進入Implementation方法再依程式流程進行，每遇一個定義上的node就產生一個對應節點收集資訊。在流程上，只要是Implementation與Flow方法的就必須進入該方法處理；在動作上，如果呼叫了Action方法或是其他Package的方法則註解為一個activity node而不要進入該方法。不應該遞迴處理到其他Package的內容，因為那會使得流程記錄得太細而失焦，難以看出現在層級應該注意的過程。

某Flow方法在內部呼叫同Component的另一個Flow方法時，該建立一個中間點將兩個Flow分成兩張圖來存放？或是不管呼叫的間隙而將全部的流程串成一張圖呢？這應該選擇後者。一個Component Interface Method的實作是一組獨立流程，部分流程會被抽成另一個Flow方法是因為它們在意義屬於某一特定目的，但仍是原來流程的一部分，因此串成一張完整的圖會比較易讀；況且圖是自動產生的，也不會太大張。

一個Component處理後再接著換另外一個，直到指定範圍內所有的Component都被處理完為止，這樣我們就拿到了所有Component Interface Method的程式流程Data Model。這時要設計一個中間檔的存放機制讓這些程式流程Data Model存成檔案，日後要轉換時再讀入處理而不需要每次都重新處理。

V14 流程的存取(1)──程式流程Data Model

2009-05-19T00:00:00.001+08:00

接下來討論的是程式流程圖的產生。由於繪製流程圖的工具非常地多樣化，所以不應該直接把程式流程輸出為流程圖，而應該先設計程式流程Data Model先將程式碼的流程轉入，然後再根據實際使用的流程圖工具製作匯出程式。

一開始應該先分析流程圖裡面所包含的元件種類以建立對應的物件。我參考的是Activity Diagram內使用的圖形，能夠用最簡單地圖形表達出設計的意義可以降低複雜度。
●start node - Flow方法的進入點
●end node - 遇到return或是走到Flow方法的盡頭
●branch node - 每個判斷條件會對應到一或多個
●merge node - 每個判斷條件block的終點
●activity node - 不在判斷條件裡的動作

Flow方法裡只有變數宣告（activity node）、執行Method（activity node）與判斷條件（branch node、merge node）等三類敍述，判斷條件內除了java的關鍵字外就只有判斷式（branch node、merge node裡的condition），因此Flow方法的敍述在理論上都能夠對應轉換為程式流程Data Model。

每一個程式流程Data Model都還要包含指向下一個node的指標（end node）沒有，branch node得有分歧條件與對應節點的集合才能建立正確的資訊。在非分歧條件下的程式碼毌須解析內容，只要把找到的註解都轉換成一個activity node即可。

V13 自動補齊註解(8)──匯入底層元件的註解產出

2009-05-18T00:00:00.000+08:00

在workspace裡的程式碼都可以使用工具達到上述的註解產出，但是在使用軟體元件的同時，要是那些Jar File有改變的時候該怎麼辦？要怎麼找出系統被那些影響變動的範圍呢？很抱歉，截至目前為此沒有辦法──除非再設計一個功能。

想像把一組很多層次的Package從中切分為二，上面放在workspace裡而下面是Jar File，差異就在於沒辦法取到下面的註解加以分析並放入集合。那麼取代的方案就是：擁有元件程式碼的人應該先分析註解並產出結果，專案就在工具裡匯入產出結果成為註解集合再繼續處理，這樣就可以解決這個問題。（匯入不能只限一組，要能同時匯入多組資料）

匯出與匯入都應該以上述所有註解分析結果為範圍，感覺就像真的剛處理出來的結果一樣才不會有落差。在優先度來說，專案的改變要比元件的改變容易發生，所以這個功能的需要就沒那麼急迫。

直到這裡，才算完成所有與註解相關的自動化部分。

V12 自動補齊註解(7)──產生Interface Method的使用追溯表

2009-05-15T00:00:00.000+08:00

每個Package的使用關聯集合如果都建立起來，除了可以快速地向下找到有關係的Package之外，還能夠搜尋到所有向上的被呼叫關係。如果有耐心作完全部的設計，追溯甚至還可以精確到Interface Method的程度。

公司定義的CMMI文件裡追溯表格只有三種：Use Case-User Case（水平）、Use Case-Class（垂直）、Class-Class（水平），這對於實際的系統設計來說是沒有對應且涵蓋度不足的。在我看來至少要有這些追溯表格：Use Case-Use Case（水平）、Use Case-Package（垂直）、Package-Package（水平）、Package-Class（垂直）、Class-Class（水平）。

仔細分析的話，可以發現追溯的根本是依層級來記錄使用關聯，Package-Class、Class-Class收集的是Component內部的使用關聯；Package-Package則必須收集每一個Component之間的使用關聯加以記錄；Use Case-Use Case、Use Case-Package這兩張表格在意義上也等同於Package-Package的作法（Use Case的入口方法都被收集在特定Package下）。

最完美的使用追溯表應該記錄到Method間的呼叫，但是攤開來看的話可能會大得太離譜。為了因應實際會需要尋找指定某個Method後列出呼叫它以及它所呼叫的所有關聯，勢必需要再設計一個查詢工具，指定一些Method後列出上下的全部使用關聯。唯有這麼作才能精確地圈選出修改後所有的影響範圍。

V11 自動補齊註解(6)──依階層收集Method註解

2009-05-14T00:00:00.000+08:00

Method是底層的行為單位，再往上的組織階層有Class、Package。既然Package擁有多個Class，而Class又擁有多個Method，那麼在集合的層級上匯總集合元素的資訊也是應該具備的功能。

回顧前面的章節所做的事，在彙總註解內容時首先要作到的是格式檢查與基本資訊的產生，第二是宣告時繼承與實作對象的註解（Class），第三是全部的使用關聯與判斷條件（註明在哪裡用到），最後則是修改的目的與記錄。處理的流程就定義迴圈，然後依序收集全部應該要收集的註解。

收集所有的Method註解後的內容很多，Class的註解可能會變為上百行之多而難以閱讀，Package層級則會面臨到沒有可放置單一註解的地方。因此建議Class的基本資訊、宣告內容與修改歷程放在Class的註解裡，使用關聯與判斷條件則另外產生外部檔存放（這部分也可在需要用到時再產生）；Package則收集修改歷程、使用關聯與判斷條件另外存到外部檔案。

Package的資訊只需要收集屬於自己內部的資訊，不需要遞迴向上彙總。每個Package都整理好本身的資訊後，在Component、Module等級的Package就可以遞迴向下收集使用關聯，知道到底使用哪些Package後就清楚重用這個Package時還需要連帶哪些Package。修改記錄的收集用途亦是讓我們可以立即知道該Package下全部的變動。

收集全部Package使用關聯的過程中，還能夠建立使用Package間的垂直與水平追溯表。