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條說明全部看過一遍，最後定義出屬於自己的檢查規則範本。

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