敏捷軟件開發(fā)

用戶評論 (總計30條)

•   早就 想買了,終于買了
•   比較喜歡的一款書
•   講的是方法
•   敏捷軟件開發(fā)：原則、模式與實踐
•   非常不錯，還可以啦。。。
•   　　這本書是我見過的講述敏捷設計、開發(fā)書籍中最棒的一本！尤其是前半部分中OOP設計原則的講述，非常佩服Bob大叔對設計原則的總結。后半部分感覺涉及到細節(jié)太繁瑣了就沒看完，不過這無損于這本名著的光芒！這本書可以和其它講述設計模式的相關書籍一起閱讀，相得益彰。
  　　
  　　讀書筆記：
  　　第一部分 敏捷宣言
  　　個體和交互 勝過 過程和工具
  　　可以工作的軟件 勝過 面面俱到的文檔
  　　客戶合作 勝過 合同談判
  　　響應變化 勝過 遵循計劃
  　　
  　　
  　　第二部分 敏捷設計
  　　
  　　腐化的設計
  　　僵化性（Rigidity）：難以對系統(tǒng)進行修改
  　　脆弱性（Fragility）：改動一個地方，程序許多地方出現(xiàn)問題
  　　牢固性（Immobility）：很難解開系統(tǒng)的糾結
  　　粘滯性（Viscosity）：做錯誤的事情容易，做正確的事情困難
  　　不必要的復雜性（Needless Complexity）：過度設計，為過多的可能性做準備
  　　不必要的重復（Needless Repetition）：重復的代碼，開發(fā)人員忽視的抽象
  　　晦澀性（Opacity）：難以閱讀、理解，沒有用清晰、富有表達力的代碼來體現(xiàn)意圖
  　　
  　　需求總是處在持續(xù)變動中，加速了代碼腐化
  　　運用抽象來封裝變化Open-Closed Principle
  　　
  　　OOP設計原則：
  　　一，SRP 單一職責原則（Single Responsibility Princip）
  　　就一個類而言，應該僅有一個引起它變化的原因
  　　高內(nèi)聚、低耦合
  　　Facade模式、PROXY模式
  　　
  　　二，OCP 開放-封閉原則（Open-Closed Principle）
  　　軟件實體（類、模塊、函數(shù)等）應該是可以擴展的，但是不可修改
  　　對擴展開放（Open for extension)：對模塊進行擴展，使其滿足那些改變的新行為
  　　對更改封閉（Closed for modification）：不必改動模塊的源代碼或二進制文件
  　　抽象、多態(tài)
  　　Strategy模式、Template Method模式，
  　　
  　　三，LSP Liskov替換原則（Liskov Substitution Principle）
  　　子類型必須能夠替換掉它們的基類型
  　　IS-A繼承
  　　從使用者角度來審視API
  　　契約式設計（Design By Contract）：通過為每個方法聲明前置條件和后置條件來指定契約
  　　LSP是使OCP成為可能的主要原則之一
  　　子類型的正確含義是“可替換的”
  　　
  　　四，DIP 依賴倒置原則（Depend Invert Princip）
  　　高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象
  　　抽象不應該依賴于實現(xiàn)細節(jié)，實現(xiàn)細節(jié)應該依賴于抽象
  　　如果高層模塊獨立于低層模塊，那么高層模塊就可以非常容易地被重用。該原則是FrameWork設計的核心原則：依賴于抽象
  　　Don't call us，we will call you.低層模塊實現(xiàn)了在高層模塊中聲明的接口，這些接口被高層模塊調用
  　　把不穩(wěn)定的具體類隱藏在抽象接口后面，可以隔離它們的不穩(wěn)定性
  　　OOP設計倒置了依賴關系結構，使得細節(jié)和策略都依賴于抽象
  　　Template Method模式，Bridge模式
  　　
  　　五，ISP 接口隔離原則（Least Knowledge Principle）
  　　不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。
  　　客戶程序看到的應該是多個具有內(nèi)聚接口的抽象基類
  　　客戶程序應該僅僅依賴于它們實際調用的方法
  　　Facade模式
  　　
  　　
  　　第三部分 薪水支付案例研究
  　　Command模式：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可取消的操作。
  　　
  　　命令模式就是把一些具體的命令封裝成一些具體的類，這些類實現(xiàn)同一個接口或者是抽象類。把這些類組織到一起來統(tǒng)一執(zhí)行，完成一個具體的業(yè)務流程。它的優(yōu)點是：解耦了發(fā)送者與接收者之間的聯(lián)系。發(fā)送者調用一個操作，接收者接受請求執(zhí)行具體類相應的動作。因為使用Command模式解耦，發(fā)送者無需知道接受者任何接口。
  　　比如說，對文件進行操作，如打開、關閉、打印。正常的操作就是用戶點擊“打開”按紐，就執(zhí)行打開命令，在按紐的單擊事件中寫個方法就可以了。但如要應用Command模式，就要把其抽象出接口，把這三個操作封裝成單獨的類。
  　　
  　　Template Method模式：定義一個操作中的算法骨架，而將一些步驟延遲到子類中。Template Method模式使得子類可以不改變算法的結構即可重新定義該算法的某些特定步驟。（繼承）
  　　
  　　Strategy模式：定義一系列的算法，把它們一個個封裝起來，并且使它們可以相互替換。Strategy模式使得算法可以獨立于使用它們的客戶而變化。（委托）
  　　
  　　Facade模式：為子系統(tǒng)中的一組接口提供一個一致的界面。Facade模式定義了一個高層接口，這個高層接口使得這一子系統(tǒng)更加容易使用。
  　　
  　　Mediator模式：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯示地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
  　　
  　　Singleton模式：保證一個類僅有一個實例，并提供一個全局訪問點。通過使用私有構造函數(shù)，靜態(tài)變量和一個靜態(tài)訪問方法來實現(xiàn)。
  　　
  　　MonoState模式：構造函數(shù)聲明為public，而將類中所有的字段聲明為static。MonoState并不限制創(chuàng)建對象的個數(shù)，但是它的狀態(tài)卻只有一個狀態(tài)。
  　　
  　　NULL Object模式：提供一個給定類型的NULL Object對象，用以代替這個對象為null的情況，簡化代碼。
