原创 微軟眼中的TDD (原文最終修訂於2006-06-11,下午03:20:52)

微軟最近發佈了測試驅動開發的方案(點擊這裏)。這些方案與Visual Studio 2005 Team System的使用密不可分。老實說,我對他們試圖去把他們自己的工具與TDD(譯註1)綁定起來並不覺得什麼。他們是個商業機構,而這就是一

原创 架構設計--僅是軟件開發之第二大影響力?! (原文最終修訂於2006-07-01 凌晨03:20:31)

SDWest2006(譯註1)對我來說是個有趣的大會。我除了星期三之外(當時我正飛往費城參加一個客戶會議 == 因此錯過了Jolt頒獎部分)每天都在演講。我也參加了一些談話和會議;其中最引人關注的是Mike Cohn的計劃與估算的談話。我

原创 如何讓Ruby代碼更簡練?!(原文最終修訂於 2006-08-18 下午02:42:25)

你可以用它來做什麼呢?請閱讀... 我四前年曾接觸過Ruby,就是爲了看看這個語言到底什麼樣。我用了它一段時間然後就把注意力放到Fit,Fitness(譯註1),和Java/.Net上了。然而最近,隨着Rails的興起,我又開始關注Rub

原创 OO難題在Ruby中有了新解 (原文最終修訂於 2006-08-21 凌晨02:27:38)

單一職責原則(SRP)認爲,一個類應該有且只有一個改變的原由。換個說法,一個類中的方法應該出於同樣的一種原由而改變,它們不應被不同原由所驅使,而導致朝着不同的方向改變。 舉個例子來說,考慮一下以下的Java類: class Employe

原创 跋涉於代碼的泥潭之中 (原文發表於2006-06-02 下午04:45:17 )

我正在寫一本叫做淨化代碼(譯註:Clean Code)的書 。這本書裏滿載了各種代碼示例;有的較短,有的較長。在我看來,如果你想教人如何寫出好代碼,你就必須給他看很多代碼示例。 一個我的評論者抱怨說, 他覺得不是一定要“跋涉於代碼的泥潭之

原创 當心:工具的美貌 (原文發表於2006-06-29 下午12:12:33 )

我這周在芬蘭的弗羅茨瓦夫(譯者注:Wroclaw)爲一位客戶作諮詢。(那是過去叫佈雷斯勞(譯者注:Breslau)的德國城鎮,而現在發VRAHT-swahf的音。)這週末我拜訪了這裏的考古博物館,就在城鎮的廣場旁。當我觀看這博物館的時候,

原创 綠色護腕 (原文發表於2006-06-10 下午01:14:07 )

我已經收到了很多的請求,是關於測試優先(譯者注:TEST FIRST,一種敏捷開發所倡導的優秀方法)綠色護腕(譯者注:Green wrist-band,一種優秀敏捷人的榮譽)的。如果你也想要一個的話就發信過來,要貼郵票,寫上你自己地址:

原创 Java枚舉,酷! (原文發表於2006-04-25 下午01:13:48)

當我頭一次看到Java 5中的新登場的枚舉類型(譯註:enum)時,我還是持懷疑態度的。這些枚舉類型允許你定義成員和方法(譯註:variables and methods),甚至是抽象方法!你能用它來做什麼呢?嗯,我現在已經找到了這個問題

原创 敏捷人還沒接受它麼?!(原文發表於2006-07-31 上午07:27:59 )

本文是對Cedric發貼的回覆   一些贊成 Cedric提出了一些不錯的觀點,尤其是指出瞭如果敏捷開發的“傳道士們”只使用教條的論點,而不去接觸那些遇到實際的問題的真實的開發者,那麼他們就沒法再將敏捷進行到底。早期的接受者已經採納了;

原创 軟件分析 Vs. 架構設計 (原文最終修訂於 2006-05-29 下午06:44:14)

何謂軟件分析(analyse)?它有沒有一個成文的定義?如果你曾讀過軟件教科書或是著作,就會發現有多少個作者,就有多少種分析的定義。具有諷刺意味的是,我們知道軟件分析是必不可缺的,但卻沒有其真正的定義。 一個用來區分軟件分析與設計(des

原创 用Rails將敏捷Web開發進行到底! (原文最終修訂於2006-08-14,凌晨03:49:12)

前些天我正好有時間學習Rails(譯註1)。我就去了《用本主義程序員》的(譯註2)網站(http://www.pragmaticprogrammer.com),而且購買了beta版的《用Rails進行敏捷web開發》。我於是就開始了閱讀。

原创 敏捷開發的精神內涵 (原文最終修訂於2006-08-11 上午10:49:50)

從根本上來說,所有的敏捷開發實踐,諸如TDD(譯註1)、結對編程(譯註2)、持續集成(譯註3)和重構(譯註4),都有一個統一的觀念--永遠不被阻攔。這就好像是一個優秀的撞球選手總要確保他的每一次擊球都能爲下一擊創造好機會,每個優秀的敏捷開

原创 TDD的三條軍規 (原文最終修訂於 2006-04-09 晚上09:45:01)

這些年來,我喜歡用下面這三條簡單的規則來描述測試驅動開發: 除非這能讓失敗的單元測試通過,否則不允許去編寫任何的產品代碼。 只允許編寫剛好能夠導致失敗的單元測試。 (編譯失敗也屬於一種失敗) 只允許編寫剛好能夠導致一個失敗的單元測試通

原创 容器外的JSP頁面測試技術

Jsp測試技術 開發web應用程序最惱人的一點就是想要測試的話你就必須向將其部署好。當然,並不是所有部分都這樣。如果你是經過了精心的設計的話,你可以在Java程序中測試業務邏輯。你可以在應用服務器不運行的情況下測試數據訪問、接口以及存儲過

原创 軟件文檔--揚棄還是傳承 (原文最終修訂於 2006-04-12,上午12:41:14)

在本人的《敏捷軟件開發:原則、模式與實踐》一書中曾提到“Martin對編寫文檔的第一原則是:除非是必須馬上撰寫文檔而且意義重大,否則的話就乾脆不要寫它”。有些人把這個意思曲解爲敏捷開發一種不需要文檔的開發過程,這並不屬實。 文檔是所有軟件