敏捷开发的几大技巧：

敏捷开发的几大技巧：
1、移动重复代码;
2、将注解转换为代码:将注释转换为代码,让代码足够清楚到可以表示注释,如将一部分代码重构成方法,用方法名来

表达注释的意思。
3：除去代码异味：
   第一种异味：代码用了类别代码（type code）如final int TYPERECTANGLE = 1;
   第二种异味：Shape 这个类有很多属性有时候是不用的;
   第三种异味：我们想给p1,p2 取个好一点的变量名都做不到，因为不同的情况下，它们有不同的含义：
   第四种异味：drawShapes这个方法里面，有个switch表达式。当我们用到switch（或者一大串的if-then-else-

if）时，小心了。switch表达式经常是跟类别代码（type code）同时出现的。
    消除代码异味方法：
    针对第一种,大多数情况下，要想去掉一个类别代码，我们会为每一种类别建立一个子类.再使用就要用

instanceof来判断对象。
    要移动一些类别代码和switch表达式，有两种方法：
    a.用基于同一父类的不同子类来代替不同的类别。
    b.用一个类的不同对象来代替不同的类别。
    
4.保持代码简洁
要判断一个类是否需要修整，一个比较主观的方法是：当在读一个类的代码时，看看我们会不会觉得这个类
“太长了”，“太复杂了”，或者讲的概念“太多了”？如果会这样觉得的话，我们就认定，这个类需要修整.
单一职责原则（The Single Responsibility Principle）认为:每个类都应该只为一个理由而修改.
5.慎用继承:
当我们想要让一个类继承自另一个类时，我们一定要再三的检查：子类会不会继承了一些它不需要的功能（属性或

者方法）？如果是的话，我们就得认真再想想：它们之间有没有真正的继承关系？如果没有的话，就用代理。如果

有的话，将这些不用的功能从基类转移到另外一个合适的地方去。
如果一个父类描述的东西不是所有的子类共有的，那这个父类的设计肯定不是一个好的设计。

里斯科夫替换原则(LSP)表述：Subtype must be substitutable for their base types. 子类应该能够代替父类的
功能。或者直接点说，我们应该做到，将所有使用父类的地方改成使用子类后，对结果一点影响都没有。或者更
直白一点吧，请尽量不要用重载，重载（类中可以相同的方法名不同的参数）是个很坏很坏的主意。

6处理不合适的依赖
  怎么判断是“不合适的依赖”
  方法1：
一个简单的方法就是：我们先看一下这段代码里面有没有一些互相循环的引用。比如，ZipMainFrame引用了
ZipEngine这个类，而ZipEngine又引用了ZipMainFrame。我们管这样的类叫“互相依赖”。互相依赖也是一种代
码异味，我们就认定这样的代码，是“不合适的依赖”。
  方法2：
另一个方法比较主观：在检查代码的时候，我们问自己：对于它已经引用的这些类，是它真正需要引用的吗？
  方法3：
第3 种方法也很主观：在设计类的时候，我们先预测一个以后可能会重用这个类的系统。然后再判断，在那
样的系统中，这个类能不能被重用？如果你自己都觉得以后的系统不能重用这个类的话，你就断定，这个类包含
“不合适的依赖”了。
   方法4
第4 个方法比较简单而且客观了。当我们想在一个新系统中重用这个类，却发现重用不了时，我们就判断，
这个类包含了“不合适的依赖”。
解决方法：除掉其中的依赖类，利用接口来处理。
依赖反转原则（Dependency Inversion Principle ）表述：抽象不应该依赖于具体，高层的比较抽象的类不应该
依赖于低层的比较具体的类。当这种问题出现的时候，我们应该抽取出更抽象的一个概念，然后让这两个类依赖
于这个抽取出来的概念
7、 将数据库访问，UI和域逻辑分离
  先抽取出数据库访问层，然后将领域逻辑将表示层也分离。
8、以用户例事管理项目  (也就通常我们所说的用例)
   一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或

者“用户例事(user story)”。也就是说，上面我们的客户所说的话，就是在描述一个用户例事（user story）。
9、 用CRC卡协助设计
    写上了类名，它的职责，以及它的协作关系，我们管这样的卡片叫“CRC卡”。CRC就是Class，Responsibility

和Collaboration的简称
10、 验收测试
11、 对UI进行验收测试
12、 单元测试
13、 测试驱动编程
14、 结对编程
      结对编程的好处：
    联合两人的知识去对付一个难题。
    知识互相传递。
    更有效的查错跟纠错。
    程序员都很开心。
    减少员工离职的损失。
     结对编程需要的一些技能：
    用代码解释已有的设计结构。
    用例子来解释。
    用图表来解释设计思路。
    如果你无法把你的设计思路表达清楚，把代码写出来。
    让比较迷惑的搭档来写代码，这样他就可以较好的融入你的概念。
    经常的休息。
    经常的更换搭档