前幾天在 developerWorks 看到一篇關於負載測試的新文章，《让开发自动化: 自动负载测试 - 使用 Apache Ant 和 Apache JMeter 频繁进行负载测试》。它提醒了我一件事：負載測試也有自動化工具。我以往很少在這一方面下功夫。大部份時候，我都是針對特定情況，自行撰寫特定的負載測試工具，而且不是很好用...

我目前尚未引入 JMeter 到日常工作之中，暫時先在此做過標註。不過有一點可以先說，JMeter 是針對應用軟體的成品或者整個運作環境進行負載測試，跟你的應用軟體開發工具無關。所以並不侷限於 Java 開發的專案才能用 JMeter 。使用 PHP 或其他工具開發的案子也能用。

• 让开发自动化: 自动负载测试 - 使用 Apache Ant 和 Apache JMeter 频繁进行负载测试
• Apache JMeter
• JMeter Ant Task

附帶一提，developerWorks 專欄作者 Paul Duvall 所撰寫的《让开发自动化》專欄，皆有相當高的實務價值，值得一讀。

剛在重構一組類別的程式碼時，突然想到 Martin 在《敏捷軟體開發原則、樣式與實務》一書中提到的一個編程技巧，就是在失敗狀況時回傳 NullObject ，避免行為調用者用 if 或 try 處理失敗狀況，影響程式可讀性。

我重構中的類別程式碼，基本上是一個聚合類別，它包含了其他類別的個體。此聚合類別提供一個方法 get() ，以取得它所包含的個體。外部調用 get() 後取得內容個體後，立即呼叫該個體的一個方法。

前一陣子在工作場所碰到一件事，我的同事抱怨 SVN 不能幫他合併他修改過的分支內容。我覺得很奇怪，因為我並沒有碰過這種情形。一開始我以為他是不熟悉 TortoiseSVN 工具，後來我實際看了他操作後，看到他竟然一次要合併近百份源碼檔，當場無言以對。

我記得我曾說過 SVN 可以幫我們程序員自動合併分支的源碼內容，並在衝突時提示我們。然而，在碰到同事這件例子後，我發覺我忘了加一個但書: 「請在持續整合(Continuous Integration)的原則下利用合併功能」。否則再好的版本控制工具也無法幫你合併。

日前配合 Selenium 撰寫一個 Web 應用軟體的測試案例，案例中有一句斷言要判定指定的表單輸入欄位是唯讀的 (readonly)。我個人很直覺地使用了 assetrNotEditable，但測試結果卻是錯的。後來我又試了 assertEditable、assertAttribute 及 assertNotAttribute 等寫法。始終無法正確而一致地判定輸入欄位的唯讀屬性 (readonly)。

依據參考文件 (Selenium IDE Reference) ，assertEditable/assertNotEditable 的說明，這兩種斷言都是調用 isEditable() 判斷。於是我開啟 selemium-api.js 後搜尋 isEditable ，找出它的源碼內容。結果發現它只判斷輸入控制元件 (input element) 的 disabled 屬性，而未判斷 readonly 屬性。

日前我在公司和同事討論一個案子的 database schema，PM初期丟下來的 database schema 是寫在 Excel .xls 檔中。我拿到手後看了一會，覺得有些怪怪的，好像有些重覆。自然要討論內容。不過，用 Excel .xls 實在不方便討論，不時地切換試算表頁，常常中斷思考與討論節奏。所以，我乾脆打開 StarUML，建立一個類別圖 (Class diagram)，把 database schema 畫了出來。在類別圖中清楚地呈現了表格與關聯性。一畫之下果然討論起來就順暢多了，也重新修正了不少地方。那接下來呢？再打開程式碼編輯器，把剛剛畫出來的 database schema 類別圖的內容，重新用 SQL 語法編寫一次嗎？

喔，不，老兄，那樣太不專業了。我們可是專業的資訊人員，重複輸入同樣的資訊，不是我們該做的事。身為專業資訊人員，就應該重複利用輸入過的資訊才對。不然我們做什麼資訊管理，搞什麼資料庫？

