出版時(shí)間:2003-09-01 出版社:清華大學(xué)出版社 作者:Robert C. Martin 頁數(shù):476 譯者:鄧輝
Tag標(biāo)簽:無
內(nèi)容概要
在這本書中,享譽(yù)全球的軟件開發(fā)專家和軟件工程大師Robert C.Martin將向您展示如何解決軟件開發(fā)人員、項(xiàng)目經(jīng)理及軟件項(xiàng)目領(lǐng)導(dǎo)們所面臨的最棘手的問題。這本綜合性、實(shí)用性的敏捷開發(fā)和極限編程方面的指南,是由敏捷開發(fā)的創(chuàng)始人之一所撰寫的。
·講述在預(yù)算和實(shí)踐要求下,軟件開發(fā)人員和項(xiàng)目經(jīng)理如何使用敏捷開發(fā)完成項(xiàng)目;
·使用真實(shí)案例講解如何用極限編程來設(shè)計(jì)、測(cè)試、重構(gòu)和結(jié)對(duì)編程;
·包含了極具價(jià)值的可多次使用的C++和JAVA源代碼;
·重點(diǎn)講述了如何使用UML和設(shè)計(jì)模式解決面向客戶系統(tǒng)的問題。
作者簡(jiǎn)介
Robert C.Martin是Object Mentor公司的總裁。Martin和他的軟件咨詢隊(duì)伍使用面向?qū)ο笤O(shè)計(jì)、模式、UML、敏捷方法學(xué)和極限編程,在世界各地都有他們的客戶。他還是好幾本暢銷書的作者。他還是1996-1999年《C++ Report》雜志的總編,并多次在國(guó)際會(huì)議和展覽中發(fā)表富有特色的演講。
書籍目錄
第Ⅰ部分 敏捷開發(fā) 第一章 敏捷實(shí)踐 1.1 敏捷聯(lián)盟 1.2 原則 1.3 結(jié)論 參考文獻(xiàn) 第二章 極限編程概述 2.1 極限編程實(shí)踐 2.2 結(jié)論 參考文獻(xiàn) 第三章 計(jì)劃 3.1 初始探索 3.2 發(fā)布計(jì)劃 3.3 迭代計(jì)劃 3.4 任務(wù)計(jì)劃 3.5 迭代 3.6 結(jié)論 參考文獻(xiàn) 第四章 測(cè)試 4.1 測(cè)試驅(qū)動(dòng)的開發(fā)方法 4.2 驗(yàn)收測(cè)試 4.3 結(jié)論 參考文獻(xiàn) 第五章 重構(gòu) 5.1 素?cái)?shù)產(chǎn)生程序一個(gè)簡(jiǎn)單的重構(gòu)示例 5.2 結(jié)論 參考文獻(xiàn) 第六章 一次編程實(shí)踐 6.1 保齡球比賽 6.2 結(jié)論第Ⅱ部分 敏捷設(shè)計(jì) 第七章 什么是敏捷設(shè)計(jì) 7.1 軟件出了什么錯(cuò) 7.2 設(shè)計(jì)的臭味——腐化軟件的氣味 7.3 “Copy”程序 7.4 保持盡可能好的設(shè)計(jì) 7.5 結(jié)論 參考文獻(xiàn) 第八章 單一責(zé)任原則(SRP) 8.1 單一職責(zé)原則(SRP) 8.2 結(jié)論 參考文獻(xiàn) 第九章 開放—封閉原則(OCP) 9.1 開放—封閉原則(OCP) 9.2 描述 9.3 關(guān)鍵是抽象 9.4 結(jié)論 參考文獻(xiàn) 第十章 Liskov替換原則(LSP) 10.1 Liskov替換原則(LSP) 10.2 一個(gè)違反LSP的簡(jiǎn)單例子 10.3 正方形和矩形,更微妙的違規(guī) 10.4 一個(gè)實(shí)際的例子 10.5 用提取公共部分的方法代替繼承 10.6 啟發(fā)式規(guī)則和習(xí)慣用法 10.7 結(jié)論 參考文獻(xiàn) 第十一章 依賴倒置原則(DIP) 11.1 依賴倒置原則(DIP) 11.2 層次化 11.3 一個(gè)簡(jiǎn)單的例子 11.4 熔爐示例 11.5 結(jié)論 參考文獻(xiàn) 第十二章 接口隔離原則(ISP) 12.1 接口污染 12.2 分離客戶就是分離接口 12.3 接口隔離原則(ISP) 12.4 類接口與對(duì)象接口 12.5 ATM用戶界面的例子 12.6 結(jié)論 參考文獻(xiàn)第Ⅲ部分 薪水支付案例研究 第十三章 COMMAND模式和ACTIVE OBJECT模式 第十四章 TEMPLATE METHOD模式和STRATEGY模式:繼承與委托 第十五章 FACADE模式和MEDIATOR模式 第十六章 SINGLETON模式和MONOSTATE模式 第十七章 NULL OBJECT模式 第十八章 薪水支付案例研究:第一次迭代開始 第十九章 薪水支付案例研究:實(shí)現(xiàn)第Ⅳ部分 打包薪水支付系統(tǒng) 第二十章 包的設(shè)計(jì)原則 第二十一章 FACTORY模式 第二十二章 薪水支付案例研究(第2部分)第Ⅴ部分 氣象站案例研究 第二十三章 COMPOSITE模式 第二十四章 OBSERVER模式——回歸為模式 第二十五章 ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式 第二十六章 PROXY模式和STAIRWAY TO HEAVEN模式:管理第三方API 第二十七章 案例研究:氣象站第Ⅵ部分 ETS案例研究 第二十八章 VISITOR模式 第二十九章 STATE模式 第三十章 ETS框架附錄 附錄A UML表示法Ⅰ:CGI示例 附錄B UML表示法Ⅱ:統(tǒng)計(jì)多路復(fù)用器 附錄C 兩個(gè)公司的諷刺小品 附錄D 源代碼就是設(shè)計(jì) 索引
章節(jié)摘錄
7.2 設(shè)計(jì)的臭味——腐化軟件的氣味 當(dāng)軟件出現(xiàn)下面任何一種氣味時(shí),就表明軟件正在腐化?! 〗┗裕≧igidity):很難對(duì)系統(tǒng)進(jìn)行改動(dòng),因?yàn)槊總€(gè)改動(dòng)都會(huì)迫使許多對(duì)系統(tǒng)其他部分的其他改動(dòng)。 脆弱性(Fragility):對(duì)系統(tǒng)的改動(dòng)會(huì)導(dǎo)致系統(tǒng)中和改動(dòng)的地方在概念上無關(guān)的許多地方出現(xiàn)問題。 牢固性(Immobility):很難解開系統(tǒng)的糾結(jié),使之成為一些可在其他系統(tǒng)中重用的組件?! ≌硿裕╒iscosity):做正確的事情比做錯(cuò)誤的事情要困難?! 〔槐匾膹?fù)雜性(Needless Complexity):設(shè)計(jì)中包含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)?! 〔槐匾闹貜?fù)(Needless Repetition):設(shè)計(jì)中包含有重復(fù)的結(jié)構(gòu),而該重復(fù)的結(jié)構(gòu)本可以使用單一的抽象進(jìn)行統(tǒng)一 ?;逎裕∣pacity):很難閱讀、理解。沒有很好地表現(xiàn)出意圖。 1.僵化性 僵化性是指難以對(duì)軟件進(jìn)行改動(dòng),即使是簡(jiǎn)單的改動(dòng)。如果單一的改動(dòng)會(huì)導(dǎo)致有依賴關(guān)系的模塊中的連鎖改動(dòng),那么設(shè)計(jì)就是僵化的。必須要改動(dòng)的模塊越多,設(shè)計(jì)就越僵化。 大部分的開發(fā)人員都以這樣或者那樣的方式遇到過這種情況。他們會(huì)被要求進(jìn)行一個(gè)看起來簡(jiǎn)單的改動(dòng)。他們看了看這個(gè)改動(dòng)并對(duì)所需的工作做出了一個(gè)合理的估算。但是過了一會(huì)兒,當(dāng)他們實(shí)際進(jìn)行改動(dòng)時(shí),會(huì)發(fā)現(xiàn)有許多改動(dòng)帶來的影響自己并沒有預(yù)測(cè)到。他們發(fā)現(xiàn)自己要在龐大的代碼中搜尋這個(gè)變動(dòng),并且要更改的模塊數(shù)目也遠(yuǎn)遠(yuǎn)超出最初估算。最后,改動(dòng)所花費(fèi)的時(shí)間要遠(yuǎn)比初始估算長(zhǎng)。當(dāng)問他們?yōu)楹喂浪愕萌绱瞬粶?zhǔn)確時(shí),他們會(huì)重復(fù)軟件開發(fā)人員慣用的悲嘆,“它比我想像的要復(fù)雜得多!” 2.脆弱性 脆弱性是指,在進(jìn)行一個(gè)改動(dòng)時(shí),程序的許多地方就可能出現(xiàn)問題。常常是,出現(xiàn)新問題的地方與改動(dòng)的地方并沒有概念上的關(guān)聯(lián)。要修正這些問題就又會(huì)引出更多的問題,從而使開發(fā)團(tuán)隊(duì)就像一只不停追逐自己尾巴的狗一樣(忙得團(tuán)團(tuán)轉(zhuǎn))?! ‰S著模塊脆弱性的增加,改動(dòng)會(huì)引出意想不到的問題的可能性就越來越大。這看起來很荒謬,但是這樣的模塊是非常常見的。這些模塊需要不斷地修補(bǔ)——它們從來不會(huì)被從錯(cuò)誤列表中去掉,開發(fā)人員知道需要對(duì)它們進(jìn)行重新設(shè)計(jì)(但是誰都不愿意去面對(duì)重新設(shè)計(jì)中的難以琢磨性),你越是修正它們,它們就變得越糟?! ?.牢固性 牢固性是指,設(shè)計(jì)中包含了對(duì)其他系統(tǒng)有用的部分,但是要把這些部分從系統(tǒng)中分離出來所需要的努力和風(fēng)險(xiǎn)是巨大的。這是一件令人遺憾的事,但卻是非常常見的事情?! ?.粘滯性 粘滯性有兩種表現(xiàn)形式:軟件的粘滯性和環(huán)境的粘滯性?! ‘?dāng)面臨一個(gè)改動(dòng)時(shí),開發(fā)人員常常發(fā)現(xiàn)會(huì)有多種改動(dòng)的方法。其中,一些方法會(huì)保持設(shè)計(jì);而另外一些會(huì)破壞設(shè)計(jì)(也就是生硬的手法)。當(dāng)那些可以保持系統(tǒng)設(shè)計(jì)的方法比那些生硬手法更難應(yīng)用時(shí),就表明設(shè)計(jì)具有高的粘滯性。做錯(cuò)誤的事情是容易的,但是做正確的事情卻很難。我們希望在軟件設(shè)計(jì)中,可以容易地進(jìn)行那些保持設(shè)計(jì)的變動(dòng)?! ?/pre>媒體關(guān)注與評(píng)論
書評(píng)第13屆軟件開發(fā)震撼大獎(jiǎng)獲獎(jiǎng)作品;國(guó)際軟件工程和開發(fā)大師最新力作;眾多名家一致推薦的敏捷開發(fā)指南;軟件工程發(fā)展史上的里程碑性巨著。希望你能喜愛這本書。希望你能像我一樣學(xué)著以創(chuàng)建美的軟件而驕傲,并享受其中的快樂。如果你從本書中略微看到了這種快樂,如果本書使你感受到了這種驕傲,如果本書點(diǎn)燃了你內(nèi)心欣賞這種美的火花,那么就遠(yuǎn)超過我的目標(biāo)了。圖書封面
圖書標(biāo)簽Tags
無評(píng)論、評(píng)分、閱讀與下載
- 還沒讀過(66)
- 勉強(qiáng)可看(483)
- 一般般(824)
- 內(nèi)容豐富(3417)
- 強(qiáng)力推薦(280)