重構極限編程：XP的實踐與反思

定　價：￥39.00

作　者：	（英）Matt Stephens，（美）Doug Rosenberg著；汪豐，趙浩等譯；汪豐譯
出版社：	清華大學出版社
叢編項：
標　簽：	極限編程

購買這本書可以去

ISBN：	9787302095293	出版時間：	2005-06-01	包裝：	膠版紙
開本：	26cm	頁數(shù)：	305	字數(shù)：

內容簡介

　　在開始之前，我們想請讀者注意本書一些非常獨特的元素。這不是一本普通的，一般性的計算機科學類的書籍！我們感覺這樣一個主題適合采用諷刺的手法，因此我們下決心賦予它這樣的風格。除諷刺之外，還有許多冷靜的幽默。我們有時確實變得嚴肅，并對了極限編程（XP）固有缺陷和危險進行認真的系統(tǒng)分析。說到這一點，這本書并非完全“抨擊”XP的一部著作。正如后面指出的，不是所有XP都是糟糕的。我們打算提供一個中肯的批評，并指出XP中可以被搶救或重構的部分，以更加健壯的方式實現(xiàn)同樣敏捷的目標。XP受到了名不副實的炒作，并且新的XP書籍繼續(xù)以難以置信的速度出版。圍繞XP惡性膨脹的呼聲從各方面影響了產(chǎn)業(yè)界（有些是正面的，如同我們探求的，但大多數(shù)是負面的）。有鑒于此，我們感覺一本逆著XP浪潮，抵制XP的書是重要的。這里有一個小例子，說明XP如何影響業(yè)界。Matt（本書勇敢無畏的共同作者）收到來自一位顧問的電子郵件，這位顧問最近失去了一份重要合同，因為他拒絕在沒有首先進行一些詳細的需求分析和預先設計之前啟動項目?？蛻敉ㄟ^閱讀知道XP編程，他告訴那位顧問：“即然XP認為以那種方式啟動項目沒有問題，那么我們將找到跳過需求和預先設計而直接啟動項目的人！” 雖然一些業(yè)務人員聽說XP后，立刻陷入瘋狂（像上面的顧問故事提示的那樣），但仍有一些人立場堅定，拒絕變化。實際上，想要將XP引入其組織的團隊面對的一個主要問題是，XP要求在整個組織中有顯著的思想改變，從團隊的組織方式到公司與客戶做業(yè)務的方式。本書分析了XP的缺點，并提出一種可選擇的實現(xiàn)敏捷性的方法，與XP相比，它對現(xiàn)有組織要求少得多的變化，同時仍然保留了XP的敏捷目標。您能使用這一“可選擇的方法”作為藍本來設定自己的敏捷方法學（本書臨近結尾處提供了一些指針，指向我們感覺比XP更為嚴謹?shù)钠渌艚葸^程）。然而，本書最重要的目的是打碎一些緊隨XP浪潮開始出現(xiàn)的神話，譬如無需記錄工作的神話，一位現(xiàn)場客戶和一些自動化測試足以替代書面需求規(guī)范的神話，以及個人的需要和舒適是項目次要元素的神話（即，“和我們結對編程或另謀高就”）等。并且我們打算以娛樂和幽默的方式來實現(xiàn)我們的目的，因為……很好，因為相關的主題要求這樣。讀者對象： XP經(jīng)常由程序員引入組織。這毫不奇怪，因為XP是“對程序員非常友好的”方法。它提升了程序員的作用（本質上不是一件壞事），并把他們置于與客戶齊舞的水平。因此，如果您是經(jīng)理或客戶，正被兜售在下一個項目中使用XP的想法，本書提供了一個頗有價值的反面觀點。如果您是將XP引入組織的程序員，本書應該對您有所幫助，因為它概述了XP的許多危險，它們可能是潛在的項目殺手，而這些危險在其他有關XP的書籍中傾向于被一帶而過。如果您正在考慮剪裁XP以提取它的所有長處，但又想避免“多末諾骨牌”效應，也就是說，避免過程的一個小的變化引起整個過程崩潰，這本書提供了一些可貴的指導。

作者簡介

暫缺《重構極限編程：XP的實踐與反思》作者簡介

圖書目錄