過去，我提到 REST 這個字眼時，多半指的是一種常用的 Web-based 應用軟體設計慣例或樣式 (我個人偏好用"慣例"一詞，不過用"樣式/pattern"好像比較專業)。既然是慣例，那在設計和使用上就比較隨興。不過隨著 REST 樣式的大量應用，有愈來愈多案例開始使用更制式化的設計樣式，這些高度制式化的 REST 服務，就稱之為 "RESTful web service"。 "-ful" 這個字尾正是在強調它們的設計方式完全符合 REST 文獻的建議內容。

相對於 RESTful ，以往那種基於慣例與相容性的實作方式，有人就稱為 RPC 。不過說到 RPC ，我第一時間想到的是 Unix 系統的 RPC (Remote Procedure Call)，而且它的歷史更為悠久。為了避免混淆，所以我傾向於用 "REST-like" 這個稱呼。

有一字串，其格式為以逗號 (,) 分隔的記錄，例如 "a","b","c"。當某些欄位之值為空白時，會有逗號相連的情形，例如 "a",,"c"。

現在要用字樣規則式(Regular Expression, Regex)修改空白欄位的表達方式，改成一個空字串 ("")，一般我們會寫成 s/,,/,"",/g (by Perl)。不過這種寫法碰到連續多個空白欄位時，例如 "a",,,"c"，會變成 "a","",,"c"，得不到我們要的結果。因為 Regex 解析器在找到第一組 ,, 後，會把處理指標放在第3個逗號的位置上。當 Regex 解析器進行下一個比對動作時，它將從第3個逗號開始尋找，此時它看到的只有一個逗號，故判定不符合樣式，也就不會進行替換動作。

碰到這種情形，我們要用 look-ahead assertion (前瞻斷言) 處理。 Look-ahead assertion 的語法為 (?=pattern)。See also perlre::Look-Around Assertions。

在 Web 應用系統的開發工具中， Selenium Core 是一套相當著名的測試工具。它的特點是 "直接在真實的瀏覽器中測試各項動作" 。由於現行各家瀏覽器的實作狀況各有所異，所以這項特點可以真實反應 Web 應用系統對各家瀏覽器的相容性。也正由於它是直接在真實的瀏覽器上進行測試，所以它也不可避免地受瀏覽器的功能限制，其中最主要的限制就是 "Same origin policy"(相同來源政策)。

凡是 Ajax 的開發人員，對於 "Same origin policy" 一定不陌生。這是瀏覽器保護使用者資料的重要安全措施。而 Selenium Core 是一套以 JavaScript 實作的測試工具，所以也受 Same origin policy 限制。這就使得開發人員在使用 Selenium Core 測試 Web 應用系統時，必須要把 Selenium Core 安裝在 Web 應用系統的目錄之下，以符合瀏覽器的相同來源政策。如果 Selenium Core 和 Web 應用系統的來源不相同，瀏覽器就會回應 Selenium Core 沒有權限載入 Web 應用系統的頁面。如此一來也就無法進行測試工作了。

今天看 iThome 的報導，知道 Jazz 開放申請使用。我也是這時才知道， Jazz 原來是一個軟體協作平台。

去年10月底，我參加 2007 IBM開發者大會時，雖然知道大會主題是 "Jazz" ，不過一直以為那是一個形容詞。在當天的議程中，完全沒有看到所謂 "Jazz" 軟體的影子，那天談的是 Web 2.0 和 SOA 。今天才知道原來那還是一個軟體協作平台。IBM 的宣傳也差了點吧...

Using XSLT, PHP, or Ruby on Rails to transform XML documents into XHTML documents. 展示 XSLT, PHP 與 Ruby on Rails 的樣版撰寫風格。

在使用樣版引擎之前，我們需要先將資料自外觀中分離，因此 A Note of HTML Form and XForm 算是本文的前置文章。當我們將資料和外觀分離時，我們將更進一步考慮如何將外觀樣版化。

