1、敏捷开发是在什么样的背景下产生的？其主要特点有哪些？什么时候选择敏捷开发更恰当，为什么？
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发有如下特征:
1. 工作在小的团队中
2. 团队是跨功能的-包括测试人员，开发人员，文档开发人员等等
3. 短迭代-利用短迭代方法来交付软件
4. 相较于文档，敏捷开发更注重面对面的交流
5. 敏捷不是一个过程，而是一个软件开发的形式或者方法
6. 敏捷可以与软件过程如CMMI等一起实施
2、Code smell 是如何产生的？有哪些典型的 code smell？代码重构(Code refactoring)有哪些优点？有哪些代码重构的方法？
code smell译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，人可以通过这种smell（异味）在代码中追捕到问题。在计算机编程社区中,code smell代表了任何标志着事物变坏的征兆。它常常标志代码应该被refactored或者全部的设计都应该被reviewed。这个短语出现在 wardswiki上，它是被kent beck杜撰出来的。在refactoring兴起之后，这个短语的使用率骤增。 判断是否存在code smell经常是主观判断，并且随着语言、开发者、开发理论的不同而存在差异。经验丰富和知识渊博的人通过对优秀设计有一种“感觉”，他们已经达到一种称之为“无意识能力 （unconsciouscompetence）”的状态。也就是说，他们无需思考，只要通过查看代码或一段设计就可以立马对这个项目的代码质量有一种 “感觉”，能够对代码设计的优劣有一个大致的判断。code smell只是一种“暗示”，而非一种“确定”。将某些事物称之为“code smell”并未是一种攻击；它只是一种提示：人需要对项目设计进行更进一步的查看。因此，code smell更多是“直觉的，本能的”。
典型的 code smell：1．duplicated code2．long method3．large class4．divergent change5．shotgun surgery6．feature envy7．data clumps8．primitive obsession9．switch statement10． parallel inheritance hierarchies11． lazy classv12． speculative generality13． temporary field14． message chain15． middle man16． inappropriate intimacy17． alternative classes with different interface18． incomplete library class
三、哪些情况需要考虑代码重构
臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
长方法: 方法之所以会变得很长主要是有以下几个原因：
1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。
2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。
大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。
常量值无处不在: 经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。
模糊的方法名: 许多时候，以下取的方法名会影响代码的可读性和可理解性：
1、模糊的不具有任何意义的方法名
2、技术性的，却没有提及相关领域的名称
代码重构的方法
提取类/抽离方法
正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
提取方法
像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。
分离条件
许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。
引入参数对象/保留全局对象
在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。
用符号常量替换魔法数字
对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。
重命名方法
正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是，这种重构方法看起来似乎非常容易理解，但是常常被许多开发者忽视，虽然在Eclipse这种IDE的refactor菜单项中经常出现这一项。