题目：
1、敏捷开发是在什么样的背景下产生的？其主要特点有哪些？什么时候选择敏捷开发更恰当，为什么？
2、Code smell 是如何产生的？有哪些典型的 code smell？代码重构(Code refactoring)有哪些优点？有哪些代码重构的方法？
1.答：敏捷软件开发产生的背景：
（1）软件开发的新挑战
a：快速的市场进入时间，要求高生产率
b：快速变化的需求
c：快速发展的技术
（2）传统的软件开发方法
a：强调过程和文档
b：对变化的适应能力偏弱
敏捷软件开发的特点：
a.敏捷宣言表明的是一些优先级，不必当做圣旨或则教条来争论
b：致力于降低变化的成本
c：价值导向
d：充分发挥人的积极性
e：基于增量和迭代的开发方法
敏捷的试用范围：
| 产品可靠性要求 | 不高，容忍经常出错 |
| 需求变化 | 经常变化 |
| 团队人员数量 | 不多 |
| 人员经验 | 有资深程序员带队 |
| 公司文化 | 鼓励变化，行业充满变数 |
| 实际的例子 | 写一个微博网站 |
| 用错方式的后果 | 用敏捷的方法卡法登月火箭控制程序，前N批宇航员都挂了 |
从敏捷开发软件的适应范围中，可以得出敏捷开发在产品要求不高，容忍经常出错；需求经常变化；团队人数不多；有资深程序员带队的情况下选择敏捷开发软件更适合。
2.答：Code Smell产生的背景：Code Smell中文译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，开发人员可以通过这种smell（异味）在代码中追捕到问题。代码味道是由我们开发人员根据自己的一些工作经验积累来判断的，有人觉得代码注释可以体现代码结构和质量，还有些人又认为代码注释是用来解释过于复杂代码的一种说明机制。显然，Javadocs? 很有用，但是多少内嵌注释才足以维护代码？如果代码已经编写得足够好，它还需要自己解释吗？从这些我们可以看出代码味道是一种主观评估的机制，在很多情况下面，尽管一些看其来糟透了的代码可能是他人曾经编写最好的代码。在我们工作中，是否有很多这样的声音，”是的，初看起来有点乱，但是它的扩展性不错”。因此，我们需要客观评估代码质量的方法，某种可以决定性地告诉我们正在查看的代码是否存在风险的东西。
典型的Code Smell：
- Duplicated Code。代码重复几乎是最常见的异味了。他也是Refactoring 的主要目标之一。代码重复往往来自于copy-and-paste 的编程风格。与他相对应OAOO 是一个好系统的重要标志
- Long method。它是传统结构化的“遗毒”。一个方法应当具有自我独立的意图，不要把几个意图放在一起，特别注意大类和长方法。
- Large Class。大类就是你把太多的责任交给了一个类。这里的规则是One Class One。
- Shotgun Surgery。这正好和上面相反。对系统一个地方的改变涉及到其他许多地方的相关改变。这些变化率和变化内容相似的状态和行为通常应当放在同一个类中。
- Feature Envy。对象的目的就是封装状态以及与这些状态紧密相关的行为。如果一个类的方法频繁用get 方法存取其他类的状态进行计算，那么你要考虑把行为移到涉及状态数目最多的那个类。
- Data Clumps。某些数据通常像孩子一样成群玩耍：一起出现在很多类的成员变量中，一起出现在许多方法的参数中……，这些数据或许应该自己独立形成对象。
- Switch Statement。基于常量的开关语句是OO 的大敌，你应当把他变为子类、state 或strategy。
- Parallel Inheritance Hierarchies。并行的继承层次是shotgun surgery 的特殊情况。因为当你改变一个层次中的某一个类时，你必须同时改变另外一个层次的并行子类。
- Lazy Class。一个干活不多的类。类的维护需要额外的开销，如果一个类承担了太少的责任，应当消除它。
- Speculative Generality。一个类实现了从未用到的功能和通用性。通常这样的类或方法唯一的用户是test case。不要犹豫，删除它。
- Message Chain。消息链发生于当一个客户向一个对象要求另一个对象，然后客户又向这另一对象要求另一个对象，再向这另一个对象要求另一个对象，如此如此。这时，你需要隐藏分派。
- Middle Man。对象的基本特性之一就是封装，而你经常会通过分派去实现封装。但是这一步不能走得太远，如果你发现一个类接口的一大半方法都在做分派，你可能需要移去这个中间人。
- Data Class。对象包括状态和行为。如果一个类只有状态没有行为，那么肯定有什么地方出问题了。
- Refused Bequest。超类传下来很多行为和状态，而子类只是用了其中的很小一部分。这通常意味着你的类层次有问题。
- Comments。经常觉得要写很多注释表示你的代码难以理解。如果这种感觉太多，表示你需要Refactoring。
代码重构(Code refactoring)的优点：
1·持续偏纠和改进软件设计
2·使代码更易为人所理解
3·帮助发现隐藏的代码缺陷
4·从长远来看，有助于提高编程效率
重构的方法
1. 提取类/抽离方法
正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
2.提取方法
像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。
3.分离条件
许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。
4.引入参数对象/保留全局对象
在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。
5.用符号常量替换魔法数字
对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。
6.重命名方法
正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是，这种重构方法看起来似乎非常容易理解，但是常常被许多开发者忽视，虽然在Eclipse这种IDE的refactor菜单项中经常出现这一项。