敏捷軟件開發(fā)

內(nèi)容概要

在這本書中，享譽全球的軟件開發(fā)專家和軟件工程大師Robert C.Martin將向您展示如何解決軟件開發(fā)人員、項目經(jīng)理及軟件項目領(lǐng)導們所面臨的最棘手的問題。這本綜合性、實用性的敏捷開發(fā)和極限編程方面的指南，是由敏捷開發(fā)的創(chuàng)始人之一所撰寫的。
    ·講述在預算和實踐要求下，軟件開發(fā)人員和項目經(jīng)理如何使用敏捷開發(fā)完成項目；
    ·使用真實案例講解如何用極限編程來設(shè)計、測試、重構(gòu)和結(jié)對編程；
    ·包含了極具價值的可多次使用的C++和JAVA源代碼；
    ·重點講述了如何使用UML和設(shè)計模式解決面向客戶系統(tǒng)的問題。

作者簡介

Robert C.Martin是Object Mentor公司的總裁。Martin和他的軟件咨詢隊伍使用面向?qū)ο笤O(shè)計、模式、UML、敏捷方法學和極限編程，在世界各地都有他們的客戶。他還是好幾本暢銷書的作者。他還是1996-1999年《C++ Report》雜志的總編，并多次在國際會議和展覽中發(fā)表富有特色的演講。

書籍目錄

第Ⅰ部分 敏捷開發(fā) 第一章 敏捷實踐  1.1 敏捷聯(lián)盟  1.2 原則  1.3 結(jié)論  參考文獻 第二章 極限編程概述  2.1 極限編程實踐  2.2 結(jié)論  參考文獻 第三章 計劃  3.1 初始探索  3.2 發(fā)布計劃  3.3 迭代計劃  3.4 任務計劃  3.5 迭代   3.6 結(jié)論  參考文獻 第四章 測試   4.1 測試驅(qū)動的開發(fā)方法  4.2 驗收測試  4.3 結(jié)論  參考文獻 第五章 重構(gòu)  5.1 素數(shù)產(chǎn)生程序一個簡單的重構(gòu)示例  5.2 結(jié)論  參考文獻  第六章 一次編程實踐  6.1 保齡球比賽  6.2 結(jié)論第Ⅱ部分 敏捷設(shè)計 第七章 什么是敏捷設(shè)計  7.1 軟件出了什么錯  7.2 設(shè)計的臭味——腐化軟件的氣味  7.3 “Copy”程序  7.4 保持盡可能好的設(shè)計  7.5 結(jié)論  參考文獻 第八章 單一責任原則（SRP）  8.1 單一職責原則（SRP）  8.2 結(jié)論   參考文獻 第九章 開放—封閉原則（OCP）  9.1 開放—封閉原則（OCP）  9.2 描述  9.3 關(guān)鍵是抽象  9.4 結(jié)論  參考文獻 第十章 Liskov替換原則（LSP）  10.1 Liskov替換原則（LSP）  10.2 一個違反LSP的簡單例子  10.3 正方形和矩形，更微妙的違規(guī)  10.4 一個實際的例子  10.5 用提取公共部分的方法代替繼承  10.6 啟發(fā)式規(guī)則和習慣用法  10.7 結(jié)論  參考文獻 第十一章 依賴倒置原則（DIP）  11.1 依賴倒置原則（DIP）  11.2 層次化  11.3 一個簡單的例子  11.4 熔爐示例  11.5 結(jié)論  參考文獻  第十二章 接口隔離原則（ISP）  12.1 接口污染  12.2 分離客戶就是分離接口  12.3 接口隔離原則（ISP）  12.4 類接口與對象接口  12.5 ATM用戶界面的例子  12.6 結(jié)論  參考文獻第Ⅲ部分  薪水支付案例研究 第十三章 COMMAND模式和ACTIVE OBJECT模式 第十四章 TEMPLATE METHOD模式和STRATEGY模式：繼承與委托 第十五章 FACADE模式和MEDIATOR模式 第十六章 SINGLETON模式和MONOSTATE模式 第十七章 NULL OBJECT模式 第十八章 薪水支付案例研究：第一次迭代開始 第十九章 薪水支付案例研究：實現(xiàn)第Ⅳ部分 打包薪水支付系統(tǒng) 第二十章 包的設(shè)計原則 第二十一章 FACTORY模式 第二十二章 薪水支付案例研究（第2部分）第Ⅴ部分 氣象站案例研究 第二十三章 COMPOSITE模式 第二十四章 OBSERVER模式——回歸為模式 第二十五章 ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式 第二十六章 PROXY模式和STAIRWAY TO HEAVEN模式：管理第三方API 第二十七章 案例研究：氣象站第Ⅵ部分 ETS案例研究 第二十八章 VISITOR模式 第二十九章 STATE模式 第三十章 ETS框架附錄            附錄A UML表示法Ⅰ：CGI示例 附錄B UML表示法Ⅱ：統(tǒng)計多路復用器 附錄C 兩個公司的諷刺小品 附錄D 源代碼就是設(shè)計 索引

