關於 XP(eXtreme programming)

XP(eXtreme Programming)中文譯為『終極』、『極端』、『極限』的程式設計(或編程)。不管是哪一個譯名都不重要,只要不把他與 Windows XP 搞混就好。

XP 是由 Kent Beck 於 1996 年代初期提出。Kent Beck 是一個程式設計師,他以程式設計師的觀點看程式設計這項工作。長期以來,程式設計的工作受到死亡線(dead line)的壓迫,他們的產出往往無法達到應有的品質。XP 從人的本質考慮如何讓程式設計師,可以有尊嚴的工作,而同時可以產出高品質的軟體。XP 的精神可以說是實踐 Agile(中文譯為敏捷、輕量、靈活、輕快)軟體發展宣言四項價值觀:『個人及相互交流勝過軟體工程和工具可運行的軟體勝過完整廣博的文檔資料與用戶合作勝過合約談判回應變化勝過服從計畫

XP 提出了 12 項的基本實務作法,我們可以說 XP 是一種方法論。但別把這些實務作法(有些人還提出一些其他的實務作法)當成 XP 的重心。雖然這些實務作法很重要,也很務實 ,可以幫助你找到進入 XP 的路徑。但學習 XP 及使用 XP,更應重視它的基本理論基礎架構及價值觀。學習 XP 可以從實務作法入門,但別把你限制在這些實務作法當中。實務上導入 XP 也是從實務作法開始,但也必須同時鼓舞程式設計師,他們要有尊嚴的工作,他們能證明他們是可以達成客戶的需求。相信唯有如此,才能真正實現 XP 的價值。

我們將 XP 相關的文章蒐集在這裡,以方便對 XP 有興趣的同好參考,也希望各位同好多多提供相關文章,及實施 XP 的經驗及心得。我們將相關文章分成三個部分:

這個專欄主要是收集及翻譯中外著名學者專家,針對 XP 所發表的各類精采文章 ,以供各界同好參考 。當然,若其中有所遺漏或不正確之處,也希望提出糾正。這些文章有些是『點空間』的成員所撰寫,或從網友、同好處收集得來,版權所有,故未經同意不得以任何方式被傳送或發行。

XP 理論

標題&內容摘要 資料來源&作者 轉譯校稿 發表日期
Agile軟體開發:為何這麼熱門!

Agile Software Development: Why It's Hot!

[內容摘要]

Agile ,如Jim Highsmith在這篇文章中指出的,在我們的周遭都可以看到它的影子 - 而且事實上已經存在一段時間了。但是為什麼忽然間變得如此熱門?

Jim Highsmith Areca Chen譯作

何明遠 校稿

 

2003/12/15
極致軟體製程(前言、序、譯序、第一至第 七章)

Extreme Programming Explained

[內容摘要]

就像這本書封底所寫的「軟體專案的開發工作可以很有樂趣、很有產能、甚至很大膽。與此同時,還可以對企業產生源源不絕的貢獻,讓整個專案不致失去方向」。eXtreme Programming 縮寫為 XP,本書譯名為極致軟體製程,其乃針對小型開發團隊所設計出來的方法論,創始者 Kent 在這本書中詳盡的描述他對 XP 的發展構想、價值觀、基本原則以及種種策略,如他序文言及這本書「背後的一些想法 --- 它的緣起、哲學、故事、和迷失」,這也是他從事軟體開發「教練」多年,對於如何寫出可以交貨,兼顧品質和時效,所需要的最佳實踐法則。

XP 這種輕量級的方法論,挑戰軟體開發中許多傳統的信條,換言之,它可讓讀者視野一新,採取不同的觀點來面對軟體開發。如果想要了解 XP,就不能錯過本書,聽聽本尊的現身說法。

Kent Beck

First Class 軟體公司擁有者及經營者

李潛瑞

本書譯者(目前這本書台灣培生出版社發行)

2002/10/31
極端軟體製程探索篇(譯序、第一至第三章、參考文獻及註解)

Extreme Programming Explored

[內容摘要]