•   　　 2005年閱讀的這本書，也因此知道了鄧輝這個人，對前幾章印象深刻，特別是敏捷的宣言和SOLID設計原則，但是后面的具體例子，受限于設計能力和語言差別，理解不深，知道了TDD，結對編程等概念，但是不能肯定是否有效。隨后打算重讀一遍技術章節(jié)；
  　　
•   　　讀懂這本書還是需要一定功底的，需要相當?shù)脑O計實踐經(jīng)驗才能完全理解，書中也描述了一些設計模式，不過相比GOF的《設計模式》來說它是在一個更高設計原則的層次來描述經(jīng)典模式的，總的來說值得閱讀。
•   　　絕對是值得每一個敏捷開發(fā)人員閱讀的圖書。內(nèi)容很實用。尤其是第六章《一次編程實踐》部分的例子對我的觸動很大。
•   　　看到前面有評論說，此書與敏捷的關系不大，頗有同感。所謂敏捷，那就是代碼先寫了再說，且看我們是如何做到，這就是讀了這本書的感受。
  　　
  　　中文版沒有把特定的英文縮寫在第一次引用時列出來（只能在后面的索引表里找到），讓我很不爽，比如DIP和SRP。不過，說到底還是中文看得快，比看小說都快。
  　　
  　　本書的一大特點就是淺顯，比GOF的那本《設計模式》通俗易懂多了。雖然我還是不喜歡看大段的代碼，但不可否認那些代碼能夠幫助理解。
  　　
  　　本書最好的地方，還是敏捷設計一章，列出了幾個基本的原則：
  　　1.單一職責原則（SRP）
  　　2.開發(fā)-封閉原則（OCP）
  　　3.Liskov替換原則（LSP）
  　　4.依賴倒置原則（DIP）
  　　5.接口隔離原則（ISP）
  　　
  　　以及后面的打包原則：
  　　1.內(nèi)聚性原則
  　　2.耦合性原則
  　　3.穩(wěn)定依賴原則
  　　4.穩(wěn)定抽象原則
  　　
  　　特別是LSP還是第一次聽說，真是耳目一新。而穩(wěn)定依賴原則，則有了更深的理論認識，雖然沒有仔細看明白那些數(shù)學公式。
  　　
  　　當然，關于好的設計模式，還有很多很多，這本書也只是講了很小一部分，講得還不錯。不過很多東西已經(jīng)很老套了，基本都是N年前的東西了，難道是Bob大叔老了？