如何分割 "資料"(Data)與 "表單外觀"(呈現層,Presentation)。

HTML Form 之中，資料與表單元件的陣述混雜在一起，增加文件編寫與閱讀複雜度。此複雜度不僅是針對人工輸入與閱讀，對應用軟體亦然，例如網頁編輯工具、Famework 工具等等。混雜的陣述方式，增加了前述工具的開發者之工作 - 編程難，除錯難 。

cf 的回應 中提到了 polymorphism 和 generic 的看法。我的看法稍有不同。

我眼中的泛型(generic)，若用非常簡化的方式來表達，就是不管型別，只看程式形式，亦即演算法。如稍候例舉的 max() 就是一種泛型演算法 (STL 也有一個同名的演算法)。我的說法和其他人的說法應該沒什麼不同。那麼多型(polymorphism)、泛型和樣板(templete)之間有什麼關係？端視程式語言的特性而定。

首先，多型(polymorphism)具有類別繼承的性質，是個體導向(OO)的概念，但泛型(generic) 不是個體導向概念。我們同樣可以在只有基礎資料型態，沒有繼承觀念的環境中使用泛型設計，只是彈性就低多了。在個體導向語言中，藉由類別繼承與動態連結的能力，才能充分發揮泛型設計的優點。

同人在《Time-Boxing 於軟體反覆演進的必要性》之中所說的情形，我也有碰過。

有時，客戶提出的需求變化其實並不是個好方法。在這種時候，我會示範或舉個例子，告訴客戶一個更好的方式。如果有示範品的話，客戶通常會很快接受。接著，我會告訴客戶這些實作方式是不是現有的。如果沒有，大約需要多少工時，並評估其重要性及時程。換言之，要評估這樣的需求變化要不要立即處理。就算客戶不能當天看到修正結果，也要在溝通的過程中，讓客戶了解前因後果以及處理時程。畢竟，「溝通」是雙向的，而不是盲目地接受客戶的要求。開發團隊單純地接收客戶指令，算不上溝通。

當然，這些內容在敏捷方法的書中都有提到，我就不再多說。我接著要提我個人的所見所聞，是上述內容在國內實行時的困境。

同人針對我的《敏捷方法實務研討會會後筆記3》寫了篇評論。確實，週期的長短並不是關鍵。因為以「日」為單位的反覆週期，是敏捷方法重視使用者參與，將使用者拉進開發工作之後，自然而然就會發生的必然結果。敏捷方法則透過密集的溝通行為，一舉將反覆式開發的週期縮短到以「工作天」為單位 (敏捷方法實務研討會會後筆記3)。

說到 CMMI ，可是現在國內軟體公司之間的熱門話題。好像沒通過 CMMI 認證，接洽案子時就矮人家一截。我之前也待過一間通過 CMMI level 2 的軟體公司。可惜的是，我完全看不出取得 CMMI 認證的公司，他們的軟體開發品質以及程序員工作效率與以往有何不同 。雖然如此，現在台灣官方 (經濟部、資策會等) 就是相信 CMMI 那一套。我並不是說 CMMI 沒用，只是在缺乏穩固基礎的條件下， CMMI 認證只是表面文章。

「穩固基礎」是指什麼？ 就是夠多的 senior programmer 、正確的程式設計觀念等等基本功夫。舉例來說，如果有一間軟體公司幾乎所有程序員都有7年以上的資深實務經驗，那不論是 CMMI, CMMV 還是 CMMX 認證 (喔，當然沒有 CMMV, CMMX ，我只是在玩羅馬數字遊戲)，他們推起來都一定順暢無比。因為他們的觀念及實務作法早就到位了，就差套個標準流程的形式而已。

雖然我們總是說著動態語言(dynamic language)、靜態語言(static language)，但區分方式並不是語法，而是運行環境。