這幾天看了尤克強教授創新即中庸?》裡,談到他對中庸之道的新解,即是「在根據事情的本質採取不同的原則,而非永遠地保持中間」,同時他認為所謂的創造性人物,正因為他們貫徹地實踐「中庸之道」,故能依據情勢「從一種性格極端轉到另一個極端」。其實,無論是我們過去所認知的,如 Kent 的「學習駕駛」,時時修正方向,以確保「路線正確」,不偏移正道,亦或者是尤教授的「創新即中庸」裡展現的想法,兩者並不相悖。後者所重的為「因時制宜」,須依環境條件的不同,修正做法,即使是極端的不同;前者則當認清方向後,時時保持專注,務使自己不偏離正道。其實,兩者皆為「中庸之道」。

XP 雖名為「極端軟體製程」,然而此一「極端」,反而顯露其能「因時制宜探索篇中,譯者(李潛瑞)舉唐宗漢先生所言探索,不是依循或倣效。探索,是你自己的探索。」我以為,可作為這本書的最佳註解。
 
  • 譯序
    (;506,118 bytes)
  • 第一章:如何寫一支程式
    (;710,085 bytes)
  • 第二章:什麼是程式重整
    (;788,524 bytes)
  • 第三章:XP 的團隊實務
    (;767,211 bytes)
  • 參考文獻及註解
    (;415,362 bytes)

William C. Wake

Agile Software Coach

李潛瑞

本書譯者(目前這本書眳p資訊發行)

2002/10/9
攀岩和極限編程(XP)

原文:Rock Climbing and Extreme Programming()

[內容摘要]

這篇文章以攀岩來描 XP 的實現,作者發現極限編程的許多思想,很適合於攀運動,而且作者在攀岩運動中,體現了這些想法。

 

Ye Yongqing
IT department, Europeloan Bank
劉焱 譯作

朱子 編校

2002/8/5
Extreme Programming Explained》譯序

[內容摘要]

這是一本刺激的書它披露許許多多驚人而反傳統的觀點,對正規的軟體工程最具挑戰味道的,莫過於『軟體改變成本不隨時間大幅增加』的看法。要知道,軟體最大的敵人在於變動,甚至可以說,若能提出成功對抗變動的軟體方法,就算還稱不上是『銀製子彈』,最少也可以讓專案風險『暫時停止呼吸』好一陣了。

李潛瑞 李潛瑞 2002/5/27
CMM視角看終極編程

Extreme Programming from a CMM Perspective

[內容摘要]

終極編程(XP)近來已被當一種適應快速多變的網際網路世界和網路軟體開發的程式設計方法而受到倡導。本文從軟體能力成熟度模式(簡稱CMM,是為軟體機構規定開發程序改進優先的五級模式)的觀點重新檢視這一廣受歡迎的方法論,概述XPCMM,並從軟體CMM角度對XP作出評論。結論是:一些羽量級的方法論,如XP,倡導了許多良好的軟體工程慣例,但是一些慣例尚有爭論,且如果在使用的時候超出其狹窄的適用範圍後,使用起來的效果則適得其反。由於XP可以被用來處理很多CMM第二級和第三級的慣例,對開發程序改進有興趣者應仔細考慮後方能採用XP中的觀念,將其應用於軟體機構的商業環境中。反言之,使用XP的機構也應仔細考慮CMM描述的管理和基礎結構問題。

 

Mark C. Paulk

軟體工程研究所

