敏捷
敏捷估计和规划的12条指导原则
- 让整个小组参与。
- 在不同层次上进行规划。
- 使用不同度量单位，让对规模和持续时间的估计保持独立。
- 用功能或者日期来体现不确定性。
- 经常重规划。
- 跟踪进度并沟通
- 承认学习的重要性。
- 规划具有适当规模的功能。
- 确定功能优先级。
- 把估计和计划建立在事实上
- 保留一些松弛度。
- 通过前瞻规划协调做个小组。
Bob大叔关于Scrum和敏捷的7条缺陷
- 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
- 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
- Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
- 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
- Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
- 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
- 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。
Agile Methodology Mashups
- Pair Programming
- Daily Scrum/Standing Meeting
- Kanban/Burn Down Charts
- Test First Development
敏捷开发中高质量 Java 代码开发实践
OOD & OOP
Composition versus Inheritance
-
Programming to an Interface, Not an Implementation
-
Creational Patterns Considered Obsolete
-
Inversion of Control Containers
-
Composition Realized
[Inheritance] can cause problems when you’re trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability.
Object composition is defined dynamically at run-time (at startup, config-time in most IoC containers –Chad) through objects acquiring references to other objects. Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a payoff. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies (!!! Very important –Chad)
Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class (configured and managed by the IoC container –Chad).
其他
Tags,无序,分类和家族相似
看似普通的Tag其实有着丰富的哲学含义
最近打算给开发和QA的同学介绍一下面向对象和UML相关的内容。这是第一篇，介绍主要面向对象的基础概念和UML类图的绘制。
类
概念：类似对象的一种软件抽象，创建对象的模板。
UML图：属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型。
接口
概念：定义了一套内聚行为的一个或多个操作特性标记的集合。接口是确保送耦合的一种强大的方法。它们允许类参与一套共同的功能集，除了支持接口意外，不需要别的类知道任何有关他的事情。接口的设计要遵循“接口分离原则”，参见什么是面相对象设计的SOLID原则(s)
UML图：接口的UML图展现的样式会有几种变化，但内容都是一样的。
注：在StarUML中可以通过选择Interface元素的Format->【Stereotype Display】、【Suppress Attributes】、【Suppress Operations】来调整。
联系（Association）
概念：实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。
UML图：
- 方向性。开口箭头指出关联的方向。只有一个开口箭头的关联是单向的：它仅可以在一个方向（箭头的方向）上移动。没有箭头时，表示关联是可以在两个方向上移动。
- 标签。标签是可选的，一般有一到两个词组成，用来描述关联。
- 多重性（Multiplicity)。关联的多重性在线的两端标出，每个方向有一个多重性指示器。
聚合（Aggregation）
概念：有时对象会有其他对象组成。例如，飞机由机身、机翼、引擎、起落架等组成。这些全部都是聚合这个概念的例子，它表示“is part of”关系。
UML图：
class Node
{
private:
vector<Node*> itsNodes;
};
上述代码只有当子节点不会成为父节点的父节点时（即，必须是树结构，不能是图结构），才能称之
为聚合。
组合（Composition）
概念：组合是更强形式的聚合，其中“整体”负责部分，每个“部分”对象也仅与一个整体对象联系。例如，
在任何给定时间，引擎是且仅是飞机的一部分。而且，除了飞机以外，其他对象都不能直接与引擎对象发
生交互。
UML图：
class Car
{
public:
virtual ~Car() {delete itsCarb;}
private:
Carburetor* itsCarb
};
依赖（Dependency）
概念：对象之间存在临时关系，只有一个原因，它们可能会相互协作。一个对象与另一个对象进行协作，它需要了解这个对象。这意味着两个对象之间必须存在对象关系或part-of关系。当两个对象之间不存在持久关联的时候，我们需要在两个类之间建立依赖。
UML图：
泛化(Generalization)
概念：表示一个更泛化的元素和一个更具体的元素之间的关系。
UML图：
AbstractKmsTheme被标记为抽象的（名字是斜体）。
实现（Realization）
概念：指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。
UML图
总结面向对象的概念和术语汇总表
| 术语 |
描述 |
| Abstract Class抽象类 |
不能实例化的类 |
| Abstraction抽象 |
一个项目（可能是类或者操作）的本质特征 |
| Aggregation聚合 |
两个类或者组件之间的关系，定义为“is part of” |
| Association关联 |
两个类或者对象之间的关系 |
| Attribute属性 |
类了解的东西（数据/信息) |
| Cardinality基数 |
表示“有多少”的概念 |
| Class类 |
类似对象的一种软件抽象，创建对象的模板 |
| Cohesion内聚 |
封装单元（如组件或者类）的相关程度 |
| Component组件 |
一种内聚功能单元，可以独立开发、发布、由其他组件编辑组成更大的单元。 |
| Composition组合 |
强类型的聚合，其中“整体”完全负责各个组成部分，每个部分对象仅与一个“整体”对象相关联 |
| Concrete Class具体类 |
可以从中实例化对象的类 |
| Coupling耦合 |
两个项目之间的依赖程度 |
| Generalization泛化 |
表示一个更泛化的元素和一个更具体的元素之间的关系。 |
| Inheritance继承 |
定义为“is a”或者“is like”的关系 |
| Instance实例 |
一个对象，它是某个类的一个示例 |
| Instantiate实例化 |
从类定义中创建对象 |
| Interface接口 |
定义了一套内聚行为的一个或多个操作特性标记的集合 |
| Message消息 |
请求星系或者执行任务 |
| Messaging消息传递 |
对象之间通过发送消息相互协作的过程 |
| Method方法 |
有执行值操作的类实现的一个过程（与结构化编程中的函数相似） |
| Multiple Inheritance多重继承 |
直接继承自一个以上的类 |
| Object对象 |
基于类定义的人物、地点、事件、事物等等 |
| Optionality选择性 |
概念“你需要它吗？” |
| Override |
在子类中重新定义属性和/或方法，以使它们与父类中的定义有区别 |
| Pattern |
在考虑相关因素的情况下，通用问题的一个可行性解决方案 |
| Polymorphism多态 |
不同的对象可以以不同的方式响应同一消息，使对象可以交互而不需要知道确切的类型 |
| Property |
在UML2中，是一个命名的值，例如，属性和关联，包括组合，指定元素（例如类或者组件）的一个特征。在Java中，属性的组合包括Getter和Setter |
| Single Inheritance多重继承 |
仅从一个类直接继承 |
| Stereotype构造型 |
建模元素的一种通用用法 |
| Subclass子类 |
继承自另一个类的类 |
| Superclass父类 |
另一个类从中继承的类 |
参考
The Ojbect Primer中文版第二章
UML中的联系、聚合与组合的区别
全面认识UML类图元素
从编程技术到项目管理，Roy Singham、Martin Fowler、Rebecca Parsons等来自ThoughtWorks的思想领袖通过本书中的13篇美文，将自己多年沉思和实践所得倾囊相授，引领你走向敏捷软件开发的成功之路。
本书内容丰富，涵盖了软件开发的各个阶段，既包含DSL、SOA、多语言开发和领域驱动设计等热门主题，也有对象设计、一键发布、性能测试和项目管理等方面的经验之谈和独到见解。不论你是开发人员还是项目管理人员，都将从本书中获益匪浅。
第六章 对象健身操
- 优秀设计背后的核心概念其实并不高深。比如内聚性、松耦合、零重复、封装、可测试性、可读性以及单一职责。这七条评判代码质量的原则就已经被广泛接受了。然而真正困难的是如何把这些概念付诸实践。理解了封装就是隐藏“数据、实现细节、类型、设计或者构造”，这只是设计出良好封装代码的第一步而已。
- 更为严格的编码标准。
- 方法只使用一级缩进
- 拒绝使用else关键字
- 封装所有的原生类型和字符串
- 一行代码只有一个“.”运算符
- 不要使用缩写
- 保持实体对象简单清晰
- 任何类型中的实例变量都不要超过两个
- 使用一流的集合
- 不使用任何Getter/Setter/Property
- 这条规则通常被描述为“讲述而不要询问”（“Tell, dont’t ask”）
- 如果努力地拥抱简单性，那么开发过程会快乐得多。
S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。
单一责任原则
当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。
http://www.diybl.com/course/4_webprogram/jsp/jsp_js/20090304/157704.html
开放封闭原则
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。我对这个原则的理解还是很模糊，还需要在日后的工作、学习过程中慢慢体验:-)。
http://www.cnblogs.com/adam/archive/2008/04/18/1159280.html
里氏替换原则
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系
http://lensping.blog.sohu.com/73111028.html
依赖注入原则
1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
2. 抽象不应该依赖于细节，细节应该依赖于抽象
http://hi.baidu.com/mickeycn/blog/item/e60900129241da56f819b884.html
接口分离原则
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
http://blog.csdn.net/xiaolu123456789/archive/2009/02/26/3941014.aspx
其他重要的面向对象设计原则
The Principles of OOD 这篇文章中介绍了其他一些面向对象设计的原则，有兴趣的同学可以进一步的学习。
总结
这几条原则是非常基础而且重要的面向对象设计原则。正是由于这些原则的基础性，理解、融汇贯通这些原则需要不少的经验和知识的积累。希望能在日后的工作、学习过程中真正的掌握和运用这些原则。
