敏捷软件开发的读后感10篇
《敏捷软件开发》是一本由Robert C. Martin著作，清华大学出版社出版的平装图书，本书定价：59.00元，页数：476，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
这本书是我见过的讲述敏捷设计、开发书籍中最棒的一本！尤其是前半部分中OOP设计原则的讲述，非常佩服Bob大叔对设计原则的总结。后半部分感觉涉及到细节太繁琐了就没看完，不过这无损于这本名著的光芒！这本书可以和其它讲述设计模式的相关书籍一起阅读，相得益彰。
读书笔记：
第一部分 敏捷宣言
客户合作 胜过 合同谈判
第二部分 敏捷设计
腐化的设计
僵化性（Rigidity）：难以对系统进行修改
脆弱性（Fragility）：改动一个地方，程序许多地方出现问题
牢固性（Immobility）：很难解开系统的纠结
粘滞性（Viscosity）：做错误的事情容易，做正确的事情困难
不必要的复杂性（Needless Complexity）：过度设计，为过多的可能性做准备
不必要的重复（Needless Repetition）：重复的代码，开发人员忽视的抽象
晦涩性（Opacity）：难以阅读、理解，没有用清晰、富有表达力的代码来体现意图
需求总是处在持续变动中，加速了代码腐化
运用抽象来封装变化Open-Closed Principle
OOP设计原则：
一，SRP 单一职责原则（Single Responsibility Princip）
就一个类而言，应该仅有一个引起它变化的原因
高内聚、低耦合
Facade模式、PROXY模式
二，OCP 开放-封闭原则（Open-Closed Principle）
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改
对扩展开放（Open for extension)：对模块进行扩展，使其满足那些改变的新行为
对更改封闭（Closed for modification）：不必改动模块的源代码或二进制文件
抽象、多态
trategy模式、Template Method模式，
三，LSP Liskov替换原则（Liskov Substitution Principle）
子类型必须能够替换掉它们的基类型
IS-A继承
从使用者角度来审视API
契约式设计（Design By Contract）：通过为每个方法声明前置条件和后置条件来指定契约
LSP是使OCP成为可能的主要原则之一
子类型的正确含义是“可替换的”
四，DIP 依赖倒置原则（Depend Invert Princip）
高层模块不应该依赖于低层模块，二者都应该依赖于抽象
抽象不应该依赖于实现细节，实现细节应该依赖于抽象
如果高层模块独立于低层模块，那么高层模块就可以非常容易地被重用。该原则是FrameWork设计的核心原则：依赖于抽象
Don't call us，we will call you.低层模块实现了在高层模块中声明的接口，这些接口被高层模块调用
Template Method模式，Bridge模式
五，ISP 接口隔离原则（Least Knowledge Principle）
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
客户程序看到的应该是多个具有内聚接口的抽象基类
客户程序应该仅仅依赖于它们实际调用的方法
Facade模式
第三部分 薪水支付案例研究
Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无需知道接受者任何接口。
比如说，对文件进行操作，如打开、关闭、打印。正常的操作就是用户点击“打开”按纽，就执行打开命令，在按纽的单击事件中写个方法就可以了。但如要应用Command模式，就要把其抽象出接口，把这三个操作封装成单独的类。
Template Method模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变算法的结构即可重新定义该算法的某些特定步骤。（继承）
trategy模式：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。Strategy模式使得算法可以独立于使用它们的客户而变化。（委托）
Facade模式：为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个高层接口使得这一子系统更加容易使用。
Mediator模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
ingleton模式：保证一个类仅有一个实例，并提供一个全局访问点。通过使用私有构造函数，静态变量和一个静态访问方法来实现。
MonoState模式：构造函数声明为public，而将类中所有的字段声明为static。MonoState并不限制创建对象的个数，但是它的状态却只有一个状态。
ULL Object模式：提供一个给定类型的NULL Object对象，用以代替这个对象为null的情况，简化代码。
《敏捷软件开发》读后感(二)：我已经记不清这是第几次在豆瓣上将此书从在读改为已读了
手上这本书已经伤痕累累了，封面也只剩下一厘米左右就要完全脱落。大学的时候就购买了这本书，然后尘封了一段时间。毕业后才正式看，也不知道看了几遍，只知道在豆瓣上我一次又一次的将此书从读过改为在读，一段时间后又改为已读，如此往复，不知道这是第几遍了，但我知道这不是最后一次。每一次拿起来都有更多的收获。
在读这本书之前，我就读过GOF《设计模式》这本书，那个时候总是在概叹，这些前辈大牛为什么能做出如此好的设计，什么在指引着他们，他们的设计目标又是什么。后来见了这本书，见了这本书上描述的原则才知道，原来这就是指引着前辈大牛做出好的设计的指导原则，是他们的航标。
设计模式虽然美妙，但那太过于具体，原则虽然通用但那太过于抽象，这本书就是在原则和模式上建立起桥梁，然后用具体的实例来阐释着在原则的指引下，来实现各种各样优美的设计。
我真希望有一天，我能将此书划到已读里，然后再也不捡起来，真希望有那么一天~~
摆在面前的是本大部头，原则、模式和实践诠释了全书的内容，单讲模式没有其他书籍规范，单从重构看又不如马丁的重构专业，本书许多知识可见其他书籍，比较典型的是设计模式解析，我装逼般的和花了一周读本书，可想我本人是多么的浮躁，对我来说书中的实践大于思想，我总感觉读这本书我读晚了，也许早两年我会更加认真的看完它的理论，现在想想这个老头在02年就能写出这么多实践，真是大师，我想那个年代再也找不到一个像作者这样理论加实践如此厚实的人了，说了这么多，如果你真的准备读它，我的建议因为本书实践大于理论，所以先备足理论是本书的前提，推荐学习面向对象原则、然后读本正统的模式书，最后再读本书，另外是java领悟的不要看c#版本，会很纠结，当你看到ejb和.net同时出现你会崩溃的。
《敏捷软件开发》读后感(四)：模式案例书
敏捷软件开发提倡测试先行，设计适应要求，迭代式渐进开发。
一、通过用例来确认需求，分析软件行为：针对用例中的事物对象建立合理的类结构；分析用例中类似情形的变化因素，尽量用抽象来统一一类变化，由此建立系统的大致静态结构。在此不需要、也很难确定好系统的最终结构，因为还没有实际的类交互，还不能很好明确此时的静态结构是否合理。
二、通过用例来编写测试用例：通过代码来实现具体功能所要涉及的输入、输出、约束（一般开发人员最容易忘掉约束，这是BUG产生的源泉之一）；为实现该功能所需要的不同类的交互行为。通过事先编写测试用例，能让开发人员站在使用者的角度来审视类方法的名称，调用流程是否合理。
三、依据测试用例和之前设计的类静态结构，可以实现为满足当前测试功能所需要的类。在实现类的过程中，能够发现之前一些静态结构设计的不合理性，从而切实地建立起合理的类结构来。
在上述三个不断迭代的流程中，共有的工作都是根据不同的手段来设计灵活的类结构。好的软件设计是对变化的反应时比较灵活的，但实际的开发中，不可能对所有变化都会加以考虑而进行设计。因此一个总的原则就是首先考虑明显可能的变化；对于因未考虑到的某个变化而导致要新增加功能时，要考虑这一类变化。
为了应对变化，就需要对一类行为进行抽象，从而可以应用由众多智慧汇聚并提炼的结构模式来分离变化。此书就是用非玩具型实例来一步一步展示整个系统是如何设计并实现完成的，众多的常用模式是如何被考虑到分离变化中来的。
对软件模式更完整的讲述当属《设计模式——可复用面向对象软件的基础》，此书做为补充材料能让开发人员对模式的应用以及如何应用模式有更直观、清楚的理解。另外此书给开发人员提供了实用且高效的迭代式开发行为方式。
《敏捷软件开发》读后感(五)：软件开发的核心问题是“人”的问题
软件开发的核心问题是不断变化的需求和团队沟通的困难。
而敏捷开发的核心思想就是针对这两个问题提出来的，XP实践过程中的团队、计划、结对、所有权都是希望通过积极的团队内部的沟通来减少人与人之间的Gap, 而测试、简单设计、重构这些都希望通过快速的迭代跟新设计来应对外部不断变化的需求的问题，解决的是外面的“人”和团队的“人”的问题而其中测试则是为了最大程度地保证跟新设计过程不会破坏原有的实现以及引入新的bug，是辅助手段。
总的来说，XP是“小步快跑”的软件开发方法，它更强调的是“小”，而不是“快”，而后者是我经常看到一些技术团队过分看重的方面。
这本书很好，但是这本书花了更多的篇幅来解释OOP设计的原则，XP想要解决的问题，说到底并没有超出软件开发自身的困难，易于维护、拓展的代码会给软件开发管理带来非常大的便利。
《敏捷软件开发》读后感(六)：讲如何在实践中进行设计
主要内容是面向对象的设计原则和设计模式的运用，设计模式讲的是具体运用，没有《设计模式》讲得全面，因为这本书着重在具体软件编程中怎么思考、运用设计模式，怎么一步步演变，代码很详细，例子很清晰简单，思考过程也讲得很清楚，就像看好的博客一样娓娓道来。《head first设计模式》是把设计原则和设计模式混在一起讲的，讲一个设计模式顺带讲一个设计原则，感觉整体上有点乱，这次算是把全部设计原则整理了一遍，这个估计是这本书里边独有的。
说实话我是在面试时被面试官问到敏捷开发是啥才来看这本书的，这本书是敏捷开发里边人气最高的，而且不是那种理论型的书，比较实际。像对我这样大型软件开发经验比较少的人来说，还是觉得能有所收获，看懂也不难，当然，要深刻理解并在实际中用起来才算学到手。
在本质上这本书讲的是方法论，就是怎么思考和怎么做好这件事。这和讲知识点的书不一样，像看一本讲语言的书，看了语法，以后就可以按着语法去写了。但讲思考方法的书需要以后在实践中慢慢体会，如果在以后的某一天，你突然发现自己在设计类的时候，脑海里会浮现一张张UML图，会从松耦合、减少重复代码的角度出发看问题，那这就是这本书所能带给你的了。所谓的那些设计原则，只是把方法抽象成概念，易于人和人之间的交流，里边思考的方法才是重要的。
《敏捷软件开发》读后感(七)：测试驱动开发与设计模式入门
首先我以个人开发者的角度来评论这本书，因个人经历所限，并未有大型团队协作，多人并行开发的经历，所以我比较关注的地方在于如何能适应需求变更，快速高质量的满足客户需求。我想每个开发者都应该有感受，需求是不断不断变化的，特别现在互联网时代，客户很可能都不知道自己想要什么需求，在版本迭代中慢慢形成，或者客户虽然刚开始明确但过程中要对最终做重大改变，所以软件开发中灵活高效解决需求变更是十分重要的。
讲完背景，所以，本书中前两章敏捷开发和极限编程我没有太多感触。
以下是我觉得这本书对我来说很重要的几个点。
测试驱动开发。
这个是本书对我影响较大的第一个点，我相信很少开发者在代码之前会写测试代码，认为那是浪费时间。但我们很容易遇到两个问题：1.你后台部分代码写完了，但这些代码需要前台事件来触发才能执行，那你必须要等前台完工且他有时间，且验证时刻你必须要依赖于前台能提供的一些事件来确保代码正确性，通常前台不可能触发所有可能的case；2.你修复了一个bug或者更改了一点小的需求，但你很难确保（如果有很好的设计习惯有可能可以确保）这个变动不会引发负面影响，你需要跑一下主功能但也没办法覆盖所有可能的测试情况。如果你采用的是测试驱动开发的方式，那么前两种问题将不存在，测试驱动开发方式提示你可以伪造一个前台，伪造他的任何事件来验证你的后台代码，测试驱动开发对每个功能点甚至每个方法都有验证，针对情况2你只需要跑一下你之前的单元测试用例即可。
软件设计原则。
刚刚有提到修复bug或者增加需求可能会带来不确定因素，但是如果你有良好的软件设计习惯，可以把这个风险降到最低。这个良好设计习惯即书中的软件设计原则：OCP、SRP、DIP等，这些原则可以让你的代码远离一些“坏味”的噩梦，让你在面临需求变更的时候更高效，代码更健壮；更易维护和拓展。
设计模式。
我强调一下书中的观点，不要为了设计模式和设计模式。比如所有对象new都可以使用工厂模式，但是你是否真的需要呢？考虑好你的场景，根据需求，甚至刚开始能不引入的情况都不使用，在适当的时候发现重构代码引入设计模式可以让你的代码更优雅有效时才引入。本书对设计模式的讲解在于例子比较实际，不想网上概念介绍都是为模式而模式，你可以不引入模式实现同样代码，且你的代码看起来会更简洁优雅一些。
总体来讲，这是一本好书，一本比较实际实用的书。推荐写过一段时间代码，对代码组织能力和变更能力感觉到吃力，或者觉得现有代码很难维护想更好重构的人读，不推荐还在学习语言语法和使用的人读。不太满意之处，在于很多设计模式有些过时或者不是很恰当，翻译有时不是特别尽人意（无可避免，有些字读英文很容易理解但你理解后你也翻译不好）。
一本好书，一本实用的书。