关闭

敏捷开发的几大技巧:

标签: 敏捷开发编程单元测试数据库测试user
517人阅读 评论(0) 收藏 举报
分类:
敏捷开发的几大技巧:
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、 结对编程
      结对编程的好处:
    联合两人的知识去对付一个难题。
    知识互相传递。
    更有效的查错跟纠错。
    程序员都很开心。
    减少员工离职的损失。
     结对编程需要的一些技能:
    用代码解释已有的设计结构。
    用例子来解释。
    用图表来解释设计思路。
    如果你无法把你的设计思路表达清楚,把代码写出来。
    让比较迷惑的搭档来写代码,这样他就可以较好的融入你的概念。
    经常的休息。
    经常的更换搭档
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1077939次
    • 积分:12814
    • 等级:
    • 排名:第1102名
    • 原创:241篇
    • 转载:156篇
    • 译文:0篇
    • 评论:227条
    文章分类
    最新评论