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%的缺點，就是想要證明自己提出的比較好，對於應該解決的問題卻沒有幫助。

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

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