如果程式影像在載入前便確立並儲存，那麼是靜態語言[If the image of program which including op code and data is static in disk before loaded, we call it 'static language'.]。這句話對學過作業系統概論或組合語言的人比較容易理解。因為在組合語言中，要求程序員設置 code 節區， data 節區等內容載入記憶體的位置。所以我們很容易聯想記憶體中的程式影像儲存在檔案系統中的情形。與之相對的是，若程式影像在載入後才建立，則是動態語言。

資料結構與演算法

喔，各位沒看錯，陳教授確實把資料結構與演算法列入他規劃的敏捷方法 (myAgile) 條目中。我看到這一點是非常 Orz

陳教授有提到理由，台灣的程式設計教育重視計算與解題，而不重視思考與建構。所以程序員常常學了資料結構與演算法之後，卻不會運用在實際的編程工作上。故此他特別把這一點列入 myAgile 條目中。

測試驅動開發 (Test Driven Development, TDD) 的觀念由來以久。寫程式時會順便寫測試碼，幾乎是所有有經驗的程序員在不自覺下養成的習慣。例如我在《運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見》一文中，提到我以前用 C 語言寫程式時順手寫測試碼的習慣。不過那個時候，xUnit 這類測試工具還不普遍。當時看其他人寫的開放源碼程式，幾乎是人人各有一套測試碼的撰寫風格。但是隨著 xUnit 工具的普及，測試碼的撰寫方式也愈來愈一致了。同時，也改變了程序員編程時的習慣，帶動了先寫測試碼的「測試驅動開發」觀念。

TDD 的好處，基本用不著我多加說明。 Robert C. Martin 在《敏捷軟體開發-原則、樣式及實務》中寫的再明白不過了。儘管如此，在研討會中，我還是針對 TDD 提了一個問題。我的問題是：能不能藉由測試案例建立更準確的工作時程量測指標，以便掌握確切的工作時程。

雖然每本敏捷方法的書，都會提到測試驅動開發(TDD) 及反覆式開發過程(或稱迭代式開發) ，然而它們並不是敏捷方法獨有的要素。這兩者都是存在已久的編程實務。XP 並沒有新的觀念，它的觀念與程式設計的歷史一樣老(Kent Beck)。但敏捷方法確實把這兩者發揚光大，讓人們注意到這兩種實務作法所蘊涵的強大威力。

陳教授在會中也一再強調反覆式開發過程。但對陳教授解說的內容，我持有兩點不同看法。雖然當時提問了，奈何時間有限，並沒有足夠的時間討論。

敏捷方法強調溝通，且溝通行為不僅發生在負責軟體開發工作的程序員之間，也要包含使用者。所以敏捷方法的實踐作法中，重視並要求「使用者參與」。陳教授在會中使用「駐廠使用專家 (On-site usage expert)」表示在敏捷開發過程中的使用者代表。一般則稱為「駐點客戶(On-site customer)」。

中央大學資工系在6月15日舉辦了一場「台灣敏捷方法實務研討會」，由陳振炎教授主講。我將聽到的內容與自己的感想做了一番整理。

敏捷方法的特色與重點，絕對是「人際溝通」。 Ivar Jacobson 說「敏捷是一門社會科學。它關注的是如何讓大家像一個團隊般工作、如何激勵成員、如何相互合作等等」(CSDN《程序員》2007年4月刊)。

三不五時就會聽到有人問寫程式需不需要懂數學，例如《寫程式到底需不需要懂數學》。在我這個大學時五修微積分才過關的人聽來，還真是刺耳。這根本是個偽命題。

若說寫程式要懂邏輯與代數，這我同意。但若說寫程式要懂數學，那我就反問要懂數學的哪一部份？

本文將指引讀者，如何在 Windows 平台上快速安裝 GTK2/Glade 暨 PHP 與 Ruby 的開發環境。

