众文网1.什么是代码重构
代码重构（英语：Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。
软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：1、去除已知bug。2、提高程序运行效率。
3、增加新的功能。重构举例：（简化代码、提升效率）重构前：if(list != null && list.size() > 0){for(int i = 0; i < list.size(); i++){//skip。
}}重构后if(list != null){for(int i = 0, len = list.size(); i < len; i++){//skip。}}何时着手重构（Refactoring）新官上任三把火，开始一个全新？？、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢？"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。
当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是"队伍变形"的强烈信号：·代码中存在重复的代码中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。
重复建设只会导致效率的低效和资源的浪费。程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。
过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。·类之间需要过多的通讯A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。
这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。·各立山头干革命如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。
笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。
这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。·缺少必要的注释虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。
往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。
2.如何重构代码
先从接触过的几个老项目经历来谈谈，对于老项目来说，大家在初步接触的过程中，大多总是抱着抵触的情绪，甚至有些是蔑视。
总喜欢对以前的代码挑出一大堆的问题，接着就开始抱怨代码、抱怨以前的开发人员，经过一段时间郁闷的抱怨阶段后，处于职业的责任心，就很想去改变这一切，希望把自己认为好的方式给带进来，于是接下来的工作就是重构代码了。 这也许大多数开发人员都经历过，这种经历是辛酸的（因为重构工作虽然重要，但是得不到过多的认可，目前国内关注的是可用性，对于代码质量并没有得到应有的重视），也是甜蜜的（风雨之后总会有彩虹）。
对于年轻的开发人员来说，见到彩虹的过程是痛苦、漫长地。他们都是在失败中成长，这些失败除了经验外，主要是由于太急功尽力了，盲目的重构！ 盲目主要体现在： 1、在还没有对系统整体架构有个清晰认识的时候，就想用自认为新的技术或架构来替换。
2、根本不分析现有系统架构或程序存在的弊端，只是一味地谈设计模式，以设计模式中固有的一套来重构（在重构中，它只作为一个参考，而不是一个依据。） 3、重构比较随性，每个版本的开发都跳出架构之外随意带入新的设计思想 这种盲目重构后给系统会带来更多问题： 你会发现当你重构完后你的系统运行效率变低了， 系统中同时存在多种思想，新加入人员更难接手， 由于你没有完全了解系统，反而在你的重构当中带来了很多重复代码， 最悲剧的是你重构后的代码也被其他人当成垃圾，而进行重构。
那么我们怎么消除盲目呢！？ 首先，了解目前项目是否存在问题，存在什么问题，这些问题是否能通过重构来解决，如果能，才进行重构，你的重构时间是需要公司给的，老板不会因为你说依赖性强偶合性低就同意的，你必须要通过问题来让他认识，关键的是只有通过问题才能得到重构时间和资源，并且你的工作才能得到认可，这是一个很现实的情况。 接下来，你要确定重构的对象，是针对架构还是局部代码，并且去设定一个理想的目标（为什么是理想的？因为我们不可能一步到位，理想和现实是有差距的，但是我们要做的是尽力去往理想上靠拢）。
如果是针对架构进行重构，那么这可不是一件轻松的事情，再真正开始之前需要做到以下几点： 1、全面的了解系统的过去，包括以前的架构/技术背景、业务需求 2、分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等 3、查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历 做到上面几点就是为了保证你能有一个清晰的认识，做到知己知彼。接下来可以进入实质阶段了吗？不行，还少了一个很重要的东西，重构计划！ 这种大范围的重构，在真实情况下，一般老板给予的时间和重构真正所需用的时间相差很大，所以重构的工作是需要往后延迟的，那么就会出现又要重构又要进行新需求的开发；还有这项工作不是一个人的事情，是一个团对，既然涉及到多人合作，除了共同的目标外，还需要有一定的评审机制，这是为了保证重构的方向一致，等等，在这些因素下要做好重构，就是需要重构计划的理由。
针对局部代码进行重构来说，也许会简单的许多，不过需要注意的地方是，你一定要符合现有架构的思想，在它的范围之内去思考。 其实这种方式的重构大多就是提取方法，或者是以真实业务流程的思路去重构现有的代码执行流程，以便易于理解，或者是降低程序之间的依赖性。
要做到这些有个很重要的思维方式： 1、善于从某个事物中分析出什么是事物的本质和什么是事物的外部环境。 2、从很多不同事物中去发现共同点，并对这些共同点进行抽象化（举个简单的例子：对于宝马和奥迪，你应该把他们抽象化为汽车）。
为什么这样说，因为这些能带来重构代码所需要的： 1、在写代码过程中降低了依赖性， 2、抽象化的事物复用性更强 做好上述的所有就表示重构完成了吗！不可能，这只是一个好的开始而已，我们要做到持续重构，就像敏捷中提到的。 也许有的人认为不现实，因为项目经理不会在每个版本周期内给出这个时间，其实，我就纳闷了，为什么不给？！不给的原因一定在你，如果你期望是一周或者更久，那么谁都不会同意，一周的时间都基本都能做完一个版本的设计了，重构还需要这么久，如果真的需要就说明你前期的设计很差！我所希望的时间是两天左右，因为这只局限于很小范围内的变动。
如果你们很好的做这些，那么你的项目可维护性一定很好，并且加入你的项目会是一件愉快的事情，这并不是什么理想的事情，只要你持之以恒地去做，实现起来其实很简单。 架构重构：1、重构计划代码重构：2、提取获取交集的算法3、简单、灵活地实现对象复制。
3.什么是代码重构
代码重构（英语：Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。
软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：1、去除已知bug。2、提高程序运行效率。
3、增加新的功能。重构举例：（简化代码、提升效率） 重构前：if(list != null && list.size() > 0){ for(int i = 0; i < list.size(); i++){//skip。
} }重构后 if(list != null){ for(int i = 0, len = list.size(); i < len; i++){//skip。} } 何时着手重构（Refactoring） 新官上任三把火，开始一个全新？？、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢？"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。
当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是"队伍变形"的强烈信号：·代码中存在重复的代码 中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。
重复建设只会导致效率的低效和资源的浪费。程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法 过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。
过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改 当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。·类之间需要过多的通讯 A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。
这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。·各立山头干革命 如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。
笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计 在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。
这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。·缺少必要的注释 虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。
往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。
4.代码重构的概述
重构（），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，才开始品头论足，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。
所以测试为先，持续重构作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。 在不改变系统功能的情况下，改变系统的实现方式。
为什么要这么做？投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢？重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。
一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢？对软件的生命造成威胁的因素只有一个：需求的变更。
一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。
在这种情况下，软件必须相应的改变。考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。
但是总的说来，软件要适应需求的变化，以保持自己的生命力。这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。
但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。
经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。
最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。重构就能够最大限度的避免这样一种现象。
系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。
通过重构可以达到以下的目标：·持续纠偏和改进软件设计重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。
重构其实就是整理代码，让所有带着发散倾向的代码回归本位。·Martin Flower在《重构》中有一句经典的话：任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。
对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。
一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！·帮助发现隐藏的代码缺陷孔子说过：温故而知新。
重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的感冒。
当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。·从长远来看，有助于提高编程效率当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。
改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。
新官上任三把火，开始一个全新？？、脚不停蹄、加班加点，一支声势浩大的千军万码夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指黄龙府。开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说我有这样。
5.到底是代码重构还是代码修整
我们这个行业里有大量的专业术语被使用。不幸的是，我们并没有对每个术语表达的究竟是什么意思达成共识。我经常听到人们误用“重构（Refactoring）”这个词，导致这种编程方法在很多企业里变成可怕的事情而被拒绝采用。怕什么？据我的观察，大部分都是因为错误的使用了这个术语。
我认为，因为没有对专业术语的使用严加管理，致使整个行业的发展受到连累。如果一个化学家对另一个化学家说“我们准备做滴定（titration）试验”，所有人都清楚的知道是要干什么。我相信计算机科学仍然是一门非常不成熟的科学。如果这个科学能够成熟起来，我们对专业术语的使用就会更加精确和有章法，这样我们的交流就会更加的精确和有效。
重构对于代码质量和可读性的改进是一种非常有效的技术方法。精确的描述：它是一种为了将来的维护和理解而对代码进行改进的一种限制性的修改行为。一个好的例子：把重复的代码提炼成一个方法，所有出现了这重复代码的地方都使用这个方法来代替，以此消除重复。重构是在上世纪90年代早期被第一次提出来讨论的概念，1999年代Martin Fowler的大作《重构》出版之后成为业界普遍接受的技术方法。
重构会导致代码的内部结构发生一些小的变化。这些变化原则上不会对外部产生任何影响。规范的单元测试只从外部来检查代码的行为，是不会发现这些代码是被重构过的。如果代码的结构变化时导致了代码的对外行为发生变化，那这不是重构。
可是，为什么我们的企业的相关人士当听到这么简单而且有用的“重构”技术时会裹足不前呢？我认为这是因为程序员实际上说的是一种更加复杂、成本更高的结构调整技术，因为没有一个合适的术语来表示，就把它叫做“重构”了。重构里的结构调整通常不是代码的推倒重写，很多的现有代码都要重用。人们对此害怕的原因是，他们不知道水有多深，一旦掉进去将要付出多少时间，而且怀疑这种行为能带来多少的好处。
上面说的结构上发生重大变化的例子让我想起来一个新业主接管一个饭店或酒吧后会做的事情。新主人通常会对饭店进行重新装修，让它看起来更有吸引力，更舒适。饭店建筑的大部分都会被保留和重用，这比完全重建会减少大量的成本。依我的经验，当程序员使用“重构”这个术语时，他们真正的意思是，代码库中的某些模块或有边界的上下文内容需要进行重大的修整。如果我们把这个术语定义清楚，让相关人员知道它的目的和意义，那我们就能对项目进行更好的计划和管理了。
这些代码的修整活动必须在之初有清晰的目标，所有的变动必须按照要求进行测试。例如，当我们对业务有了新的认识后，会发现代码没有真正的反映出业务模型。这种认识经过一段时间后不断的积累，代码开始不再满足业务需求。如果使用领域驱动设计（Domain Driven Design），业务模型的本质会被看的更清楚。当对业务有了新的理解后，代码需要大调整来适应新需求。如果为了赶工期，随意在需要的地方进行代码修改，代码的发展会偏离精炼出的设计模型。各处的修改相互不关联，慢慢积累，虽然可以运行，但也带来了不好的副作用。这就需要代码重构。重构的过程中，测试的目的就是要检查这些重大的程序结构调整是否仍然完全的满足改进后的业务设计说明。
对于核心业务将来的发展，或者降低一个关键的模块为应对产品的需求偶尔做出的升级的风险，代码的修整是十分有必要的。
我好奇其他人也是否相似的在开发中出现的这些现象，你觉得对这些概念进行重新定义有意义吗？