第Ⅰ部分另一個美好的混亂第1章瘋狂的XP 11.1 理論上的極限編程 21.1.1 XP的中心前提 21.1.2 價值 31.1.3 實踐 41.1.4 活動 111.1.5 角色 131.1.6 XP的生命周期 141.2 XP面向什么問題 151.2.1 典型軟件項目中反映出的什么問題可以作為XP的目標 151.2.2 現(xiàn)有方法學中還有哪些問題可以作為XP的目標 161.3 實踐中的極限編程: XP實際經(jīng)歷的評價 161.4 先拆下，后重建 191.4.1 價值 191.4.2 活動 191.4.3 其他要素 201.5 小結 20第2章 XP誕生于何處 222.1 C3概述 242.2 XP項目的生命周期(如C3的活動所展示) 242.2.1 大肆宣傳和吹噓 252.2.2 做可能實現(xiàn)的最簡單的事 272.2.3 產(chǎn)生一個快速成功的錯覺 272.2.4 無休止的重構 292.2.5 放棄發(fā)貨! 302.2.6 取消 312.2.7 勝利和成功的聲明 322.2.8 新聞組中的困惑 342.2.9 聲明它并不那么重要 372.3 C3的問題 392.3.1 現(xiàn)場客戶的工作過于艱難 402.3.2 廚師太多 402.3.3 逐漸增加得不夠 412.3.4 開發(fā)人員偏離了正確路線 412.4 小結 42第3章反XP案例 433.1 一個自反安全網(wǎng)絡(蛇圈) 433.1.1 從合作衍變?yōu)橄笳饕饬x(symbolism) 443.1.2 生命周期還是蛇圈 473.1.3 把蛇拆散開 503.1.4 將蛇捆綁在一起：部分的XP 593.2 因此制宜XP顛倒的原因 603.2.1 邏輯性與情緒化 613.2.2 把您的鴨子固定成一排 633.3 小結 64第Ⅱ部分 XP的社會效應第4章 Extremo文化 654.1 "XP不是無節(jié)制的刪減！” 664.1.1 為什么XP實踐者們覺得XP不是真的刪減 664.1.2 把文檔丟給獅子 674.1.3 為什么在開始編碼前詳細記錄設計 674.2 XP進入主流 684.2.1 XP實踐者不做設計 694.2.2 XP實踐者不編寫文檔 704.2.3 主流世界中的XP 704.3 XP和.com的繁榮 714.4 XP作為人的過程 734.4.1 敏捷過程中的“嬉皮士“ 734.4.2 IfXPIsntWorkingYoureNotDoingXP 744.4.3 把人的過程極端化 754.4.4 XP和點心 764.4.5 XP宣言：再多些奶酪，伙計？ 774.5 XP術語 784.6 像Constantinople和TerminationCanbeSuccess 這樣的長詞 794.7 向發(fā)信人攻擊 814.8 恐懼 844.8.1 恐懼和Extremo文化 854.8.2 恐懼和Extremos 854.8.3 恐懼是C3失敗的原因嗎 884.8.4 如果您沒在做XP，那么您一定是害怕了 894.9 小結 90第5章現(xiàn)場客戶 915.1 那是客戶的問題 925.2 現(xiàn)場客戶：舊約 945.2.1 “舊約”現(xiàn)場客戶的問題 955.2.2 現(xiàn)場客戶的問題促使C3項目失敗嗎 965.2.3 警告：當一名現(xiàn)場客戶可能對健康有害 975.3 現(xiàn)場客戶：新約 995.3.1 我們能對XP客戶團隊有何期望 995.3.2 廚師太多 1005.3.3 接受度測試 1015.3.4 沒有安全保障網(wǎng)絡 1025.4 小結 103第6章結對編程 1046.1 結對編程基礎 1056.2 有項研究能證實我的觀點 1076.3 為沉默的聲音祈求 1116.4 這是一種愛的工作，卻要用強迫的手段來實行 1126.5 生產(chǎn)率：程序員數(shù)量/2==程序員數(shù)量 1146.6 結對編程說明 1216.6.1 不同類型的程序員的結對問題 1216.6.2 其他問題 1236.6.3 小心，桌子底下有蛇! 1246.7 小結 125第7章口頭文檔 1267.1 “但是我以為您的意思是……" 1277.1.1 需求文檔 1277.1.2 設計文檔 1297.2 只是無知的白癡 1327.2.1 在其位，謀其政 1337.2.2 僅稍稍超前他的時代 1337.2.3 專題小組的成員們脫離了現(xiàn)實 1357.2.4 別打擾我，我正忙著-- 去看錄像帶吧 1357.2.5 項目過程中被雇傭的新程序員會怎樣呢 1367.2.6 單元測試是文檔(是的，很對) 1377.3 小結 140第Ⅲ部分無需永久性的規(guī)范和預設計第8章先測試后設計 1428.1 當只有錘子時 1438.2 XP設計的口頭禪：沒有BDUF 1468.3 單元測試的問題 1478.3.1 面向異步消息傳遞和多線程系統(tǒng)的測試 1478.3.2 其他問題 1498.3.3 單元測試很簡單-- 客戶需要編寫那些令人討厭的接受度測試 1508.3.4 沒有安全網(wǎng)的編程 1568.4 小結 158第9章編程后的持續(xù)重構 1599.1 重構的天堂 1619.2 XP設計的口頭禪：殘忍地重構 1639.2.1 當重構有用時 1659.2.2 當重構變得簡短時 1669.3 預先設計能否完全避免后來的重大重構 1699.3.1 代碼真的就是設計嗎 1699.3.2 預先設計真的是一件壞事嗎 1709.3.3 進行多少預先設計才足夠 1729.4 在固定的用戶庫下進行重構 1749.4.1 不間斷的全面維護 1759.4.2 惹惱用戶：重構實際的用戶界面 1769.4.3 的確惹惱了用戶：破壞了他們的真實數(shù)據(jù) 1779.5 小結 180第10章用戶故事和接受度測試 18110.1 爸爸，給我講個故事 18210.2 用戶故事與用例 18510.2.1 用例 18610.2.2 什么是用例驅動的開發(fā) 18610.2.3 用例要比故事更嚴格 18810.3 用戶故事與需求 18910.3.1 需求 18910.3.2 在非XP項目中，不確定的需求是怎么處理的 19110.3.3 體系結構變化的需求 19310.4 作為接受度測試的“文檔化”需求 19310.5 小結 196第Ⅳ部分永久編碼機第11章軟件開發(fā)無止境 19711.1 進度表本身并不存在 19811.1.1 拒絕已完成的概念 19811.1.2 擁抱蔓延的項目需求范圍漸變 20111.1.3 如果不知道項目完成期限 20411.2 范圍可變的合同 20711.3 小結 213第12章緊急結構和設計 21412.1 XP設計的咒語：YAGNI 21912.2 構建緊急設計的基礎構造 22112.1 代碼有設計價值而沒有商業(yè)價值 22312.3 緊急結構與早期原型 23212.4 小結 234第13章擁抱變化 23513.1 變更成本曲線(修改錯誤成本的曲線) 23713.2 早期發(fā)布，經(jīng)常發(fā)布 23913.3 發(fā)布計劃 24113.4 迭代計劃 24213.5 永久編碼機(擁抱變化) 24313.5.1 故事變更 24413.5.2 敏捷意味著快速嗎 24413.5.3 設計變更 24513.6 變化是什么 24713.7 使用預先設計來增強敏捷性 24813.7.1 管理變化 24813.7.2 設計抽象的平衡 24913.8 小結 251第Ⅴ部分全局圖第14章可伸縮性 25214.1 問題描述：在50人的項目中使用XP方法 25314.1.1 避開實踐 25414.1.2 ATLAS規(guī)模大小項目中的緊急設計 25714.1.3 結論 25814.2 體系結構的可伸縮性 25914.2.1 可伸縮性驅動體系結構 26014.2.2 Extreme Programming Installed中的例子：病人記錄數(shù)據(jù)庫 26014.3 當XP開始失效時 26414.3.1 手寫故事卡和口頭文檔 26514.3.2 集體所有權 26514.3.3 XP教練 26514.3.4 現(xiàn)場客戶 26614.3.5 公共編碼房間 26614.3.6 緊急結構 26714.4 小結 269第15章重構XP 27015.1 如何既敏捷又不脆弱 27115.1.1 良好的敏捷過程應該減少風險 27215.1.2 良好的敏捷過程應該支持應急 27215.1.3 良好的敏捷過程應該避免脆弱性 27315.2 拔掉極限編程的毒牙：除去XP中的“極限” 27515.2.1 重構XP實踐/ Xtudes /價值/原則 27515.2.2 附加實踐 28615.2.3 交互設計師 28715.3 案例研究：服務器工具項目 28915.3.1 概述 28915.3.2 XP能滿足需要嗎 29015.3.3 框架 29215.3.4 不止一個雇主 29315.4 小結 294第16章結論：消除事實曲解的地方 29516.1 運用中的無形技巧 29616.1.1 太多瑣碎的討論 29616.1.2 微妙玄通，深不可識 29716.1.3 差建議就是差建議 29816.2 在結束之時 30216.3 結束語 304