敏捷软件开发

《敏捷软件开发》读书笔记（2） 包的划分原则和度量方法 以下原则中，前三个有关粒度，关注于如何把类划分在包里，是自底向上的设计，是关于包的内聚性设计，但是要考虑可开发性和可重用性两者的平衡；而后三个有关耦合，关注包之间的关系，关于包的稳定性设计，是自顶向下的设计思考。 重用发布等价原则REP 重用的粒度=发布的粒度，重用的粒度就是发布的粒度，为重用而发布的包中，不应该包含任何不是为重用而设计的类，也就是不应该包含任何业务定制、环境定制多代码。另外，也要考虑划分，不能强迫使用者引入他们不需要的类。 共同重用原则CRP 一个包中的所有类应该是共同重用的，如果重用了包的一个类，那么就要重用包中的所有类。重点是，相互之间没有紧密联系的类，不应该放在一个包中。否则，要么可能增加软件大小（apk这种），要么是一些不相关的类的更新，会导致所有依赖的地方被迫更新、验证，即使他们完全没有用这些类。 共同封闭原则CCP 一个包多所有类，应该对同一类变更是共同封闭的，也就是会为了同一个原因而修改，不应该包含多个引起变化的原因。一个需求变化到来时，应该将变化封闭在一个包中。（业务复杂，至少在修改问题时，不应该到处修改） 无环依赖原则 没啥好说的，包之间不能出现循环依赖，否则会出现无法构建、晨后综合征、测试困难、构建时间长等问题，可以用如下两个方式解决循环依赖：抵赖倒置、增加一个包，让两个模块都依赖新的包。

《敏捷软件开发》读书笔记（3） 书中设计模式的汇总 命令类模式，分离执行和定义 CMD模式 其实是事件-事务绑定的模型： 可以用事件驱动，只要收到事件，执行绑定到事件对应的CMD对象.do方法就行，对于真正执行的事情无感知。解除了系统的逻辑互联关系和实际连接关系的设备之间的耦合。 事务型操作，把验证和执行分离，由执行框架完成验证和执行操作。解除了获取数据、验证数据、执行数据操作这种空间耦合，同时也可以在执行时间上进行解耦。扩展可以增加undo接口，系统把CMD对象压入堆栈，在进行回退的时候调用undo。 整体上就是把程序算法或者业务逻辑，和程序的实际控制执行解耦，有点像函数式编程。 ACTIVE OBJECT模式 这部分没看懂，似乎是多线程任务执行引擎，可以把CMD对象放回到引擎列表中。这种类型的线程任务是RTC线程。 复用算法，分离业务逻辑的模式 TEMPLATE METHOD模式 把算法的控制和逻辑分离，通用算法封装到基类，不需要理解的逻辑部分交给子类实现，比如冒泡排序。（其实不一定用继承，可以用组合），注意防止滥用。 STRATEGY模式 相比TEMPLATE METHOD，更好的解除了具体实现和算法的耦合，使用接口+组合，而不是继承，能提高具体实现的复用性，优先使用。 统一对外接口，隐藏策略的模式 FACADE模式 封装组件对外的策略和约束

《敏捷软件开发》读书笔记（4） 气象站系统的实践 开始，先分析需求、用例，确定计划。根据具体的需求和非功能性的需求，选取开发语言，准备开始软件设计。 软件设计，考虑优先解除对界面的依赖，用OBSERVER模式，创建一个ADAPTER作为观察者，收到数据后去刷新界面。 再考虑如何解除对传感器修改的依赖，因为Schedule主要是要耦合不同传感器的触发周期，那就单独把触发周期抽象一个触发器，由传感器实现，告诉Schedule在某个时间唤醒自己即可，这样Schdule就只完成了一件工作，符合SRP原则。 考虑如何创建一套独立的API，和现有系统隔离，利用BRIDGE模式把硬件API从现有系统提取出来，把实现和抽象分离。 分离这些对象的实现后，创建对象的代码非常繁杂，再利用FACTORY模式把创建过程封装起来，进一步隔离实现类，把相关的实现类放在一起处理。 进一步把平台实现类的创建过程封装到工厂类中，只需要替换一行代码，就可以切换到另一个平台。 接下来拆分包，对软件的几个部分分别进行发布和分发，把UI从Station解耦出来，由主程序分别初始化。 进一步解除UI和具体实现的依赖，把添加监听的部分，抽象出接口类，让UI依赖接口，系统实现接口，进一步解除耦合。 在监控之余实现数据持久化和相关策略计算逻辑，还是利用OBSERVER，监听变化和时钟，并且将通用算法分离出去。