卡內基` 梅隆大學

 


沈蘇南

朱斌

朱子

 

2002/4/15
瞄準、射擊(Aim, Fire)

原文

[內容摘要]

很多人批評XP是『先射擊、再瞄準』,XP的創始人Kent Beck也曾經在其著作當中說明XP的確是『先射擊、再瞄準』,而且是『先射擊、再瞄準』的好。不管是先瞄準還是後瞄準主要的重點是所謂的的瞄準所指的就是『設計』。XP不使用一般開發方式使用『前置設計』預先對系統架構作設計。

在本文中Kent Beck提出了一個新的觀念,也就是在舊有的理論中『先寫測試(test-first)』也就是代表了『設計』的概念。為先寫測試迫使程式設計師對系統架構必須有鮮明的了解,其結果也就是『設計』的概念。 所以XP也可以說是『先瞄準、在射擊』

Kent Beck
(本文已獲Kent Beck的授權翻譯並公布於網頁。)
Areca Chen 2002/1/15
與Kent Beck對談實錄

原文

[內容摘要]

由UML China於2001年12月7日舉辦與XP創始人Kent Beck對談實錄之內容整理及翻譯。

UML China

本文已獲UMLChina同意刊登。

Areca Chen 2001/12/17
XP:抄近路的詭計
Doug Rosenberg及Kendall Scott對於XP的質疑

原文

Pdf 版本(793KB)

Zipped版本 (599KB)

[內容摘要]

XP是新興的一個軟體開發序的方法論。其中值得質疑的地方相信還是蠻多的。以不同的角度來看XP對於想採用XP方法論的人而言,這篇文章提供相對的角度來看XP。雖然作者所持的論證可能有些偏頗也未能深入論證XP的問題點。但是這篇文章值得我們閱讀之處乃在於對於任何事物的質疑是不可避免的。任何方法論都有其優缺點,我們如何採用其優點而避開其缺點。同時我們應該學習的是在批評別人時如何把自己的論證做的讓人信服;個人認為這才是重點。

Thanks for visiting us
Doug Rosenberg,
Kendall Scott

(本文已獲Mark Collins-Cope的授權翻譯並公布於網頁。)

 

Areca Chen

 

2001/12/12
分析:「XP」能否進行大規模軟體發展

發佈時間:2001-07-04 15:51:56

日經BP 朱子提供 2001/11/5
與作者Robert C. Martin深度技術訪談關於終極製程

In-depth technical interview with author Robert C. Martin on eXtreme Programming

原文:

Pdf 版本(669KB)

Zipped版本 (458KB)

[內容摘要]

Robert C. Martin是ObjectMentor總裁, 物件導師(Object Guru), 『 C++ Report 』的編輯及『 Designing Object-Oriented C++ Applications using the Booch Method』的作者。本文是由Mark Collins-Cope詢問Robert C. Martin回答。Robert C. Martin在實務上採用XP開發軟體的經驗與理論上的映證經由Mark Collins-Cope一針見血的詢問得以一一闡述的淋漓盡致。XP的發展時間不長,實證上的例子多,這篇文章提供愛好XP而對XP有所懷疑的讀者一個相當好的映證的機會。

Thanks for visiting us

Mark Collins-Cope

(本文已獲Mark Collins-Cope的授權翻譯並公布於網頁。)

本譯文亦穫RATIO公布於其技術圖書館的網頁上

 

Areca Chen 2001/10/31
如何規劃XP專案

Planning Extreme Programming: The XP Series

[內容摘要]

這本書是The XP Series其中之一。這是一本有關規劃軟體專案的書。主要是為專案管理者所寫;他們必須規劃及監督實際的相關規劃工作。當然這本書也提供程式設計師及客戶;他們是扮演規劃及開發軟體的實體的角色。

(本文因未取得原著者授權僅限進偕會員閱讀,一般會員及網友只限一至三章。)

Kent Beck

Martin Fowler

Areca Chen 2001/10/10

 

解析XP(XP Distilled)

[內容摘要]

去年夏天在同事的影響下開始接觸軟體工程的資訊,UML、RUP、方法論... 一切都是那麼新鮮。偶然間看到 XP 這樣的名詞,參考了 XP Distilled 這篇文章之後感覺到,RUP 以及 UML 的入門檻似乎高了點,而且那麼多規範、做法,如何能夠在短時間消化
之後,進而選擇、安排適合工作環境的流程做法呢?而 XP 卻能夠抓住 Internet 時代軟體研發的快速和變化等精神,提出令人躍躍欲試的技巧,這就像是在慌亂的登山步道看見山友留下的指引一般,指點我們一條出路。就讓我幫大家節省一點時間,將XP Distilled 這篇文章翻譯成中文,並取得作者之一 Roy Miller 的授權,而得以和大家分享這樣的資訊。這篇文章尚未經過仔細校稿,如果有任何建議,歡迎寫信給我指教。

Chris Collins(Senior Software Developer, RoleModel Software, Inc.)

Roy Miller(Software Developer, RoleModel Software, Inc.)

Daimler Huang

[徵求校稿]

初稿2001/09/26
推薦連結 李潛瑞的XP網站 李潛瑞 李潛瑞 2001/09/26
終極製程eXtreme Programming(XP)

[內容摘要]

      XP是目前相當熱門的話題。XP是由Kent Beck於1996年代初期提出。他與Ward Cunningham共同工作一段時間,由於軟體開發的經驗希望提出一個比較簡單並有效率的方法。當初Kent思考什麼是讓軟體容易建構的因素;什麼是讓軟體困難件夠的因素。1996年Kent接受 DaimlerChrysler的專案並開始使用新的概念開發軟體。以而誕生了XP的方法論。

      Kent所認知的要改善軟體專案有四的方向,你需要改善溝通,你必須找尋簡化的途徑,你需要獲得回饋以讓你做的更好,你需堅持勇敢的去做。『溝通』『簡化』『回饋』及『勇氣』是XP四個主要精神所在。

    XP在規劃、設計、編寫程式及測試四個階段共提出了28條簡單的規則及實務作法。並對於如何導入XP提出了一些說明。這些規則、實務作法也應用了一些軟體工程的理論如元測試、可接受測試、整合程式碼等等,但未深入說明其實際內容。所以這一部份需要讀者自行再另行研究,也就是說原作者認為讀者應該已了解相關知識,但這並不影響對於本文的了解,後續我們也希望整理相關的軟體工程技術。 

  (檔案較大請耐心等候)

J. Donovan Wells

(本文已獲原作者Don Wells的授權翻譯並公布於網頁。)

Areca Chen

感謝趙光正校稿

初稿2001/08/17

第一次校稿2001/08/22

第二次校稿2001/09/25

重整(Refactoring)

標題&內容摘要 資料來源&作者 轉譯校稿 發表日期
重整:改善現有程式碼的設計
Refactoring - Improving the Design of Existing Code

[內容摘要]

基本上這是一本告你如何寫一個好的物件導向程式的書籍。他告訴你怎樣的程式是不好的程式(也就是教你如何聞出程式碼的臭味及有哪些臭味。)同時也提供你一些手段去除這些程式碼的臭味。這個手段就是『重整』(也有人譯成『重構』)。如果你想寫好物件導向程式這是一本中階程式設計師必讀的書。

我們以筆記摘要及討論的方式呈現重整的概念,所以希望讀者看我們的內容及所提出討論的問題,可以將你的想法在點空間討論區中提出與大家研究。

Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts
 
Areca Chen 2002/5/9
進行中.....
重整:在程式執行之後進行設計

原文:Refactoring: Doing Design After the Program Runs

[內容摘要]

這篇文章對重整(Refactoring)做了簡短的介紹,主要談到為什麼需要重整,以及如何使用手工方式或運用工具來進行重整。另外作者也說明重整的價值,同時表明對重整技術的期望,以及告知我們如何獲得這方面技術的相關資料。

Martin Fowler
Chief Scientist, ThoughtWorks

 

朱子 2002/04/15
系統重構 — 改善既有設計(Refactoring 中譯本之序文,前言及第一章)

Refactoring - Improving the design of existing code (Chapter 1: Refactoring, a First Example)

[內容摘要]

所謂的重構(Refactoring;Areca 譯為重整),Martin Fowler 於書中定義它是一種「在不改變代碼外在行為的前提下對代碼做出修改,以改進代碼的內部結構」的過程。簡言之,Refactoring 的目的不在於對既有的代碼增加新功能,而只是不影響程式既有功能及正確的執行下,改善程式代碼。或許 Refactoring 對許多人而言,讓他們感到相當疑惑 的是,這種行為究竟能否帶來任何益處?關於這一點,我想就讓 Fowler 及 Refactoring 的作者們來為各位解答。

Refactoring 這本書除了對既有程式代碼為何要進行重整的理由加以說明外,也指引如何來判斷哪些代碼需要進行重整,以及如何進行重整。我們在此僅摘錄侯捷的 Refactoring 中譯本的序文、前言及第一章,如想更進一步的了解中譯本的相關資訊,請參觀侯捷網站

Pdf 格式檔(930K)

原著:
Martin Fowler

中文譯本:
侯捷

譯文取自侯捷網站之先睹為快

侯捷 2002/04/17
Joshua Bloch:訪談關於設計

Joshua Bloch: A conversation about design

[內容摘要]

Bill Venners最近訪問位於Santa Clara, Calif.的昇陽(Sun Microsystems)學院的Joshua Bloch,Josh是昇陽Java核心平台群組的建構師(Architect)。在訪談中,Josh說明對於API設計、XP、程式碼品質及再使用、重整(refactoring)、 保護複製(defensive copies)及客戶程式設計師應該被信任的範圍等等有獨到的見解。

Bill Venners Areca Chen 2002/01/14
重複的程式碼(Duplicate Code)

[內容摘要]

關於程式碼重複最著名的單詞是 Kent Beck 的 Once And Only One,也就是說軟體操作的任何一個片斷--不管是一個演算法,一個常數集合,用於閱讀的文件或者其他東西--應當只出現一次。
 

軟體重複出現至少會導致以下問題

  • 其中的一個版本會過期。

  • 程式碼的責任會四處散開,導致程式碼難以理解。

  • 當你修改程式碼時,需要重複修改很多地方,一不小心就會遺漏。

  • 你不能很好地進行性能優化。

石一楹

網站:
ERP 之道

 

朱子 2001/11/14
重整:一個令人驚奇的技術之優缺點

(Refactoring Benefits and Disadvantages of an Amazing Technique)

[內容摘要]

甚麼是好的程式碼?甚麼又是壞的 程式碼?如何才能開發出好的程式碼?Refactoring提出了個新的解決方案。

Michael Hunger

Areca Chen 2001/11/30

測試(Test)

標題&內容摘要 資料來源&作者 轉譯校稿 發表日期
測試入門

[內容摘要]

在開發程式的過程中,大多數的時間是花在測試上,作為一個測試工具,JUnit 是個好的開始,它本身其實不難,但難在如何落實測試,大多數的時間中,我們仍習於先撰寫好程式,然後運行它並觀看結果來除錯,能夠撰寫測試程式已屬難能可貴,真正能作到測試驅動(Test-Driven)的就更加稀有了。

無論如何,測試是必要的,然而要改變開發人員那種近乎與生俱來的不良測試習慣,則是需要教育的。JUnit 不僅是個測試工具,還是個教育工具,您要學習的是背後的單元測試與測試驅動概念,而不僅僅是如何使用 JUnit 中的工具類別。

為了鼓勵人們進行測試,幾乎所有的測試工具其官方網站都有豐富的文件資源,您可以善用這些資源,這邊的文件是我對測試相關議題的一些簡單整理,目的是為一些想瞭解如何進行測試的新手引個開頭。

良葛格 良葛格 2005/02/20
如何自動測試使用者介面?

[內容摘要]

XP這套方法開始普遍受到軟界的重視之後,許多軟體開發者為了實現自動化測試的目標,開發了許多工具。JavaProgrammer建立了一個叫作JUnit類別,若繼承此類別來實作測試程式,就可以用測試軟體來批次執行所有的JUnit。這種方法主要是用來測試軟體的Logic,但對於GUI的測試要如何進行呢?Test-Driven Development In .Net,這篇文章有提到必須為每個GUIView Class實作存取資料用的Interface,細節請參考該篇文章。這種做法對於擁有許多視窗介面的軟體來說,要撰寫的測式程式想必就很繁瑣。

光桀

2004/08/20
全資料驅動自動測試
Totally Data-Driven Automated Testing

[內容摘要]

為什麼要自動化測試、錄製/播放有什麼問題、有哪些是有效益的自動化測試方法?本文的目的是跳脫學術理論,透過作者本身的經驗,以更直覺、忠實的態度來討論自動化測試的議題,讓讀者能夠清楚的瞭解,要成功實施符合成本效益的自動化測試,到底需要哪些條件的配合。

Keith Zambelich
Sr. Software Quality Assurance Analyst, Automated Testing Evangelist
oldsidney 2004/08/07
自動化測試不是銀質子彈 ( Silver Buller )?
Automated Testing:A Silver Bullet?

[內容摘要]

自動化測試 - 或者說是實施自動化測試的策略與工具 - 只是測試人員工具箱 ( toolbox ) 中的一把大榔頭,在這裡我特別強調自動化測試只是工具箱中的工具,而避免提及用自動化測試來取代人工測試,因為人工測試是無法取代的。當然毫無疑問的自動化測試是很有威力的工具,只要您運用得當,工具也會為您帶來極大的好處,關鍵在於何時 ( when ) 以及如何 ( how ) 使用它。

Dawn Haynes oldsidney 2004/04/25
在.NET環境中使用Test-Driven Development(測試驅動開發方法)
Test-Driven Development In .NET

[內容摘要]

大部分的Unit Tests都是寫在主要的程式碼已經設計好、寫好之後。大部分的程式開發人員都有相同的的經驗,在主要程式碼寫好之後再來加入Unit Test是一項困難的工作,而且在時間的壓力之下Unit Test通常是第一個被跳過的步驟。

這篇文章要介紹的Test-driven development (TDD,測試驅動開發方法),其主要目的就是試圖要解決這一個問題,並且讓程式開發人員可以因此寫出更高品質的,完整測試過的程式碼。其方法就是把整個程序反轉過來,在寫主要程式碼之前就要把Unit Tests寫好。TDD是所謂的Extreme Programming(XP,終極程式寫作)裡面所提到主要Practices(實務、實作)之一,在Java陣營中採用TDD的程式開發人員為數不少,在.NET的陣營中則還只停留在很少數的文章談到如何使用TDD。

Peter Provost

周育亨翻譯

Areca Chen校稿

2003/10/04
完整生命週期型物件導向測試方法
The Full Life Cycle Object-Oriented Testing (FLOOT) Method

[內容摘要]

完整生命週期型物件導向測試 (Full-Lifecycle Object-Oriented Testing,以下簡稱 FLOOT) 方法論是一個驗證 (verify) 及確認 (validate) 物件導向軟體的測試技術集合。本文列出這個測試技術清單的目的並不是要你全部做到,只是想讓它清楚一點,讓你能選擇更多對你有幫助的技術。

Scott W. Ambler 王舜民翻譯

Areca Chen校稿

2003/7/29
單元測試實例

[內容摘要]

在目前的軟體開發程序中單元測試(unit test)的角色愈來愈重要,尤其是XP沒有單元測試其專案幾乎可以說沒有成功的機會。既使你不是使用XP開發專案,單元測試也可以提供專案的可信度及延展性。而且單元測試是由程式設計師負責撰寫,在未來程式設計師不止要撰寫程式碼,同時也要有能力撰寫單元測試。

Areca Chen Areca Chen 2002/09/25
單元測試概論

[內容摘要]

在程式設計的領域中有許多種測試單元測試只是測試中的一種所以單元測試並不保證程式是完美的。但單元測試在所有測試當中是非常重要的一種。單元測試是一種由程式設計師自行測試的工作。單元測試所測試的是其所撰寫的程式碼單元是依據其所設想的方式執行而產出合於預期的結果。就是程式碼的正確性。

Areca Chen Areca Chen 2002/09/06
測試的概念

[內容摘要]

長期以來,我所接觸的軟件開發人員很少有人能在開發的過程中進行測試工作。大部分的專案都是在最終驗收的時候編寫測試文件。有些專案甚至沒有測試文件。現在情況有了改變。我們一直提倡UML、RUP、軟件工程、CMM,目的只有一個,提高軟件編寫的質量

Eric Wang Areca Chen 2002/05/01
有關測試文章的收集

[內容摘要]

你寫程式有做測試嗎?如果你寫程式而沒有測試,你如何知道你的程式碼的結果是正確的而且符合客戶的需求。亦或是你自認是天縱英名你寫的程式絕對沒有問題,亦或是你的程式碼是讓客戶來除蟲的。

如果你寫的程式有測試,那你是如何測試的。你的測試周延嗎?為了周延程式測試你要耗費多少成本?怎樣的測試才是適當的呢?經過哪些測試你認為你的程式碼才能發行呢?

測試議題從開始有程式設計既已存在,測試也發展成一特定議題及技術。但在資源有限的限制下不是把整個測試理論皆搬到你作室就可以確保你的程式碼可以發行,其中牽涉到測試技術的運用與整合,以及在合理的成本下應有哪些測試行為。

同時在XP(eXtreme Programming)的理論中測試就佔有重要的地位,在XP中測試不只是我們原來所知的測試,同時也包含了其他的意義。

1.JUnit相關文章

  • JUnit簡介
  • JUnit入門
  • Java程式的單元測試
  • 資料庫程式碼的單元測試
  • 測試的感染:程式設師喜歡寫測試

  • 持續性整合(簡體由透明翻譯)

2.測試樣式(Test Patterns)

3.先寫測試(Test First)

  • 瞄準、射擊

4.J2EE

5.診斷Java程式碼(Diagnosing Java Code)

Areca Chen 2002/02/08

2008年08月23日 星期六