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

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