⑴ 如何使用IntelliJ IDEA来重构代码
Ctrl+Alt+L 格式化代码
Ctrl+Shift+J 两行合成一行，删去不必要的空格匹配代码格式
其他快捷键：
【常规】
Ctrl+Shift + Enter，语句完成
“！”，否定完成，输入表达式时按 “！”键
Ctrl+E，最近的文件
Ctrl+Shift+E，最近更改的文件
Shift+Click，可以关闭文件
Ctrl+[ OR ]，可以跑到大括号的开头与结尾
Ctrl+F12，可以显示当前文件的结构
Ctrl+F7，可以查询当前元素在当前文件中的引用，然后按 F3 可以选择
Ctrl+N，可以快速打开类
Ctrl+Shift+N，可以快速打开文件
Alt+Q，可以看到当前方法的声明
Ctrl+P，可以显示参数信息
Ctrl+Shift+Insert，可以选择剪贴板内容并插入
Alt+Insert，可以生成构造器/Getter/Setter等
Ctrl+Alt+V，可以引入变量。例如：new String(); 自动导入变量定义
Ctrl+Alt+T，可以把代码包在一个块内，例如：try/catch
Ctrl+Enter，导入包，自动修正
Ctrl+Alt+L，格式化代码
Ctrl+Alt+I，将选中的代码进行自动缩进编排，这个功能在编辑 JSP 文件时也可以工作
Ctrl+Alt+O，优化导入的类和包
Ctrl+R，替换文本
Ctrl+F，查找文本
Ctrl+Shift+Space，自动补全代码
Ctrl+空格，代码提示（与系统输入法快捷键冲突）
Ctrl+Shift+Alt+N，查找类中的方法或变量
Alt+Shift+C，最近的更改
Alt+Shift+Up/Down，上/下移一行
Shift+F6，重构 – 重命名
Ctrl+X，删除行
Ctrl+D，复制行
Ctrl+/或Ctrl+Shift+/，注释（//或者/**/）
Ctrl+J，自动代码（例如：serr）
Ctrl+Alt+J，用动态模板环绕
Ctrl+H，显示类结构图（类的继承层次）
Ctrl+Q，显示注释文档
Alt+F1，查找代码所在位置
Alt+1，快速打开或隐藏工程面板
Ctrl+Alt+left/right，返回至上次浏览的位置
Alt+left/right，切换代码视图
Alt+Up/Down，在方法间快速移动定位
Ctrl+Shift+Up/Down，向上/下移动语句
F2 或 Shift+F2，高亮错误或警告快速定位
Tab，代码标签输入完成后，按 Tab，生成代码
Ctrl+Shift+F7，高亮显示所有该文本，按 Esc 高亮消失
Alt+F3，逐个往下查找相同文本，并高亮显示
Ctrl+Up/Down，光标中转到第一行或最后一行下
Ctrl+B/Ctrl+Click，快速打开光标处的类或方法（跳转到定义处）
Ctrl+Alt+B，跳转到方法实现处
Ctrl+Shift+Backspace，跳转到上次编辑的地方
Ctrl+O，重写方法
Ctrl+Alt+Space，类名自动完成
Ctrl+Alt+Up/Down，快速跳转搜索结果
Ctrl+Shift+J，整合两行
Alt+F8，计算变量值
Ctrl+Shift+V，可以将最近使用的剪贴板内容选择插入到文本
Ctrl+Alt+Shift+V，简单粘贴
Shift+Esc，不仅可以把焦点移到编辑器上，而且还可以隐藏当前（或最后活动的）工具窗口
F12，把焦点从编辑器移到最近使用的工具窗口
Shift+F1，要打开编辑器光标字符处使用的类或者方法 java 文档的浏览器
Ctrl+W，可以选择单词继而语句继而行继而函数
Ctrl+Shift+W，取消选择光标所在词
Alt+F7，查找整个工程中使用地某一个类、方法或者变量的位置
Ctrl+I，实现方法
Ctrl+Shift+U，大小写转化
Ctrl+Y，删除当前行
Shift+Enter，向下插入新行
psvm/sout，main/System.out.println(); Ctrl+J，查看更多
Ctrl+Shift+F，全局查找
Ctrl+F，查找/Shift+F3，向上查找/F3，向下查找
Ctrl+Shift+S，高级搜索
Ctrl+U，转到父类
Ctrl+Alt+S，打开设置对话框
Alt+Shift+Inert，开启/关闭列选择模式
Ctrl+Alt+Shift+S，打开当前项目/模块属性
Ctrl+G，定位行
Alt+Home，跳转到导航栏
Ctrl+Enter，上插一行
Ctrl+Backspace，按单词删除
Ctrl+”+/-”，当前方法展开、折叠
Ctrl+Shift+”+/-”，全部展开、折叠
Alt+1，项目
Alt+2，收藏
Alt+6，TODO
Alt+7，结构
Ctrl+Shift+C，复制路径
Ctrl+Alt+Shift+C，复制引用，必须选择类名
Ctrl+Alt+Y，同步
Ctrl+~，快速切换方案（界面外观、代码风格、快捷键映射等菜单）
Ctrl+Tab，转到下一个拆分器
Ctrl+Shift+Tab，转到上一个拆分器
【重构】
Ctrl+Alt+Shift+T，弹出重构菜单
Alt+Delete，安全删除
Ctrl+Alt+N，内联
【查找】
Ctrl+F，查找
Ctrl+R，替换
Ctrl+Shift+F，在路径中查找
Ctrl+Shift+R，在路径中替换
Ctrl+Shift+S，搜索结构
Ctrl+Shift+M，替换结构
【VCS】
Alt+~，VCS 操作菜单
Ctrl+K，提交更改
Ctrl+T，更新项目
Ctrl+Alt+Shift+D，显示变化
补充说明：
IDEA
全称IntelliJ
IDEA，是java语言开发的集成环境，IntelliJ在业界被公认为最好的java开发工具之一，尤其在智能代码助手、代码自动提示、重构、
J2EE支持、Ant、JUnit、CVS整合、代码审查、
创新的GUI设计等方面的功能可以说是超常的。IDEA是JetBrains公司的产品，这家公司总部位于捷克共和国的首都布拉格，开发人员以严谨著称的
东欧程序员为主。
⑵ 为什么国内程序员都很少进行代码重构
说到代码的重构对于国外的程序员提到的比较多，特别是大型的开源工程，基本上一个模块或者函数的实现会反复的修改，一个文件能被修改成千上万次，曾经订阅了linux内核组的邮件，每天的收到的修改文件成千上万，有时候一个文件都能被修改上百次，对于文件修改最疯狂的是google的chrome源码，重构的次数，让你觉得每天都在重写但是功能上感觉越来越流畅。为什么我们周围的程序员绝大部分时间做的不是这样的事情。
为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的 科技 创新，从全球开源代码的占比就可以看出，差距还是很巨大的。
为什么觉得老外写的代码比我们的强？
1.国内软件发展主要阶段还在解决有没有，还远谈不上强大
中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。
任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。
所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。
2.软件产业的底子还很薄弱， 历史 积淀还不够
举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。
但是在国外写代码是一种很常见的职业，和别的工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和 历史 的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。
3.公司的文化差异
目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。
小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。
Time is money. 以目前国内互联网的情况，需求应接不暇，程序员基本上都是被需求与业务赶着走，时间非常紧张，在这种情况下，程序员很多时候唯一的选择就是赶紧实现需求的功能。所以，一个项目下来，代码基本上都变得非常非常的“垃圾”。
也有很多程序员想过在项目结尾的时候进行代码的重构，基本上每个程序员也都知道重构代码的好处，但是并不代表着真正能做起来。还是那个原因，国内互联网的速度太快，需求应接不暇，做为程序员，基本上没有时间来做这件事情。
而另外一个原因是跟团队负责人有关。若团队负责人能够意识到重构的好处，那么他可以为此单独划分一段开发时间出来，让大家分别负责一个模块进行重构，这都是可以安排做起来的。这也需要团队负责人如何在需求人员的需求与代码质量的进度上做一个平衡，进行统筹安排。
最后我想说一个可能很少意识到的原因，那就是人员流动问题。国内互联网目前人员流动非常的大，尤其是北上深这样的互联网发达的城市，基本上是平均两年就会走一大波人，在这样的情况下，也会考验从业人员的职业道德，即我到底要把代码写的多好，要把代码的可维护性做到多好，其实这都是从业人员自身需要考验的问题，因为完成一个功能很容易，但是要考虑的全面就是另外一回事了。而人员流动带来的另一个问题就是有一些代码是很难看懂的，即有些代码在人员离开后成为了“ 历史 ”，无人敢动。这也会阻碍着软件的重构工作的进行。
从我所讲的这几种情况来看，重构其实是大家都能知道的好处，但是真正实施起来却又有现实的约束，需要负责人来做这样的统筹安排与推动。
成本太大
大多数软件产品的开发都是经过了很多开发人员的付出，如果进行代码重构需要了解产品、了解框架、了解代码逻辑，这个过程会花费大量的时间和人力成本，对于企业来说，效益是第一位的，与其花费精力进行效益不大的产品重构，不如去承接更多的项目来的实在。
领导决策
由于大部分企业的老板都是非技术人员出身，他们更关注效益和客户，为了符合企业的发展，在进行产品开发时会更多的采用新技术来吸引客户，花费精力重构代码不如开发一套新产品或者开发更酷炫的效果更具有实在意义。
代码规范不足
由于国内互联网较之国外起步较晚，很多企业发展时间较短，加之人员流动比较大等多方面的因素，很难形成标准、严谨、行之有效的代码规范，所以很多技术人员在开发时都是根据个人风格习惯在开发，等其他人接手代码时，缺少相关标准和文档，很难理解代码逻辑，花时间去了解代码、重构代码不如直接推翻重做来的方便。
客户定制化需求
部分企业创业初期对企业信息化是不够重视的，只有企业发展到一定程度才会考虑信息化建设，而由于业务的限制，大多数标准化的互联网产品都很难满足企业的实际需求，需要进行大量定制化的开发，对于互联网企业来说，即使产品开发足够完善，在实际项目中也需要进行扩展，倒不如直接在项目中进行调整。
程序员的发展限定
在国内很少有终身的程序员，大部分都会逐渐转向销售、售前、项目经理、产品经理等岗位，而这些岗位则需要了解业务、了解客户，对技术的需求反而不会太高，所以与其花时间去专研技术不如将更多的精力用在业务和项目层面。
代码能够重构对底层框架要求深度掌握、且代码框架本身要足够灵活，而国内绝大部分技术人员都是停留在对框架的使用层面、少数可以完善、结合使用，极个别的在做同语言山寨或者换一种语言重写，能够对产品体系进行把握、与时俱进扩展实在是凤毛麟角。随着国家的经济提升、IT行业逐渐成熟，在我国这么多IT公司基数下，即便是凤毛麟角的概率，重视基础框架、积累萃取、不断迭代完善的一些技术公司也会慢慢崭露头角、涌现出来的。
【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：
系统没有问题，就是最大的功劳
我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？ 就是尽可能的不要动系统！
可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。
测试覆盖度太低，重构代码没办法保证质量
代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”
这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。
但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。
其他
进行代码重构不是一件容易的事情，务必需要对需求熟悉；对代码 历史 变更熟悉；对代码框架，模块熟悉；对产品更新迭代做好风险把控，时间成本把控……
进行代码重构需要能力非常高，责任心非常强的人进行，甚至需要一个优秀的团队完成。
为什么要代码重构？理由一大堆，我认为主要有两条，一是原代码已不适合扩展新需求，二是原代码已拥肿不堪，乱七八糟。
为什么很少重构？除了上述分析外，还有其他因素，如人员流动快，原团队原作者早已不知何去何从了。又如需求和业务繁多，完成工作开发都累得半死不活，日理万机似的，哪有时间和心情重构？
谢谢大家。
1.国内程序员技术能力不足以进行代码重构
大量的软件从业人员连编程规范都不熟悉，怎么可能做代码重构？更多的人只会写写hello world，只会拷贝粘贴小段代码，连if else这种语句都写不清楚甚至漏掉逻辑，连面向对象的编程思想都没有，谈何重构？
2.国内程序员的沟通能力说服能力一般。
进行软件重构，必须说服经理，让经理相信重构会带来软件质量的提高和故障率的逐步降低，这样经理才会安排人力进行重构。
3.国内软件开发更注重bug的及时解决
国内软件开发大量的人力被分配到解决短期的某个bug，没人抽时间思考如何长久的彻底的解决软件缺陷，其实解决bug不重要，找到软件的缺陷或者性能低下的地方才重要，这些才是重构的点。国内加班加点疲于奔命式的开发，没人考虑bug率是否长期内能够收敛，总是先解决眼前的问题再说，处于一个永远解决bug的死循环里。
这种工作模式是愚蠢的，不是smart的。
软件开发，一定要动脑子，不要蛮干，这不是耕地，力气大就耕的多。
重构代码的目的说白了，就是让软件开发人员更自由。
谢谢楼主的问题，这是一个我特别想回答的问题？
为什么？因为，第一，我是一个对代码有洁癖的人，受不了一坨，一坨那样的代码。第二，我是一个践行Clean Code 的人，给大家我主要负责的一个项目的一组数据（JAVA），总代码量20万行,UT coverage(单元测试代码覆盖率）82%，代码重复率0.5%，代码规则(sonar）违反（Code issue）0,甚至连最低的违反都没有。
也正是因为我的项目在实践Clean Code上的数据，我经常去给不同的团队做分享，也对团队对这个重构不太上心有一些理解。
大致以下几个原因。
第一，也是最多的，交付压力，大部分人都会抱怨，你看我们有这么多新功能，还有那么多bug,根本忙不过来，哪有时间重构？
第二，重构意识不足，老板，管理人员总是希望这个我们要有，那个我们也要实现？为什么？因为别人有，别人有我们没有可能会造成用户流逝。即使有一些有见识的程序员和老板反应这个重构问题，但是重构从来不是高优先级的。毕竟，现在的软件的生命周期可能很短。
第三，人员流动性大，这个是我听过最奇葩的一个理由，我问一个来听培训的哥们，说你代码写成这样，以后怎么维护？这个哥们说，我也知道难维护，但我明年就跳槽了。
第四，设计上就不需要重构，曾经给一个保险公司做分享，我本人也是做金融相关产品后台的，我就问你们这样写代码，可能三四年以后就非常难维护了，还是要尽快重构。他们的回答是，我们不重构，我们只重写。什么意思那？就是一个系统，三四年以后在写一遍。
第五，程序员本身的问题，可能第一写单元测试，修改命名，修改代码结构，是一件很没有成就感的事情，也是一个没有多少附加值的事情。毕竟现在你去找工作，这个代码质量方面的问题会问得很少。
第六，我见过的我不能反驳的一个回答，我的英文太差，不能很好的命名，而我也不想学英文。
第七，反正我已经实现了功能。
最后，用一句话来提醒程序员们，重构是多么重要。
出来混迟早要还的，挖了坑迟早要填的。
在国内，【重构】这件事是程序员最喜欢做的事，而不是公司喜欢做的事。
但程序员喜欢并不能影响公司的决策，所以，国内的现象就是软件系统很少有重构。
其根本的原因在于，国内的公司所推出的系统大多没有重构的价值。
1、国内的互联网公司存在这样一种快节奏，那就是发现一个有价值的创意，就马上进入开发，开发完成立即上线，并立马推广使用。这是一种快速试错的模式，一旦发现系统在 社会 中没有引起反响，那就马上把系统再下线。这种情况下的系统哪来的重构价值呢？
2、即使一个系统上线成功了，也积累了大量的用户，貌似为了系统的稳定性和性能，可以有重构的机会。但事实上不是，国内公司仍旧不会选择重构，因为重构带不来新的价值。所以，公司多数都会在系统上添加新的功能来吸引新的客户，而不会考虑重构现有系统。
总得来说，引起重构的原因在于能够有持续的价值。没有价值的事，企业当然不会做，仅是程序员的一厢情愿而已。
你只是见到了你所在的公司现象，不代表所有，也不能代表大部分的。
代码重构还是存在的现象
代码设计烂，经常出问题、扩展麻烦、维护心累、数据混乱、结果不清醒、模块划分混乱
就可能要考虑到重构了
呵呵，
老大说：
你赶紧去修复一下这个bug，
还有几个功能没有实现，加班搞一下，
pm 说：
这个功能改一下，
还有这个，界面重新调整一下，
这个业务流，现在不一样了，
客户需求需要多几个功能，
老板说：
这东西下周能出来吗？
⑶ 如何重构代码
先从接触过的几个老项目经历来谈谈，对于老项目来说，大家在初步接触的过程中，大多总是抱着抵触的情绪，甚至有些是蔑视。总喜欢对以前的代码挑出一大堆的问题，接着就开始抱怨代码、抱怨以前的开发人员，经过一段时间郁闷的抱怨阶段后，处于职业的责任心，就很想去改变这一切，希望把自己认为好的方式给带进来，于是接下来的工作就是重构代码了。 这也许大多数开发人员都经历过，这种经历是辛酸的（因为重构工作虽然重要，但是得不到过多的认可，目前国内关注的是可用性，对于代码质量并没有得到应有的重视），也是甜蜜的（风雨之后总会有彩虹）。对于年轻的开发人员来说，见到彩虹的过程是痛苦、漫长地。他们都是在失败中成长，这些失败除了经验外，主要是由于太急功尽力了，盲目的重构！ 盲目主要体现在： 1、在还没有对系统整体架构有个清晰认识的时候，就想用自认为新的技术或架构来替换。 2、根本不分析现有系统架构或程序存在的弊端，只是一味地谈设计模式，以设计模式中固有的一套来重构（在重构中，它只作为一个参考，而不是一个依据。） 3、重构比较随性，每个版本的开发都跳出架构之外随意带入新的设计思想 这种盲目重构后给系统会带来更多问题： 你会发现当你重构完后你的系统运行效率变低了， 系统中同时存在多种思想，新加入人员更难接手， 由于你没有完全了解系统，反而在你的重构当中带来了很多重复代码， 最悲剧的是你重构后的代码也被其他人当成垃圾，而进行重构。 那么我们怎么消除盲目呢！？ 首先，了解目前项目是否存在问题，存在什么问题，这些问题是否能通过重构来解决，如果能，才进行重构，你的重构时间是需要公司给的，老板不会因为你说依赖性强偶合性低就同意的，你必须要通过问题来让他认识，关键的是只有通过问题才能得到重构时间和资源，并且你的工作才能得到认可，这是一个很现实的情况。 接下来，你要确定重构的对象，是针对架构还是局部代码，并且去设定一个理想的目标（为什么是理想的？因为我们不可能一步到位，理想和现实是有差距的，但是我们要做的是尽力去往理想上靠拢）。 如果是针对架构进行重构，那么这可不是一件轻松的事情，再真正开始之前需要做到以下几点： 1、全面的了解系统的过去，包括以前的架构/技术背景、业务需求 2、分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等 3、查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历 做到上面几点就是为了保证你能有一个清晰的认识，做到知己知彼。接下来可以进入实质阶段了吗？不行，还少了一个很重要的东西，重构计划！ 这种大范围的重构，在真实情况下，一般老板给予的时间和重构真正所需用的时间相差很大，所以重构的工作是需要往后延迟的，那么就会出现又要重构又要进行新需求的开发；还有这项工作不是一个人的事情，是一个团对，既然涉及到多人合作，除了共同的目标外，还需要有一定的评审机制，这是为了保证重构的方向一致，等等，在这些因素下要做好重构，就是需要重构计划的理由。 针对局部代码进行重构来说，也许会简单的许多，不过需要注意的地方是，你一定要符合现有架构的思想，在它的范围之内去思考。 其实这种方式的重构大多就是提取方法，或者是以真实业务流程的思路去重构现有的代码执行流程，以便易于理解，或者是降低程序之间的依赖性。要做到这些有个很重要的思维方式： 1、善于从某个事物中分析出什么是事物的本质和什么是事物的外部环境。 2、从很多不同事物中去发现共同点，并对这些共同点进行抽象化（举个简单的例子：对于宝马和奥迪，你应该把他们抽象化为汽车）。 为什么这样说，因为这些能带来重构代码所需要的： 1、在写代码过程中降低了依赖性， 2、抽象化的事物复用性更强 做好上述的所有就表示重构完成了吗！不可能，这只是一个好的开始而已，我们要做到持续重构，就像敏捷中提到的。 也许有的人认为不现实，因为项目经理不会在每个版本周期内给出这个时间，其实，我就纳闷了，为什么不给？！不给的原因一定在你，如果你期望是一周或者更久，那么谁都不会同意，一周的时间都基本都能做完一个版本的设计了，重构还需要这么久，如果真的需要就说明你前期的设计很差！我所希望的时间是两天左右，因为这只局限于很小范围内的变动。 如果你们很好的做这些，那么你的项目可维护性一定很好，并且加入你的项目会是一件愉快的事情，这并不是什么理想的事情，只要你持之以恒地去做，实现起来其实很简单。 架构重构：1、重构计划代码重构：2、提取获取交集的算法3、简单、灵活地实现对象复制
⑷ 什么是代码重构
代码重构（英语：Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。
软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：
1、去除已知bug。
2、提高程序运行效率。
3、增加新的功能。
重构举例：（简化代码、提升效率）
重构前：
if(list!=null&&list.size()>0){
for(inti=0;i<list.size();i++){
//skip...
}
}重构后
if(list!=null){
for(inti=0,len=list.size();i<len;i++){
//skip...
}
}
何时着手重构（Refactoring）
新官上任三把火，开始一个全新??、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢？"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。
Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是"队伍变形"的强烈信号：
·代码中存在重复的代码
中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。
程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法
过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改
当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。
·类之间需要过多的通讯
A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链
"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。
·各立山头干革命
如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计
在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。
·缺少必要的注释
虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。