•   　　一本還不錯的軟件設計方面的書。不過為什么要扯上敏捷的頭銜呢。書中最有價值的還是那個附錄《源代碼即設計》，其它的真正敏捷的東西太少了。而且放的代碼過多。
  　　
•   　　通過這本書，你可以有以下收獲：
  　　1.更深入的理解模式。
  　　2.提供了更好的軟件開發(fā)的方法。
  　　3.具有了總體理解系統(tǒng)架構的能力。
  　　
  　　我以前總想看懂DELPHI的源碼，總覺得一頭霧水，現(xiàn)在知道是我沒明白他的設計思想，不能從上往下看，越看東西越多就糊涂啦。
•   有同感！
  我相信作者的幽默感不錯，但翻譯之后，平平淡淡得！
•   老大，這本來就是本2002年的書，當然是N年前......
•   “所謂敏捷，那就是代碼先寫了再說”，你的理解比較搞笑，完全誤解敏捷開發(fā)的含義和主張?？磥砟氵€是一個寫代碼的啊。。。
•   to TiMeZz，我可不可以認為你沒有寫過代碼？
•   難倒狗咬了你一口你就要咬回來?
•   Gabriel糾正得極是，我還得加強修煉才行，呵呵。
•   總有人覺得自己很高竿.
•   敏捷還真就是代碼先寫了再說，整個極限編程的核心就死簡單實現(xiàn)...
•   從書中的舉例和故事來看，其實也和敏捷實踐有很大關系
•   “所謂敏捷，那就是代碼先寫了再說”，這倒也是，我看了一遍這書都快把它當作面向對象開發(fā)的讀物來對待了。
•   TiMeZz說的沒有錯，optman所說的“敏捷”就是先寫代碼，確實沒有理解到敏捷軟件開發(fā)的精髓。
  敏捷是指，不斷維護一套靈活性很高的，易于修改的，防止其腐化，使之始終保持最佳狀態(tài)，這樣就能夠快速地應對不斷而來的客戶需求變化，從而使得最終產(chǎn)生最符合客戶需求的質量最高的系統(tǒng)。
•   還是先寫代碼
•   跟敏捷的關系還是很大啊。。
•   　“所謂敏捷，那就是代碼先寫了再說”, 代碼是要寫的, 但不僅僅是這樣的吧, 呵呵
•   對于我們這樣的菜豆來說，代碼是理解原理的最好形式。
•   有了這些代碼, 理解設計模式就比GOF輕松多了.而且從代碼的演化過程可以學會如何重構,重構是如何進行的,為什么重構.
•   基本上就沒有什么敏捷的內(nèi)容在里面，這年代你不談xp，不談agile，不談scrum，出版商都和你急！
•   難道真沒有麼？真的沒有麼？真的是沒有麼？

相關圖書

• 專利地圖方法與應用
• 日本の美意識
• 那邊在歌唱
• 限富扶貧
• 日本人と中國人とのコミュニケーション
• 旅の指さし會話帳33JAPAN【中國語版】
• 旅の指さし會話帳4中國第3版]
• 茶道具の世界2 高麗茶碗
• 康定斯基的月光
• 鯨騎士
• 雨濕之夜 參橫之晨
• しっぽをかんで
• 愛我，就來追我吧
• SEO實戰(zhàn)密碼
• 擁抱的語言
• 我們只有一個選擇
• 太空兒UB
• 中國烹調大全
• 經(jīng)常性思想工作方法與技巧
• 冷眼看人生
• 我家的北極熊寶寶·Peace
• サーカスの時間
• 傾盡天下之亂世繁華
• 揚州園林甲天下
• 奧菜恵ベストセレクション/ALL ABOUT MEGU