G06 程式設計的能力(1)──能夠拆解動作

系統被拆解為功能，功能拆解出步驟，步驟中決定做的動作，每個步驟與功能都預先想好可能會發生的例外狀況，並決定好萬一發生了該怎麼處理。雖然會有資深的人幫我們準備好所有的資料，但是這卻是我們應該培養出來的能力。

上級交待一件事情，在確定目的後就應該要去分析這個目的可以拆解為哪些相關卻不重複的工作項目；工作項目確定後，要再去想可以分解為哪些獨立的工作步驟，而且該做些什麼且跟哪些人有關。這樣的能力在生活裡隨處可見，程式設計的原理也剛好不謀而合。

同樣的概念也發生在希望在程式裡達成一個目的時使用。想要做到的功能要去思考要由哪些動作來完成，那些動作各由什麼元件提供或是要另外做，能夠乾淨清楚地切出正確的動作並找到該負責的單位，是做所有事情所必須具有的第一種能力。

G05 做事的方法(9)──寫日記的方式

高二時曾寫過一本日記，那時的想法是忠實地記錄下每天生活的過程，也就是記流水帳。絕大部分對於寫日記的建議都說不要記成流水帳，要選擇特別的事情記下來，可是一直沒法理解為什麼要這樣。

開發與銀行相關的系統時，客戶很重視電子日誌的功能，這個功能可以記錄下所有使用者在系統上所執行過的任何功能與內容。由於銀行系統都跟錢有關係，所以需要這個機制在有狀況發生時可以追蹤到在什麼時間誰執行過什麼功能。這感覺上就像是在記系統的流水帳。

開發系統時，我們會記錄與系統有關的資訊與想法，因為這些東西在經過分析與規畫後，會使用想法更為融合與精簡，去蕪存菁後留下與系統開發有關的部份，藉此讓系統慢慢地成形並進而成功。我們並不會特別去記什麼文件在什麼時間點產出，因為內容會隨著時間再慢慢修訂，重要的是裡面所記下的想法。

可以發現前者只是一種記錄，便於在特殊要求時去找出相關的一系統事件；後者則是記下與成長有關的所有資訊，讓未來可以引證參考而能夠有更成熟的想法。兩種記錄的內容與方式恰巧對映在寫日記的類型。如果要的是在未來知道以前曾發生過的所有事情，適用第一種記錄法；如果要的是留下能打動心靈的瞬間，那就使用第二種記錄法，才更有機會反省並成長。

G04 驗收的文件(1)──需求階段相關文件

客戶對於想要做出來的系統，通常會有幾個大方向的資訊：

１、系統應用的範圍。提到的是系統的設計將會是應付什麼領域裡的功能所存在，這裡會提到很多使用者商業領域的相關知識。（Domain Knowledge）這裡的資料在設計時要產生系統詞彙表，並進而產生系統可以處理的Data Model。

２、系統處理的功能。提到的是系統將讓使用者可以做且要怎麼做哪些功能，每個功能的目的與進行的流程應被分析出來並明確記錄到需求規格書裡。所有需求都應被明確地定義出來並有清楚的流程後才開始設計。

３、對系統整體的要求與硬體配置。前者的清單會記錄著與功能的配合關係，並與硬體配置同時在作架構設計時視為最重要的參考資訊。有時客戶不是很明白這些資訊，在訪談時如有不清楚的地方要建議幾個方案給客戶選擇，客戶的決策就是系統確定要做的架構。

G03 文件是必要之惡？

開發系統的人幾乎都覺得寫文件是很痛苦的事，但是一些理論與公司規定卻又要求非寫出哪些文件不可，只好心不甘情不願的花時間敷衍了事。以前的我也抱著同樣的心態，但是在領悟應把心裡的想法留下記錄的道理後，就變得十分支持依系統開發的各個階段產出應有的文件。

設計人員通常會把瞭解需求之後的構思直接轉換為實作的程式碼，這對寫作的人來說是自然不過的事；系統的需求、需求如何轉實作、實作時的邏輯、物件的對應與使用等等很多的細節都是在他腦海裡的產物，當你拿到的只是開始的需求資料與結果的程式碼，要多少時間才能找出其間的演變關係？

順向依各個階段把心裡想法記錄下來是我現今堅持的理念，即使專案沒有足夠的時間，我也會依循文章裡提到的原則簡短地記錄。當文件成為想法一步步實現時的腳印後，就不需要做完系統才寫回憶錄而且寫了還完全沒用的痛苦，因為裡面寫的都是形成系統的重要概念與想法。

接下來就依系統各個階段的演進來看看應該會產生出什麼樣的文件與其代表的意義。

G02 建立系統標準安裝內容

程式開發完成並通過層層的測試後，那表示系統即將要可以驗收囉。但在驗收前最後的考驗，是把系統安裝到正式的環境裡作最後的線上測試；這也就是說，我們必須把所有開發出來的結晶作包裝的動作，以便客戶安裝到他們的電腦裡執行。

首先要知道的是每一部電腦對應的角色應該安裝哪些必須軟體，接著要知道各個電腦角色需要哪些建置好的程式檔案。另外，不管是系統的功能或是元件的使用，如果牽涉到其他公司的公用程式，除了在設計階段要註明使用的關聯之外，在準備佈署的時候必須參考使用關聯先行放置那些必須的檔案。