在泛Unix環境下，我們通常使用 GTK+ 開發圖形化使用介面(GUI)的應用程式。GTK+ a multi-platform toolkit for creating graphical user interfaces. 許多動態語言，如 Perl, Python, Ruby, PHP 等等，皆可利用 GTK+ 開發圖形化使用介面程式。由於上述動態語言之軟體開發環境與 GTK+ 皆具有跨平台的特性，因此利用它們所設計出的應用程式，通常可運作於多種作業平台之上，包括 Win32 (Windows 2k/XP) 平台。

報個消息。中央大學陳振炎教授定於6月15日，在中央大學辦一場「敏捷方法實務研討會」。相關訊息請見網頁。

我老是在談自己的經驗，以自己的經驗去驗證書上的 XP/Agiel Method 內容。還真是挺想知道其他人是如何實踐的。如果沒什麼意外，我應該會參加。希望能向公司爭取到公假...

當我說：MIS 和 PM 應該系出同門，都屬於「資訊管理科系」。按理說溝通時應該不會有觀念的落差。然而實務經驗的落差卻很大。其實有些挖苦的味道。我並非資訊科班出身，所以我曾經以為 MIS 和 PM 系出同門。後來發現我錯了，實際狀況並非如此。我的經驗是 在傳統升官發財的思維下，有點能力的 programmer 多數依「Peter Principle」升遷 PM 或系統分析人員(台灣資訊軟體業缺乏資深programmer) 。在我看來，國內的 PM 多數是從資工等技術體系出身。與 MIS 並非系出同門。

同人說 關鍵不在核心，而是在邊界 (註)。 kuni 說 我覺得成敗最關鍵人物是軟體公司派去溝通需求這個人 。我在《Bug 數量與軟體品質控制》中說 甲方接口單位通常是甲方的 MIS ，通常跟乙方一樣是資訊科班出身... 難怪甲方無法參與開發流程，甚至參與後反而成為專案的阻力 。又在《甲方、end-user 與需求落差》中說 基於 Agile methods 強調使用者參與的精神，我更注重使用者在軟體開發的活動中扮演了什麼角色？ 。

我們的觀點都指向同一個重點，那就是溝通。

今天在 Ruby-talk mailing list 上看到一則消息「Microsoft brings Ruby to the browser?」。重點如後述，各位姑且看看。

Microsoft 日前發表 Silverlight 。 Silverlight 是一種 RIA 開發工具與環境，其用途與目前廣泛流行的 Adobe Flash 技術相同。以 plug-in 方式增加網頁內容之多媒體支援，並提供使用者更豐富的操作互動性。由於 Silverlight 是基於 .Net 平台的應用環境，故其中將包含一個小型的 CLR 執行環境。據聞微軟亦將正式發佈 .Net 平台的 IronPython 與 IronRuby (.Net 的 PHP, Phalanger, 不在其中?)。據此，程序員將可能以 CLR 所支援的這些動態語言，開發 Silverlight 的 RIA。

我在《PHP 不需要另一個樣版引擎, part 2》中寫著：說不定哪天我們就會看到內建 PHP 引擎的瀏覽器了。也許 .Net 版的 PHP (Phalanger) 會搭上微軟 WPF 架構 的順風車，成為第一個被瀏覽器 (Vista/IE only) 內建的 PHP 引擎，用於解析 HTML, XAML 等文件中的 php 標籤。這句話似乎即將實現。

Mr. Saturday 談到 Coding Style - 程式設計風格對軟體開發的影響 。其中提到了一位老朋友 - Hungarian Notation - 。中譯為「匈牙利命名法」。以現在的標準來看，匈牙利命名法很醜，變數名稱又臭又長。但它的存在有其特殊背景。匈牙利命名法在組合語言和 C 語言的 coding 場合其實非常好。它們沒有便利的 casting ，一個指標或一個整數沒什麼差別。不加個記號說明一下型態， coding 工作可要命了。我當年會把 struct 印成一張速查表貼在電腦螢幕旁。每寫一個符號，就瞄一下看看這變數是啥型態。若用匈牙利命名法，取一個 dwID 和一個 szID ，就可以減少不少錯誤。至少不會把整數(dword)的 dwID 當成字串指標；也不會把 szID 當成數值代號。

