敏捷软件开发的笔记(13)

>我来写笔记

按有用程度 按页码先后 最新笔记

第三部分薪水支付案例研究

Wuqifu (喜欢买书的软件工程师~)

Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无... (更多)

Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无需知道接受者任何接口。
比如说，对文件进行操作，如打开、关闭、打印。正常的操作就是用户点击“打开”按纽，就执行打开命令，在按纽的单击事件中写个方法就可以了。但如要应用Command模式，就要把其抽象出接口，把这三个操作封装成单独的类。
Template Method模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变算法的结构即可重新定义该算法的某些特定步骤。（继承）
Strategy模式：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。Strategy模式使得算法可以独立于使用它们的客户而变化。（委托）
Facade模式：为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个高层接口使得这一子系统更加容易使用。
Mediator模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Singleton模式：保证一个类仅有一个实例，并提供一个全局访问点。通过使用私有构造函数，静态变量和一个静态访问方法来实现。
MonoState模式：构造函数声明为public，而将类中所有的字段声明为static。MonoState并不限制创建对象的个数，但是它的状态却只有一个状态。
NULL Object模式：提供一个给定类型的NULL Object对象，用以代替这个对象为null的情况，简化代码。 (收起)

2011-12-23 21:34:19 回应

收藏
推荐
第3页

猴子 (生活依然是生活)

敏捷软件开发宣言：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。 (更多)

敏捷软件开发宣言：
个体和交互胜过过程和工具；
可以工作的软件胜过面面俱到的文档；
客户合作胜过合同谈判；
响应变化胜过遵循计划。 (收起)

2012-05-02 21:15:53 回应

收藏
推荐
XP计划中的流程

白乌鸦 (Understand yourself)

1，初始探索：尽量确定所有真正重要的用户素材，而非所有的用户素材。任何过大的素材都应该被分解成小一点的部分，任何小素材都应该和其它小素材合并。估算出每个素材的开发速度：素材点，随着项目进展，估算将趋于准确。 2，发布计划：客户知道了开发速度，就能对每个素材成本有所了解，也知道了每个素材的商业价值和优先级别。一些重要但实现起来代价高昂的素材可被推迟实现，而先去选择那些代价低廉的素材。... (更多)

1，初始探索：尽量确定所有真正重要的用户素材，而非所有的用户素材。
任何过大的素材都应该被分解成小一点的部分，任何小素材都应该和其它小素材合并。
估算出每个素材的开发速度：素材点，随着项目进展，估算将趋于准确。
2，发布计划：客户知道了开发速度，就能对每个素材成本有所了解，也知道了每个素材的商业价值和优先级别。一些重要但实现起来代价高昂的素材可被推迟实现，而先去选择那些代价低廉的素材。当开发速度变得更准确时，可以对发布计划进行调整。
3，迭代计划：客户开始选择他们想要在迭代中实现的素材。而在迭代期间，用户素材的实现顺序属于技术决策范畴。一旦迭代开始，客户就不能再改变迭代期内需要实现的素材，除了开发人员正在实现的素材外，客户可以任意改遍或重新安排项目中的其它任何素材。
计算出本次迭代的开发速度，这个速度将被用于计划下一次的迭代。这次迭代中完成了31个素材点，那么应该计划下次迭代中也完成31个点。
4，任务计划：
（1）开发人员和客户制定迭代计划后，在迭代前，将素材分解成任务，一个任务是一个开发人员能在4~16小时内实现的某个功能。对素材分析，尽可能列举出所有任务
（2）开发人员逐个签订他们想要实现的任务，如果任务没有全部分配出去，则协商交换任务。还不能分配完，就要求客户去掉一些任务或素材。
（3）迭代到中点时，如果没有完成一半的素材点，则重新制定计划。
管理人员不必强制、威胁或者恳求开发人员去达到一个武断的，不切实际的目标。 (收起)

2012-04-19 18:31:24 回应

收藏
推荐
XP概述中的两点：三条XP原则，重构

白乌鸦 (Understand yourself)

三条XP原则 1，考虑能够工作的最简单的事，所有能达到目标的方案中，选取最简单的那一个 2，只有在有证据，或十分明显的迹象表明要引人某些基础结构时，再引入。 3，如果代码重复，一旦发现，马上消除。迫使团队提炼出更多的抽象，减少耦合（为何抽象越多，耦合越少？不懂）重构：每次只对其进行一系列小的改造。重构是我们应该每隔一小时或者半小时就该做的事。然后立即运行单元测试。 (更多)

三条XP原则
1，考虑能够工作的最简单的事，所有能达到目标的方案中，选取最简单的那一个
2，只有在有证据，或十分明显的迹象表明要引人某些基础结构时，再引入。
3，如果代码重复，一旦发现，马上消除。迫使团队提炼出更多的抽象，减少耦合（为何抽象越多，耦合越少？不懂）
重构：每次只对其进行一系列小的改造。重构是我们应该每隔一小时或者半小时就该做的事。然后立即运行单元测试。 (收起)

2012-04-19 18:12:24 回应

收藏
推荐
敏捷宣言的4条价值观，及其引出的12条原则

白乌鸦 (Understand yourself)

四条价值观：个体和交互胜过过程和工具：可以工作的软件胜过面面俱到的文档客户合作胜过商务谈判响应变化胜过遵循计划工作细节 1，几乎每个周五，我们都会把软件提交给客户，到下一个周一或者周二，客户会给我们一份关于软件的变更列表。我们把这些变更排定一个优先级，然后把他们安排到随后几周的工作中。 2，为下两周做详细的计划，为下三个月做粗略的计划，至于一年以后的系统将要做什么，有个模糊的想法... (更多)

