編碼冒險開始
【作者】:
David Carew（carew@us.ibm.com），電子商務體系架構設計師，IBM
Willy Farrell （willyf@us.ibm.com），電子商務體系架構設計師，IBM
Alfredo Gutierrez（fredgz@us.ibm.com），電子商務設計小組經理，IBM
2001 年 6 月
出于擔心自己的技術會逐漸削弱、軟件開發經驗會日益缺乏，IBM 頂尖技術咨詢小組考慮過一起放棄咨詢而恢復開發組織，在開發組織中他們就可以恢復他們的編程兵工廠的勇氣。他們決定拿起自己的長劍，正面與那些“龍”搏斗 —通過開發他們自己的 Web 應用。這些屠龍者不是用亞瑟神劍（Excalibur），而是用極端編程來設計、開發和測試集成了最新技術、使用了 IBM 工具和產品的應用。 Go-ForIt 系列的第 1 篇（即本文）為 DragonSlayers 的故事和使他們的咨詢職業恢復活力的 Go-ForIt 應用搭建了舞臺。
本文討論了我們的 Developer Relations Technical Consulting 小組負責的項目的幾個方面。使用極端編程（eXtreme Programming，XP），我們用 IBM開發工具和技術為一個假想的公司 Go-ForIt.com 構建一個 Web 應用。我們討論 Go-ForIt 項目的起因，包括負責這個項目的方式，以及項目目的和目標。我們還提供在手上的這個項目中構建的應用的高級概述。
Go-ForIt 項目的主要目的是將我們的經驗和我們所學到的知識歸納一下。在這個系列中我們將共同分享那些經驗和獲得的知識，本文是這個系列中的第一篇。后面的文章將詳細說明為這個 Web 應用開發的組件、對體系結構和設計決定的討論以及我們在開發過程中得到的教訓。
為何我們被稱作 DragonSlayers（屠龍者）
Developer Relations Technical Consulting 小組使用 IBM 軟件工具和技術為 IBM 的商業伙伴提供體系結構、集成和咨詢支持。我們的任務可概括為 4個 E：Excite（激勵）、Evangelize（宣傳）、Educate（教育）和 Enable（提供能力）。我們通過展示和演講活動激勵開發者對 IBM 提供的產品感興趣。宣
IBM 版的，開發的，基于標準的開發。我們提供關于 IBM 軟件的正規教育。我
通過電話和 Web 方式的咨詢以及現場咨詢使開發者能夠使用 IBM 工具和技術。
當小組或其中一個小組成員解決了一個極端困難的問題，或（通過給予培訓和能力支持，使他們在開發中節省了時間和精力）使一個客戶特別高興時，我們作為一個小組會特別慶祝一番。我們開始把這種杰出的工作稱為殺死了一條“龍”，不久我們就給自己起了 DragonSlayers（屠龍者）這個綽號。
所有的 DragonSlayers都是程序員，我們在軟件開發方面的數年經驗在我們的工作中起到了很突出的作用。為使我們的商業伙伴取得成功，我們不能只告訴他們我們的產品怎么樣，以及他們應該使用這些產品的原因，我們還必須一針見血地從技術角度詳細告訴他們使用方法。只有程序員才能有效地將使用方法與另一個程序員聯系起來。
對我們來說，另一個關鍵因素是學習。如果我們要教會我們的商業伙伴，我們就必須是行家。軟件技術正在快速發展，且發展速度之快可能是前所未有的，這是顯然的且千真萬確的。DragonSlayers 不斷受到挑戰，要跟上并維持他們在工具、技術以及出自實驗室的標準方面的專門技術。這意味不僅僅要閱讀技術手冊，還有付出更多的努力，因為我們都知道閱讀技術手冊不會使人成為專家。您必須實際使用工具和技術。我們花費了相當多的時間和精力，親自動手去了解每種新產品或新版本的細微差別和復雜性。
冒險的業務
隨著越來越多的公司采用IBM的電子商務框架和連帶的服務工具和技術，我們組也逐漸成長以滿足那些公司的支持需求，我們面臨著有沒有能力持續提供我知道自己必須提供的高級咨詢的冒險。
第一個冒險是要使自己的技術和知識增長的足夠快，能夠一直領先于客戶。我們在獲取實際經驗方面所花費的時間和精力與我們的客戶天天使用這些產品所獲得的經驗無法相比。我們的客戶過去開發大型、復雜的系統，推進了他們用于構建那些系統的 IBM 產品性能的提高。我們的主要任務是帶領、指導我們的客戶，但我們卻要冒這個角色可能失敗的冒險，因為我們的客戶已經變得比我們對那些工具和技術更熟練。
下一個冒險與我們員工的整體軟件開發經驗有關。我們知道，除技術上的技巧和能力外，軟件開發也必需過程和方法。它包括分析和設計，團隊合作，以及，也可能是最重要的一點，作為一個為緊迫的商業問題提供技術解決方案的功能系統的所有者而感到自豪。我們從事咨詢業務的時間越長，我們的“真實”軟件開發經驗衰退得越厲害。
這導致我們要面對最終的冒險 — 我們的組成員對最前面描述的兩種冒險的響應。一些，大多數，甚至全部組成員最終都會離開這個組，而加入開發組織去獲取他們感覺自己需要的技巧和經驗，這種情況已變得明顯起來。于是相當多的努力花費在了補充新成員和小組培訓上，我們不想失去我們的任何有價值的人。
解決方案：Go-ForIt.com
一天晚上，當我們在當地一個酒吧討論這些冒險時，我們想到了解決這個問題的方案。我們相信承擔一個“真實的”開發項目會有助于我們解決和盡量減少面臨的冒險。我們一致認為，我們的項目：
#規模和涉及范圍必須大到需動用 Technical Consulting 小組的所有成員
#必須不是將來要投入生產的應用
#但是，必須象實際問題的實際解決方案一樣現實可信
#必須有助于在其實現中使用大部分的面向電子商務產品和技術的 IBM 框架，還必須是我們的客戶的問題和解決方案的典型代表
#必須是無限度的，要不斷改進和加強
關于第二個標準有一些爭議，但最終，我們知道我們的任務是支持 IBM 的商業伙伴，我們不希望造成我們的應用的用戶和我們的實際客戶之間的沖突。
我們構思的項目是為一個假想的公司 Go-ForIt.com 開發一個 Web 站點。Go-ForIt.com 是一個個人差使服務�？蛻艨稍谶@個站點注冊，并發送他們需要完成的差使；例如，收拾該洗的衣服，遛狗，排隊等待許可證，等等。獨立的承包者，比如知名的個人助理（ Personal Assistants，PA）也會在這個站點注冊并對發送的差使投標。Go-ForIt 將把勝出的投標者與需要服務的客戶配在一起，并按完成差使的報酬的一定百分比收取費用。
我們知道，作為一個商業模型，Go-ForIt.com 將把自己歸為 .com 類，這個滑稽得不得了的 .com 在去年都快破產了，但我們的重點是在技術方面，我們相信這個應用會符合我們的標準。
我們的主要目標是獲取有現實意義的軟件經驗，但我們意識到 Go-ForIt.com 還能夠幫助我們達到小組的另外兩個重要的目標。第一，我們會從這個項目中獲得大多數或全部的課程資料，第二，我們可以經常抽取提出的問題、提示和技巧、技術論文和其它的技術內容與軟件開發社區共享。
誰的錯都不是
為實現我們的思想，我們制定了一套原則來表明我們的項目的基調和指導思想，如下所示：
#關于這項目的每件事情都是開誠公布的、理由充分的、經過深思熟慮的，即使這些原則也是如此。組中的每個成員都有義務對自己不理解的或認為不正確的決定提出疑問。
#我們不要忘記我們的主要任務是支持我們的客戶。這個任務優先于其它任何事情，包括這個項目。畢竟，我們從事這個項目也是為了獲得技巧和經驗，以便能夠更好地支持我們的客戶。
#但是，我們不會將這個項目當作業余的或隨意的活動來對待。我們將把這個項目的各種分配、進度表、截止期限等等當作我們想要實際部署的真實項目一樣認真對待。
#關于這個項目的一切都作為實際項目來建立和管理，包括配置管理、編碼標準、進度表、截止期限、文檔編制、集成測試、驗收測試、緊急錯誤修復、性能測試和調優，等等，要一直牢記原則 #2。
#我們將使用極端編程（XP）作為開發過程。XP 是一種嚴格按照要求進行的軟件開發方法，它接受更改（認為這是不可避免的），并相應地制定計劃。我們選擇 XP不是因為它新而且簡潔，而是因為它能解決我們在這個項目中面臨的困難。它被設計用于模糊而迅速地更改要求，提倡較短的開發周期以便最大程度地學習，并要求持續測試和重編代碼以確保其正確性。我們的客戶正在評估XP；有些客戶可能已經在使用XP。XP 是軟件開發上的重大改革，我們應該具有 XP方面的經驗，以便能夠聰明地與我們的客戶進行探討。
#這個項目不必根據委員會意見或經一致同意才運行。組中的一個人將擔任這個項目的經理，從而負責這個項目的管理決定。組中的一個成員將擔任這個項目的體系架構設計師，并負責所有的技術決定。組中的一個成員將充當客戶，負責所有的業務決定。整個組將作為一個戰略家，負責這個項目中將包括 IBM的什么產品和技術的所有決定。
這條原則和原則 #1 并不沖突。一切都是可以自由挑戰、自由提問和自由辯論的。但有時候，必須做出決定才能前進。委員會是出了名的喜歡通過冗長的討論來拖延和推遲決定。我們沒有時間那樣做。但是，我們計劃過一段時間在小組成員之間輪換一下角色，這樣所有的成員都能得到軟件開發不同方面的經驗。
#沒有任何小組成員將變成這個項目的任何部分的專家或這個項目所使用的任何產品和技術方面的專家。任何小組成員都不得以缺乏經驗為借口，拒絕從事項目的任何部分，或這個項目所使用的產品和技術。沒有任何人被指定為只負責“思考”。每個人都要編寫代碼。這里沒有 HTML 專家、Java 專家、JSP專家等等，我們爭取讓所有的成員都得到盡可能廣泛的經驗。這個項目歸集體所有，但是每個成員都應該把自己當做整個項目的主人翁。
#無論何時出現了問題，誰的錯都不是。這個原則是 XP哲學的一部分（適合我們的情況）。出現問題時（問題是不可避免的），自然的反應就是指責某個人。但指責是沒什么用的。我們需要做的是修正問題，至于是誰的錯誤真的并不重要。所以，無論何時出現了問題，我們都不要抱怨任何人，要趕快著手修正問題。
我們已經制定出了這些原則，并把這些思想形成了建議，呈交給喜歡這些思想并很快批準這些建議的管理部門。然后我們將這些建議向整個組公布，并召開了一次會議回答所有的問題，說明大家關心的每個問題。接著，對涉及的所有成員進行了幾次 XP 培訓，并于 2001 年 1 月開始著手這個項目。
Go-ForIt.com 應用
這部分描述了 Go-ForIt.com 應用，但仍在相當高的級別上。后面的文章將深入到項目開發的細節問題。
為開始構建 Go-ForIt 應用，并使 XP 模型盡可能真實，我們指定 4 個小組成員作為客戶。他們提出一套用戶情景（User Storie）。用戶情景是從客戶角度出發的要求，包含極少或不包含實現細節問題。他們代表客戶將如何使用這個系統的觀點。為保持事情易于管理并避免個人情景太長、太復雜（我們的客戶小組中的某些成員一向以小題大作出名），我們要求每個情景寫在一張 3x5 開的索引卡片上。情景一旦被定義，我們就開始把每個情景分解成一組任務，然后實現這些任務。（您可以看到情景的完整列表以及它們的當前實現狀態。）
設計指導思想
我們用從零開始實現用戶情景。但是，我們的確有一套大家都遵守的通用設計原則。這些原則是在用戶對商家（User-To-Business）模式的指導下制定出來的，這種模式是IBM電子商務模式的一部分，有一組可重用的資源，有助于加快電子商務應用的開發速度。
這些原則如下所示：
#我們使用 Java 編程語言（組中有人建議使用 Perl，結果不得不在重重保衛下才安全走出房間）。
#用戶界面（UI）是基于 Web 的。
#UI 的靜態部分是用 HTML 實現的。
#UI 的動態部分實現為 JSP 頁面。
#持久數據（例如，用戶信息、差使請求信息）表現為容器管理持久性（Container Managed Persistence）實體 bean。
#實體 bean之間的關系（例如，指出某個差使請求是某個特定客戶發出的）是用關聯處理的
#用戶的所有行為都是由 servlet 處理的，servlet 先調用相應會話 bean上的適當方法，然后再調用適當的 JSP 頁面向用戶返回行為的結果。
#通過開發一個命令 bean 簡化了到會話 bean 的 Servlet 接口，命令 bean是一個簡單的 JavaBeans 組件，帶有 setXXX()方法（用來提供用戶供應的數據），一個不帶參數的 execute() 方法（用來執行任務）和 getXXX()方法（用來提供結果（如果有的話））。命令 bean 拋出異常來指明錯誤情況。
#會影響持久數據的任務（例如，添加用戶、更新用戶信息）由 EJB 會話 bean上的方法來表示。
#簡單的用戶輸入驗證（例如，驗證一個電話號碼格式是否正確，或驗證是不是已經輸入了所有必需的輸入）用客戶端的 JavaScript 來完成。
#這個應用可配置在任何支持 WebSphere 應用服務器的硬件平臺上。
開發工具
我們使用下列工具開發 Go-ForIt：
#WebSphere Studio 3.5 高級版用來開發 HTML 頁面、JavaScript 和JSP。
#VisualAge for Java 3.5 企業版用來開發所有的服務器端代碼：EJB、servlet和與它們相關的助手類。實體 EJB 之間的關聯使用 VisualAge for Java中的持久性構建工具（Persistence Builder Tool）完成。
#VisualAge for Java 3.5 Team Server管理開發小組中的成員共用的一個資源庫。
關于在 XP 環境下使用 VisualAge for Java 的更多信息，請參閱參考資料。
測試
XP的基本要求之一是每個項目應該有一套綜合的自動測試，測試可能出錯（帶有自然反應的可能異常）的任何東西。當我們發現錯誤時，我們編寫測試案例來找到錯誤并在修正此錯誤之前將其添加到套件中。關于在 XP 中進行測試的更多信息，請參閱 eXtremeProgramming: Deceptively simple innovation。
我們使用 JUnit 測試框架（請參閱參考資料）為我們的 EJB 組件、命令 bean 和其它所有相關的助手類編寫合適的測試案例。
結論
Go-ForIt.com 項目已經開始實現我們的目標了 —保持技能和共享技術信息。為保持和增加咨詢小組的技能深度，我們正在關注 Go-ForIt項目的相關發展領域（即我們的商業伙伴的發展領域）。有了這些相關技能，我們就能夠完成我們這個組織的任務的一半— 教育（educate）我們的客戶，提高他們的能力（enable）。但是，我們沒有忘記我們的 4 個 E 的另一半 —
激勵（excite）我們的客戶并向他們宣傳（evangelize）。所以，當 IBM 向我們的商業伙伴介紹并推薦新技術時，Go-ForIt 項目也會反映這些新技術。Go-ForIt 測試技術的有效性，并使我們的顧問能夠說出它的可靠之處。
我們正在發掘 Go-ForIt 項目中的技術信息，用來共享：“使用指南”文章、樣本代碼、相關主題的課程、常見問題的解答以及優秀教材（Mentored Workshop）的素材。朝著這些目標，目前為止Go-ForIt已經是相當成功了。然而，通過咨詢小組堅定不懈的努力，Go-ForIt 已經越來越引人注目，這里特寫的是第二次修訂版，其中學到的教訓可與IBM商業伙伴和個人開發者共享，并被他們使用。
在后面的幾周或幾個月中，我們將把從 Go-ForIt 得到的經驗歸檔，并與您共享。我們將討論我們是如何如何開發各種組件的，我們做出的設計決定以及在此過程中遇到的陷阱和取得的成功。讓我們休息一下，回味一下這個過程。我們已經從這次編碼冒險中學到，并將繼續學習許多東西，我們期望聽取來自開發者社區的意見：我們所做的哪些是錯的，哪些是對的，以及您自己在電子商務應用開發領域的經驗或 XP 方面的經驗。
參考資料
參與本文的討論論壇。
閱讀 Go-ForIt 系列的第 2 篇文章，了解為什么 DragonSlayers選擇用極端編程來與開發他們的 Web 應用過程中的困難作斗爭。
研究 IBM 電子商務模式，它預先建立了用于創建和實現大型集成系統的設計。
訪問 JUnit 站點，獲取關于 JUnit 開放源代碼回歸測試（regression
testing）框架的信息，該框架使得在 Java 中進行單元測試成為可能。
通過本文學習在 IBM VisualAge for Java 中進行極端編程，這篇文章出自 IBMDeveloperToolbox。 重溫 Go-ForIt 應用的用戶情景（客戶要求）。
解決方案 2001 提供了下列相關的會議：
Roadmap to Architecting e-business with IBM WebSphere Programming Model Best Practices for HttpServlets and JavaServer Pages
WebSphere Programming Model Best Practices for Enterprise JavaBeans
Hands-on: VisualAge for Java Version 3.5.3
【關于作者】
David Carew 是位于美國德克薩斯洲，奧斯汀的 IBM Developer Relations Technical Consulting 公司的電子商務體系架構設計師，該公司為 IBM 商業伙伴提供教育、實現和咨詢。他于 1988 年加入 IBM，已經擔任過開發工作中的各種不同職務，從編寫代碼到控制工業機器人，到為 AIX 廣域網設備編寫設備驅動程序。在學習 Java 的過程中，他取得了位于奧斯汀的德克薩斯洲大學的 MBA 學位，開始為 Developer Relations 做咨詢。David 是經過 Sun 認證的 Java 程序員、經過認證的 Java 開發者，還是經過認證的 Java 技術設計師。您可以通過 carew@us.ibm.com 與他聯系。
Willy Farrell 是位于美國德克薩斯洲，奧斯汀的 IBM Developer RelationsTechnical Consulting 小組的首席電子商務體系架構設計師，該公司為 IBM商業伙伴提供教育、實現和咨詢。他從 1980 起就以從事計算機編程為生，從 1996開始使用 Java，并于 1998 年加入 IBM。Willy 持有下列技術證書（另外還有其它證書）：Java Programmer、VisualAge for Java Solution Developer、MQSeriesSolutions Expert、WebSphere Application Server Solution Developer、XMLDeveloper 和 IBM e-business Solution Technologist。您可以通過 （willyf@us.ibm.com）與 Willy 聯系。
Fred Gutierrez 擁有令人敬畏的特權，負責咨詢小組的整體方向，這個小組冒險殺死了 IBM 商業伙伴的應用中經常出沒的“龍”。他于 1987 年加入了IBM，同時進入加州大學深造。他所在的工作組開發了在線教育，與 AS/400 系統預包裝在一起（對那些不象 Fred 那么老的人來說即是 iSeries）。Fred 從 GSU 獲得會計學學位畢業后，IBM 將他派到 Boca Raton 去開發關于 OS/2 應用開發的課程和紅皮書。1994 年他鴻運當頭，被調到世界生活音樂之都（奧斯汀，德克薩斯州）繼續同樣的工作。Fred 于1997 加入了電子商務“體系結構和集成”小組，擔任顧問，并繼續涉足技術，當時他只能與他們小組中的其它成員進行簡短的會話。記住一點 — 在加入IBM 之前，Fred 是德克薩斯公共安全（Public Safety）部門的一個公路巡警。請通過（fredgz@us.ibm.com）與他聯系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
