第四次作业（1,2）

题目

1、敏捷开发是在什么样的背景下产生的？其主要特点有哪些？什么时候选择敏捷开发更恰当，为什么？

2、Code smell 是如何产生的？有哪些典型的 code smell？代码重构(Code refactoring)有哪些优点？有哪些代码重构的方法？

1.1敏捷开发是在什么样的背景下产生的？

敏捷这个词汇最早于2001年被一些热衷于改善软件开发过程的软件工程师用来描述一种能够增加客服满意度的软件开发过程--敏捷式开发过程。

1.2其主要特点有哪些？

敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

　　（1）敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

　　这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。　　　　

（2）敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

　　在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

　　然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。

　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

1.3什么时候选择敏捷开发更恰当，为什么？

小团队，快速反映，以个人能力为中心，用敏捷。
自上而下，建立组织级管理及运行制度，如身之使臂，臂之使指，用cmmi。
2.1Code smell 是如何产生的？

网络释义

1.	代码异味 程序员们通常称它们作代码异味(Code Smell)，但是就我个人认为“代码警报”这个名字更为合适一些，因为它有更高的紧迫感的含义。根 … tianmeide824.blog.163.com|基于142个网页
2.	代码味道 ...码质量，而每个人对代码质量都有一套自己的看法。甚至术语代码味道（code smell） 也已进入大众词汇表，成为描述代码需要改进的 … topkung.blog.163.com|基于132个网页
3.	代码气味的散播 有些人会将代码生成称为代码气味的散播（code smell）。在他们的观点中，如果我们需要生成代码，那么很可能就会做一些错事。 blog.csdn.net|基于57个网页

依此我们可以知道1Code smell 是随着代码产生的
2.2有哪些典型的 code smell？

重复代码: 相同或者相似的代码存在于一个以上的地方。

长方法: 一个非常长的方法、函数或者过程。

巨类: 一个非常庞大的类。

太多的参数: 函数或者过程的冗长的参数列表使得代码可读性和质量非常差。

特性依恋: 一个类过度的使用另一个类的方法。

亲密关系: 一个类依赖另一个类的实现细节。

拒绝继承: 子类以一种‘拒绝’的态度，覆盖基类中的方法，换句话说，子类不想继承父类中的方法，参考Liskov substitution principle。

冗余类 / 寄生虫: 一个功能太少的类。

人为的复杂: 在简单设计已经满足需求的时候，强迫使用极度复杂的设计模式。

超长标识符: 尤其，在软件工程中，应该毫无保留的使用命名规则来消除歧义。

超短标识符: 除非很明显，一个变量名应该反映它的功用。

过度使用字面值: 为提高可读性和避免编码错误，应该使用命名常量。此外，字面值可以且应该在可能的情况下，独立存放于资源文件或者脚本中，在软件部署到不同区域时，可以很方便的本地化。

2.3代码重构(Code refactoring)有哪些优点？

通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

持续纠偏和改进软件设计

帮助发现隐藏的代码缺陷

从长远来看，有助于提高编程效率

2.4有哪些代码重构的方法？

 

提取类/抽离方法

正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。

 

提取方法

像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

 

分离条件

许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。

 

引入参数对象/保留全局对象

在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。

 

用符号常量替换魔法数字

对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。

 

重命名方法

正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是，这种重构方法看起来似乎非常容易理解，但是常常被许多开发者忽视，虽然在Eclipse这种IDE的refactor菜单项中经常出现这一项。