一、AgileEAS.NET平台简介 AgileEAS.NET平台 是一套应用系统快速开发平台，用于帮助中小软件开发商快速构建自己的企业信息管理类开发团队，以达到节省开发成本、缩短开发时间，快速适应市场变化的目的，AgileEAS.NET应用开发平台包含基础类库、资源管理平台、运行容器、开发辅助工具等四大部分，资源管理平台为敏捷并行开发提供了设计、实现、测试等开发过程的并行。 AgileEAS.NET平台 基于软件过程改进以及构件化快速开发两方面达到这方面的目标，在软件过程改进实践方面，提出了独有的“ 敏捷并行开发方法 ”开发方法，其目的是在软件的管理之中提出符合国内中小软件企业实际情况并且可操作的软件工程实践、软件过程改进思想、及相配套的项目管理系统。 在快速开发方面， AgileEAS.NET平台 平台提供了企业应用开发所需的诸如ORM、IOC、分布式通信、插件与平台基础结构以及一系统的快速生成工具，涵盖开发过程中的设计、编码、集成、部署、运维等各个环节。 二、有关AgileEAS.NET文章汇总 有关于AgileEAS.NET平台介绍的文章 5.0 版本介绍 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - 5.0 简介 4.2重构改进 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - Linq 2 EAS

　　敏捷软件开发原则 ----《敏捷软件开发原则、模式与实践》学习笔记 最近在系统地学习并且有意地在工作中实践敏捷软件开发， 文章乍看起来，都是一些说教性、理论性，比较无聊的东西。 　　 但是如果静下心来结合自己自身的经历、思考地去阅读，可能会发现，有的观点确实很赞同，然而有的可能会有自己的想法。 　　以下是在《敏捷软件开发 原则、模式与实践》一些读书笔记，斜体字是直接摘录于书本，非斜体字是自己的一些理解。 一、尽早的，持续地交互有价值的软件来使客户满意。 初期交付的系统功能越少，最终交付的系统的质量越好。逐渐增加功能的方式，经常地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量越高。 关于交付对象，这里指的交付给客户，我们能做的不一定是交付给客户，还可以是提交给上级、开发、产品、测试同事看一下，看是否有不合理的地方，可以及时更正。如果等到差不多完了才交付，可能出现了问题也不好改了。 关于交付的时间点，可以是软件有一部分完整可以展示的功能即可。 二、欢迎需求的变化，即使到了开发后期，敏捷过程能够驾驭变化，为客户创造竞争力。 其实欢迎需求变化，个人觉得只是一种无奈、坦然的说法，有谁闲着没事希望天天改需求丫。这里的意思只是说，开发软件的时候，要努力的保持软件结构的灵活性，当需求有变化的时候，让系统改动最小化。 三、经常地交付可以工作的软件，从几个星期到几个月

《敏捷软件开发──原则、模式与实践》阅读笔记 /*--> */ /*--> */ 《敏捷软件开发──原则、模式与实践》阅读笔记 Table of Contents 1. 敏捷开发 1.1. 敏捷联盟宣言 1.2. 敏捷开发的原则 2. 极限编程 3. 设计原则 3.1. 单一职责原则（SRP） 3.2. 开放——封闭原则（OCR） 3.2.1. 遵循开放──封闭原则设计出的模块具有两个主要的特征 3.3. Liskov替换原则（LSP） 3.4. 依赖倒置原则（DIP） 3.5. 接口隔离原则（ISP） 4. 常用设计模式 4.1. Command模式和Active Object 4.1.1. Command模式的优点 4.1.2. Active Object模式 4.2. Template Method模式和Strategy模式：继承和委托 4.2.1. Template Method模式 4.2.2. Strategy模式 4.2.3. 对比 4.3. Facade模式和Mediator模式 4.3.1. facade模式 4.3.2. Mediator模式 4.3.3. 对比 4.4. Singleton模式和Monostate模式 4.4.1. Singleton模式 4.4.2. Monostate模式 4.4.3. 对比 4.5. Null Object模式 4.6.

敏捷软件开发与传统软件开发的对比 最早了解敏捷开发是通过大二的一次博雅课堂，一位在百度工作的北航学长跟我们分享了他近年来从事敏捷开发的经历。印象最深的一句话是一个延迟3个月交付100%功能的软件和一个按时交付75%核心功能的软件，敏捷软件开发者更愿意选择后者。本学期的软件工程基础课又向我们讲授了传统软件开发，经过课上和课后的学习，对于敏捷软件开发和传统软件开发有了浅显的认识和理解。由于课上学习的重点是传统软件开发，所以课下对敏捷软件开发进行了更多的涉猎，本文以敏捷软件开发为主体，来分析其与传统软件开发的对比。 敏捷软件开发与传统开发方法相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正软件中的错误，提高开发效率，同时为需求的调整提供更多机会，保证软件向正确的方向发展。 传统软件开发如瀑布模型强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。 对敏捷联盟宣言的理解 1.个体和交互胜过过程和工具，强调软件开发必须发挥人的积极性和创造性，更看重人的沟通和团队的力量； 2

本文已经首发于 InfoQ中文站 ，版权所有，原文为《XXX》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站 是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、线下技术交流活动 QClub 、免费迷你书下载如 《架构师》 等。​ 在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。 确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量