當然在C++或動態語言中，這種命名法就毫無意義了。大多數情形下會自動轉型，故 “1″ == 1 is true. 這又提醒我們一件事， Coding Style 跟程式語言的特性有關。不同的程式語言，因其語法特性不同，就會有不同的 Coding Style 。不必要硬套同一種 convention 。

我個人對 Coding Style 的要求頗為寬鬆。任何像我這種寫或維護過十幾萬行 C 語言程式碼、被 C 語言多樣而自由的程式風格荼毒過的程序員，應該都能適應各種怪風格。基本上我只要求三點。一、要縮排；二、以80個字元為寬度換行；三、變數命名方式一致。不過太寬鬆的結果，就是我有時會被視為常常寫怪 code 的那種人。

喲哪桑說「I Don't Like Outsourcing」。他說因為 外包，將確保你的軟體知識不再累積，軟體也無法成為你策略性的核心能耐(Core Competence)。

基本上，喲哪桑是從 Resource Based View/Knowledge Based View (RBV/KBV) 之觀點主張不要外包。然而我以為喲哪桑的觀點有必要加以修正，才能正確表達他所要表達的意涵。「軟體」一詞沒有抓準非IT企業的核心能耐之本質，精準地說「軟體開發」並非IT企業的核心能耐，「業務流程」才是非IT企業的核心能耐。

FireFoxer 于 要不要走程式設計這一行 提到「興趣」對於一個想走程式設計這一行的人是否必要。

個人看法以為興趣是必要的。Programming 基本上是一種「設計」工作，尤其對我這種傾向 Agile method 的程序人員而言更是如此。設計就是編程，編程就是設計。我們不但要達成功能需求，更在其中追求技藝之美。如果沒興趣，將得到一個「程式碼打字人員, code typist」，而不是一個「程式設計人員, program designer」；兩者之差別在「創造力」，其差異宛如臨摹者與畫家之分。

在我看來資訊軟體產業中也分很多行，而程式設計 != 資訊軟體產業。我並不輕視 code typist ，因為資訊軟體產業這一行還是需要 code typist ，但走這條路不等於走程式設計這一行。再者就我週遭經驗，沒有興趣以及一定偏執程度的人，通常在這條路上都待不久。儘管他們不會離開資訊軟體產業，但不會再投入編程工作了。

我在《軟體工程的 GPS》說「一個人寫程式，其實很苦悶；兩個人一起寫，就頗有樂趣了」。這句話發自心腑。獨行之路不好走，沒有興趣走不下去。

Google Code 是一項開放源碼專案管理服務平台 - Google Code Home，它採用 Subversion 作為版本控制系統(See also: Programming with Subversion Quickstart)。想申請建立專案非常容易，只要到 Prject Hosting 中填好申請表格即可建立專案。唯一限制是軟體授權證一定要採用 Google Code 提供的開放源碼授權證 (如 GPL, Apache License, New BSD License)。必須先登入 Gmail 帳號之後，才會出現 Create a new project 的申請表連結。提醒事項:

在思考 Ruby 模組與混成(mix-in)概念的過程中，勾起了我當初學習 Java 的記憶。C++ 藉由多重繼承達成程式碼再用之目的，也因此衍生了類別鑽石繼承問題。而 Java 出現時，強調它使用單一繼承並結合介面宣告而避免鑽石繼承問題。然而我對介面的使用經驗卻是負面的。

介面只宣告行為的外觀而不牽涉細節，細節在類之中個別實現。舉例而言，如果有兩個不具共同父祖類別的類，假設為 A, B 類，但具有一個共同的行為、一段相同的程式。 C++ 的作法是將此共同行為 - 亦即這一段相同的程式 - 設計為一個類，假設為 C 類，再令 A, B 類多重繼承 C 類；只要 C 類之中沒有任何屬性與 A, B 類之父祖相同，就不會導致鑽石繼承，同時達成程式碼再用之目的。Java 的作法則有兩個方式，其一是介面，其二是深度繼承。