在基本佈署建立之後，再依層次向上決定每一個硬體所需的執行函式庫，還有系統執行檔，如此一來，每個硬體一層一層讓有哪些東西都可以決定。這樣的記錄將會延伸定義為執行硬體需求、軟體需求與安裝手冊，未來所有電腦的採購與安裝都需依照文件的內容進行。

G01 建立系統標準出版方法

針對系統開發的所有程式碼，在建立的同時應參考應用的場所與範圍來決定所屬的Package與Project，並依此來決定程式檔案的佈署配置。

Package通常會以功能的特性加以封裝，Class少的時候全部放置在同一層，多的時候再依用途再劃分Package放置，但嚴格來說會視作一個Component。把功能類似的Component放置到同樣的Project裡，並將Project的內容匯出成一個執行函式庫，同時依Component的使用關聯記錄Project的使用關係。

依據使用者需求設計的系統所寫的程式，同樣也依功能性分Package來存放，再將相同層次的程式依硬體配置擺放在不同的Project裡，每個Project再匯出系統程式檔。在不同的硬體上配置系統程式檔加上執行函式庫，就是使用者真正在使用的系統。

從原始程式建置系統檔案時，可以使用像ant之類的佈署工具，撰寫描述檔讓程式自動建立所有必須的程式檔案。

F26 系統應該被測試，想法應該被Review

系統應該被測試，然後除錯，以期望它能正常的運行
想法應該被review，然後修訂，以期望它能順利地實用

由於與同事討論程式設計的想法時，大多流落到局部面的思考，所以原本想藉這個Blog記錄對於開發系統時要有的全部想法，作為日後討論的依據。開始的時候試著用處理事情的思維加上軟體工程的角度寫短篇的文章，卻在不斷地思索之後慢慢發掘到更多要素的思維與影響。

雖然已儘量用主題表達方向，並使用簡短的文字帶出我的想法，不過我感覺只寫出心裡想法的四分之三左右；而更重要的是，雖然我覺得自己的想法說得通，但是不知實際上有沒有問題。於是幾天前在Java World @ TW論壇公開部落格的網址，讓自己的想法來接受檢驗並加以調整。不過一個沒考過SCJP認證又沒看過幾本書的人所說的話，理論上是不會有人進來多看的。

至今遇到過的人都還停留在“用程式做功能”的層面上，希望有那麼一天可以跟幾個理念接近的人共事，討論出實現軟體工廠的可行方式，並進而先“用程式做工具”讓很懂商業邏輯卻不大懂寫程式的人“用工具做功能”。等到那麼一天我們就可以有很強的競爭力了。

F25 客戶會在意系統開發的哪些方面？

在工作上一直都是廠商的角色，以公司的作法來滿足客戶的需求。用我現在的標準來衡量，如果我今天是需要採購一套電腦系統的客戶，我將會以下面幾項為出發點來審視：

首先是功能部分。系統最低限度是要滿足需求，除了由客戶提供功能清單之外，我將會檢視廠商如何記錄與控管所有的功能與流程的描述；尤其是需求規格書的內容。要是我可以決定測試標的內容，我一定會加上幾份重要功能的規格書審核。

接著是設計部分。我會檢查系統架構設計書上是否完整註明所有硬體與所用的技術？決策的過程是否有被記錄？當然設計規格書會是重頭戲，不過我著重的將會是Controller與Action的層次是否分明，另外看元件的層次是否整齊，系統的訊息是否獨立，功能上要求可以置換的地方是否採用夠彈性的設計。

測試將會是最看重的部分。測試的範圍必須與功能的設計相互呼應，藉此來保證所有功能都被完整測試；另外測試的時程與報告也是一定會看的重點。最後則是文件的內容是否切確地描述系統的安裝與如何使用所有的功能。

其實我覺得重點是在系統開始的時候，客戶就要用心投入系統的規劃，如此才能夠隨時隨地掌握住系統的狀況的內容。

F24 做事的方法(8)──做前三思，做後反省

生活裡總會遇到許許多多要作決策的事，之前提過做事要有目的與達成的步驟，但是在做之前還有個重要的決策：到底該不該做這件事？

在心裡快速地作沙盤推演可以是個有效的方法，把每個決定與作法都在心裡思考一下，整理出每個決策的優劣與影響並加以比較，如此將最有機會選擇到最好的決定。很快地作決定並不見得是好事，古人要我們三思而後行就是希望我們先確認再作最好的決策。

在學生時代寫考卷時，師長總會要求我們寫完要檢查；現在要問的是，要怎麼檢查才符合之前所提到的測試概念呢？每一個題目是需要寫答案的最小物件，所以在寫每一題的答案前應該先在心裡檢查一下對錯，這是Unit Test；每一個大題包含了該類型的所有題目，不過每一題間並沒有關係存在，這一層倒可以省略不用檢查；整張考卷會被批改並標註分數，於是把考卷視為系統再作一次檢查也是合理的要求。

做事前養成先想一下再做的習慣，一定會比先做下去再觀察反應的方式好上許多。這是在從事任何決定之前應該要有的習性。