章節(jié)摘錄

　　7.2 設(shè)計的臭味——腐化軟件的氣味　　當軟件出現(xiàn)下面任何一種氣味時，就表明軟件正在腐化。　　僵化性（Rigidity）：很難對系統(tǒng)進行改動，因為每個改動都會迫使許多對系統(tǒng)其他部分的其他改動?！　〈嗳跣裕‵ragility）：對系統(tǒng)的改動會導致系統(tǒng)中和改動的地方在概念上無關(guān)的許多地方出現(xiàn)問題。　　牢固性（Immobility）：很難解開系統(tǒng)的糾結(jié)，使之成為一些可在其他系統(tǒng)中重用的組件?！　≌硿裕╒iscosity）：做正確的事情比做錯誤的事情要困難?！　〔槐匾膹碗s性（Needless Complexity）：設(shè)計中包含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)?！　〔槐匾闹貜停∟eedless Repetition）：設(shè)計中包含有重復的結(jié)構(gòu)，而該重復的結(jié)構(gòu)本可以使用單一的抽象進行統(tǒng)一　　?；逎裕∣pacity）：很難閱讀、理解。沒有很好地表現(xiàn)出意圖?！　?.僵化性　　僵化性是指難以對軟件進行改動，即使是簡單的改動。如果單一的改動會導致有依賴關(guān)系的模塊中的連鎖改動，那么設(shè)計就是僵化的。必須要改動的模塊越多，設(shè)計就越僵化?！　〈蟛糠值拈_發(fā)人員都以這樣或者那樣的方式遇到過這種情況。他們會被要求進行一個看起來簡單的改動。他們看了看這個改動并對所需的工作做出了一個合理的估算。但是過了一會兒，當他們實際進行改動時，會發(fā)現(xiàn)有許多改動帶來的影響自己并沒有預測到。他們發(fā)現(xiàn)自己要在龐大的代碼中搜尋這個變動，并且要更改的模塊數(shù)目也遠遠超出最初估算。最后，改動所花費的時間要遠比初始估算長。當問他們?yōu)楹喂浪愕萌绱瞬粶蚀_時，他們會重復軟件開發(fā)人員慣用的悲嘆，“它比我想像的要復雜得多！”　　2.脆弱性　　脆弱性是指，在進行一個改動時，程序的許多地方就可能出現(xiàn)問題。常常是，出現(xiàn)新問題的地方與改動的地方并沒有概念上的關(guān)聯(lián)。要修正這些問題就又會引出更多的問題，從而使開發(fā)團隊就像一只不停追逐自己尾巴的狗一樣（忙得團團轉(zhuǎn)）?！　‰S著模塊脆弱性的增加，改動會引出意想不到的問題的可能性就越來越大。這看起來很荒謬，但是這樣的模塊是非常常見的。這些模塊需要不斷地修補——它們從來不會被從錯誤列表中去掉，開發(fā)人員知道需要對它們進行重新設(shè)計（但是誰都不愿意去面對重新設(shè)計中的難以琢磨性），你越是修正它們，它們就變得越糟。　　3.牢固性　　牢固性是指，設(shè)計中包含了對其他系統(tǒng)有用的部分，但是要把這些部分從系統(tǒng)中分離出來所需要的努力和風險是巨大的。這是一件令人遺憾的事，但卻是非常常見的事情?！　?.粘滯性　　粘滯性有兩種表現(xiàn)形式：軟件的粘滯性和環(huán)境的粘滯性?！　‘斆媾R一個改動時，開發(fā)人員常常發(fā)現(xiàn)會有多種改動的方法。其中，一些方法會保持設(shè)計；而另外一些會破壞設(shè)計（也就是生硬的手法）。當那些可以保持系統(tǒng)設(shè)計的方法比那些生硬手法更難應用時，就表明設(shè)計具有高的粘滯性。做錯誤的事情是容易的，但是做正確的事情卻很難。我們希望在軟件設(shè)計中，可以容易地進行那些保持設(shè)計的變動?！　　?/pre>



媒體關(guān)注與評論
書評第13屆軟件開發(fā)震撼大獎獲獎作品；國際軟件工程和開發(fā)大師最新力作；眾多名家一致推薦的敏捷開發(fā)指南；軟件工程發(fā)展史上的里程碑性巨著。希望你能喜愛這本書。希望你能像我一樣學著以創(chuàng)建美的軟件而驕傲，并享受其中的快樂。如果你從本書中略微看到了這種快樂，如果本書使你感受到了這種驕傲，如果本書點燃了你內(nèi)心欣賞這種美的火花，那么就遠超過我的目標了。






圖書封面



圖書標簽Tags
無




評論、評分、閱讀與下載



還沒讀過(66)
勉強可看(483)
一般般(824)
內(nèi)容豐富(3417)
強力推薦(280)


 


    敏捷軟件開發(fā) PDF格式下載