Alex Yin 在《請使用者也參與軟體專案, CMMI-ACQ》中回應：「正確而言並不適合將使用者與甲方畫下等號。現有的軟體工程在IEEE-STD-12207的Acquisition Process就是敘述甲方(軍備局)的activity。」純粹從 PM 的角度來看，確實在發出採購案前，甲方內部應先進行一套評估流程。但甲方內部流程並非我關注之事。我是一個 programmer ，所以我關心的是已進行採購且軟體專案開始實施的狀況，而且基於 Agile methods 強調使用者參與的精神，我更注重使用者在軟體開發的活動中扮演了什麼角色？

在 Taiwan.CNet 上看到喲哪桑寫的《GPS與軟體流程》，我想到了軟體工程中確實存在著類似 GPS 的智能代理者 (Intelligent Agents) 。

Reflection ，一般譯為「反射」。但我一般說這是 讓 object 看到自己的外貌的功能(PHP5 的動態函數/行為調用效率測試) 。這說法似乎和「反射」一詞扯不上關係。事實上，我稱這種能力為「自識」能力。

唉唉，我差點被 Tokimeki 搞糊塗了。在他的《函數設計準則 (2)》一文中，他設計了兩個函數，一個是一次只處理一筆的 (載入單一模組、寫入單一記錄, etc) ，另一個是批次處理的。

我們在設計函數時，通常要考量函數之中發生錯誤時應如何處理？這一方面的知識沒有捷徑，通常需要仰賴足夠的設計經驗以為準則。概略而言可分兩部份來談：其一是錯誤回報；其二是資源回收。

由於此文是我回應 Tokimeki 的 PHP 文章之內容整理而來，故會夾雜一些 PHP 的例子。

先前我在《Bug 數量與軟體品質控制》的回應中提到：從 PM 的角度來看，以使用者和開發者都認可的 use case 為準，必須在此 use case 的範疇下無 bug 才能交貨。不過我觀察國內的 case 好像有個現象，使用者不參與 use case 內容的，彷彿使用者跟這軟體沒關係。依據開發者單方面規劃的 use case 來撰寫 test case 。這種現象好像很正常，但我個人總覺得哪裡不對。

就讓我們這些 programmer 承認吧，我們在進行軟體專案時，口中有 user ，但心中無 user 。使用者總在有意無意之中被排除在外。其實使用者也很關心如何能評量委託他人開發的軟體是否符合需求。例如我現在服務的百貨零售業，前一陣子就為了公司的零售與進銷存系統到底有沒有達到預期目標 (事關付款問題) ，而跟廠商「飛x 高」打了場官司。