四条价值观：
个体和交互胜过过程和工具：
可以工作的软件胜过面面俱到的文档
客户合作胜过商务谈判
响应变化胜过遵循计划
工作细节
1，几乎每个周五，我们都会把软件提交给客户，到下一个周一或者周二，客户会给我们一份关于软件的变更列表。我们把这些变更排定一个优先级，然后把他们安排到随后几周的工作中。
2，为下两周做详细的计划，为下三个月做粗略的计划，至于一年以后的系统将要做什么，有个模糊的想法就行了。
十二条原则：
1，尽早、持续交付有价值的软件：初期交付功能要少，要频繁交付；
2，即使到了开发的后期，也欢迎需求的改变；
3，经常性交付，交付间隔越短越好；
4，在整个项目开发期间，业务人员和开发人员必须天天都在一起工作；
5，围绕被激励起来的个人来构建项目。给他们提供所需要的环境、支持和信任；
6，最具效果效率的沟通就是面对面交谈；
7，进度度量标准：客户需求的数量；
8，责任人、开发者和用户应该能够保持一个恒定的、长期的开发速度；
9，不断地关注优秀的技能和好的设计；
10，以最高地质量完成最简单的工作
11，最好的架构、需求和设计出自于自组织的团队
12，每个一段时间，团队会在如何更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
结论：构成了一个可以帮助团队打破过程膨胀循环的方法。
(可供选择的敏捷过程：SCRUM, Crystal, FDD, ADP, XP) (收起)

2012-04-18 22:19:59 回应

收藏
推荐
书中的四部分内容

白乌鸦 (Understand yourself)

敏捷方法（欠缺）面向对象设计原则（欠缺）设计模式（略微了解） UML（略微了解） (更多)

敏捷方法（欠缺）
面向对象设计原则（欠缺）
设计模式（略微了解）
UML（略微了解）
(收起)

2012-04-18 22:01:40 回应

收藏
推荐
面向对象的设计原则

白乌鸦 (Understand yourself)

SRP：单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。 OCP：开放-封闭原则：软件组件（类、模块、函数等）应该是可以扩展的；但是不可修改 LSP：Liskov替换原则：子类型必须能够替换掉它们的基类型。（这个不懂） DIP：依赖倒置原则：抽象不应该依赖于细节。细节应该依赖于抽象。 ISP：接口隔离原则：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。（不懂） REP：.. (更多)

SRP：单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。
OCP：开放-封闭原则：软件组件（类、模块、函数等）应该是可以扩展的；但是不可修改
LSP：Liskov替换原则：子类型必须能够替换掉它们的基类型。（这个不懂）
DIP：依赖倒置原则：抽象不应该依赖于细节。细节应该依赖于抽象。
ISP：接口隔离原则：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。（不懂）
REP：重用发布等价原则：重用的粒度就是发布的粒度（理解有偏差）
CCP：共同封闭原则：包中的所有类对于同一类性质的变化应该是共同封闭的。。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
CRP：共同重用原则：一个包中所有类应该是共同重用的。如果重用了包中的一个类，就要重用包中所有类（不懂）
ADP：无环依赖原则：在包的依赖关系图中不允许存在环。
SDP：稳定依赖原则：朝着稳定的方向进行依赖。
SAP：稳定抽象原则：包的抽象程度应该和其稳定程度一致。（不懂）
(收起)

2012-04-18 20:59:30 回应

收藏
推荐
第一部分敏捷开发

maverick (不为无益之事,何以遣有生之涯)

过程的敏捷性：采用轻量级的过程方法，尽量发挥人的主观能动性，减少重量级过程方法本身带来的额外工作量。软件的敏捷性：采用面向对象的设计方法和重构等技术使代码能易于改变和扩展。 (更多)

过程的敏捷性：采用轻量级的过程方法，尽量发挥人的主观能动性，减少重量级过程方法本身带来的额外工作量。
软件的敏捷性：采用面向对象的设计方法和重构等技术使代码能易于改变和扩展。

思维导图：敏捷开发思想和过程、关键实践部分
(收起)

2012-02-19 19:16:08 回应

收藏
推荐
第二部分敏捷设计

Wuqifu (喜欢买书的软件工程师~)

腐化的设计僵化性（Rigidity）：难以对系统进行修改脆弱性（Fragility）：改动一个地方，程序许多地方出现问题牢固性（Immobility）：很难解开系统的纠结粘滞性（Viscosity）：做错误的事情容易，做正确的事情困难不必要的复杂性（Needless Complexity）：过度设计，为过多的可能性做准备不必要的重复（Needless Repetition）：重复的代码，开发人员忽视的抽象晦涩性（Opacity）：难以阅读、理解，没有用清晰、富有.. (更多)

腐化的设计
僵化性（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）：不必改动模块的源代码或二进制文件
抽象、多态
Strategy模式、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.低层模块实现了在高层模块中声明的接口，这些接口被高层模块调用
把不稳定的具体类隐藏在抽象接口后面，可以隔离它们的不稳定性
OOP设计倒置了依赖关系结构，使得细节和策略都依赖于抽象
Template Method模式，Bridge模式
五，ISP 接口隔离原则（Least Knowledge Principle）
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
客户程序看到的应该是多个具有内聚接口的抽象基类
客户程序应该仅仅依赖于它们实际调用的方法
Facade模式 (收起)

2011-12-22 00:52:36 回应

收藏
推荐
第一部分敏捷宣言

Wuqifu (喜欢买书的软件工程师~)

个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划 (更多)

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划 (收起)

2011-12-22 00:52:10 回应

收藏
推荐

<前页 1 2 后页>

笔记是你写在书页留白边上的内容；是你阅读中的批注、摘抄及随感。

笔记必须是自己所写，不欢迎转载。摘抄原文的部分应该进行特殊标明。

>敏捷软件开发