到底在軟體工程方法中，有沒有關於甲方 (使用者) 的部份呢？褐雨燕學習筆記 中提到了 CMMI 的部份，規範於「CMMI-ACQ(CMMI for Acquisition Organizations」之中，雖然目前還僅僅在草案階段。

我看到 thinkingmore 在《subversion 與 file:// protocol》提到，在 Windows 下，可以偷懶不用裝 Subversion server ，利用 file:// protocol 就可以存取專案貯藏庫 (Repository) 。在 Subversion 文件中，稱 file:// protocol 的方式為 Direct repository access (See also: Subversion Repository URLs) ，或 Local Access (See also: Local Access to the Repository)。關於這種做法，我補充一些內容。

威豆兄問我「如果有一個公司希望你來參與，建立 Open Source 的軟體工程流程 你願意試試看嗎 ?」，我很誠實地回答，我不適合這工作。但威豆兄是位有心人，對 Open Source 的發展很有熱情，又說道：

我們不是要理論的人啊 ... 我們要組成能夠去實踐的團隊 !! 看到很多中小學已經有很多老師願意投入 OSS 程式開發， 但到現在還是非常沒有組織 ... 照這樣下去， OSS 永遠是 Just for Fun !! 如何成為具有關鍵性的角色呢 ? 我們期待更多有心人投入 ... by 威豆 at 2007年02月1日

於是，我也很認真的寫了這篇文章，談談我心目中的 FOSS (Free/Open Source Software) 實踐團隊，以及我是如何從經驗中擁抱軟體工程 (主要是 XP/Agile) 的。

謝謝 tokimeki, robmlee 兩位網友的回應。

我離開上一家資訊軟體公司時，用的理由基本上是獨孤木說的「擔心你健康，很怕你常時間熬夜加班，會過勞而死的母親」。另外還加上一些別的理由，例如對公司文化不適應。嘿，所謂公司文化就是唯「微軟」是從，除了 Visual Studio XXX 以外不知其他工具，除 ASP, .Net 外不知其他技術。我在《為什麼程序員不用版本控制工具?》說的就是我碰到的情形。我在 Open source 界混太久了，還真無法退化去適應這種封閉文化。

tokimeki 在回應《動態語言關於參數宣告的寫作風格》時提到： 所以我只要在函數內設定一個預設陣列，然後把參數陣列以及預設陣列丟進去處理就行了，傳回來就得到過濾好的參數陣列，而且保證每個參數都有值。接下來就可以對每個參數作驗證、運算等動作。 這個作法還可以按所謂「Configuration Driven Development」的概念進一步改良。 Configuration Driven Development 是以中介資料描述軟體運作時的組態，我們藉由組態內容便得以調整與協調程式運作的內容。可以參考 Steve McDuff 的這篇：《Configuration-driven development》。

該議程主要介紹使用微軟的 WPF/XAML 技術開發「新一代使用者操作經驗」的應用軟體，然而我看到的只是微軟將一個舊技術按自己的策略量身打造的專有規格。我說的舊技術，是指使用標籤語言 (markup language) 設計應用軟體呈現層的方式。這句話聽來很玄，但其實早已非常普遍， HTML 就是這種技術的最佳代言人。

現在回頭看這份講義，像是一份歷史文件，記錄著當時人們所使用的用詞和工具。然而，工具一時的，觀念是長久的。當時所談的觀念仍然支撐著現在的 Web 環境。有時候拋開那些被高度包裝的種種 Web 開發工具與名詞，回去看看那原初的名詞與意義，反而能夠讓後進者學到純淨的知識，從零思考 web programming 的內涵。

若是 Web 應用, 大可不必採用 MVC, 招致執行效率差程式碼分散的結果 相反的, 也有工程師告訴我使用 MVC 對於長期維護程式增減功能有很大助益

據了解使用 MVC 程式的行數的確會增多; 但也會有助健全的程式開發與便利維護程式

由於許多 framework 都把 MVC 列為特點，因而導致初學者把 MVC 和 framework 這兩件事混淆在一起，然而這兩者是不同層次的事物，甚至彼此無關。

在進行任何程式的設計工作之前，我們必定已經知道程式的輸出入結果，亦即我們已經確知當使用者輸入什麼資料後，程式應該輸出什麼結果。更進一步說，我們已經知道使用者將如何使用這個程式，諸如使用者在操作過程中會做什麼事，而程式對操作內容應該如何回應等等。這段理所當然到近乎廢話的敘述，卻是所有軟體設計人員惡夢的開始，也是所有軟體工程實踐作法的起點。在 eXtreme Programming 中，我們稱這些內容為「故事 (story)」；在 RUP 中稱之為「使用案例 (use case)」；在 Microsoft Solution Framework 中稱之為「情節 (scenarios)」。我個人偏好使用「故事」一詞，因為它不像術語。既然故事是設計人員惡夢的開始、設計工作的起點，那麼就先說一個故事。

自從我到某資訊軟體公司做過一陣子程式工程師後 (過去式) ，我就一直在感慨為何國內的多數程序員不用版本控制工具 (Version control system) 。這個問題不久前得到了解答。