考虑了很久才决定发上来，因为这个话题很有可能会挨一顿批，后来想了想不挨批 ，怎么可以学到东西呢，所以还是决绝的发了上来。
重构这个话题从概念上来说挺好理解，即重新整理自己以前写过的代码，重构的好处不言而喻，它有助于代码的可读性，可维护性，也有利于代码的可调试性，那什么时候该重构，什么样的代码值得重构呢，以及怎样去重构这些代码，这里我谈一下我的看法。
在开发一个系统时，随着代码的不断增长，也为了完成上面布置下来的进度，对于代码的结构上考虑的可能相对就少了点，也许此时问题慢慢的出现了，但因为还能继续下去，所以也只是在心里预算，在以后留下一段时间来专门的做重构，这样是对的吗，我想这确实绝不能算错的，因为这也算是敏捷开发当中的一个思想吧，可很多时候真得到了一定的时候才去重构吗，其实我倒觉得重构应该是无时不在的，当你在要增加一个功能，找到相对应代码时，如果你觉得它对于你增加的这个简单功能需要配置多个地方，或者说在以后增加类似功能时，又不得不写很多相同代码，还有就是你觉得如果你修正了这段代码后，能让代码结构性更清晰，更好的调试，那也许此时你可以考虑重构了，当然对于重构我觉得很多时候还是不能一个人拿主意，因为你必须考虑到你是团队中的一员，所以你更应该与写这段代码的程序员共同商量，因为有些时候，这段代码可能不需要重构，只是因为与你的思维习惯有点不同（很多时候，争论也是因此而产生），如果说，那个程序员在听了你的意见后，也觉得有道理，重构此段代码是对以后的扩展有好处，而且能更好的管理，那这样你还说什么呢，开始重构吧。
什么样的代码需要重构，我想这点很多时候，是可能跟一个程序员的经验来判断的，很多有经验的程序员，在阅读某段代码时，可能很快就可以嗅出这段代码里面的异味，如程序里面大量的充斥着SWITCH语句，代码里面大量的重复代码，大量的临时变量，一个函数从头到结尾几百行，一个CLASS里面完成的功能太多等等，碰到这些代码，我觉得你也可以拿起重构这个武器，对它进行手术般的修整了。
看到需要重构的代码，以及跟团队成员讨论确定可以重构，那此时就可以开始重构了，那怎么才能去重构呢，这也许又是一个问题了，拿我自己来说，我觉得以面向对象的思想去重构可以很好的解决这个问题，面向对象最精髓的就是“抽象”，把一个大的东西以一个模块来对待， 再在大模块里面区分出各个小模块，彼此理清各此的继承关系，以及清楚各个小模块各自的功能，如果可以还可以在小模块里面再划分，只要保证以下几个原则，可维护，可扩展，可复用。 下面我来说一下我遇到的一个案例，以及最后我采取的重构方法（挺简单的，但很有针对性）
我们现在在开发一个系统，里面牵涉到很多的报表，当时也因为工期的问题，对于代码的结构性上面考虑的较少，所以后来准备推翻重来，只是这次重来需要保证几个问题，也就是上面提到的，可扩展，可维护，以及对于特定报表的修改不至于影响到整体报表，考虑到以上几个问题，再具体的查看了以前的代码（虽说以前的代码不具重用性，但可以从中获取这些报表的一些共通点），在仔细查阅后，我发现这些报表可以分为很多种类，而且这些类型的报表都有一个共同点，就是模板里面上部分显示图表，下部分是显示数据。基于这些特点，我开始准备重新设计，首先我确信这些报表应该是可以构成一个模块的概念，而这个大的模块又可以分类成各种报表类型的模块，各种类型的模块呢还可以再分特定的报表，这样结构就可以一下子清晰了，再抽象，上面说了，所有的报表是由两部分组成，即图表与数据两部分，这样我们就可以抽象出基类，只包含两个方法，所有的报表类型都继承于它，所有的特定报表再继承上一层所属的报表类型，这样整个结构 就出来了，文件结构也按照此种思想，新建了一个报表文件夹，里面包含各种类型的文件夹，各个类型文件夹里面又包含了各个具体的报表文件，再通过继承关系，把它们组织起来，最终在外部调用他们，只需要封装一个类，用于专门获取具体的报表对象，然后再对具体的报表对象进行操作，这样就解决了上面提到的几个要求，下面是比较新老两个版本
在旧版本里面，所有的具体报表都是通过SWITCH来判断，各个分支等于处理一个报表，而当时又因为想共用数据部分，最终他们调用的都是同一个获取的数据方法，而因为在页面显示时，数据组织形式又相当的复杂，最后搞得整个MODEL无法查阅，要想再添加一个报表，那简直是不可能的
新版本里面，各个具体的报表操作自己的文件，数据调用也是调用自己的数据模型，数据模型里面只负责数据的取操作，所有的逻辑操作都在具体的报表里面完成，而最外层的调用，也只是调用，不处理任何的逻辑操作，这样等于修改一个报表或者说增加一个报表时，就很有针对性的修改与增加了，再怎么变，再怎么增加也不会影响到其余的报表，当然这个结构可能也只是暂时的适应这个时候，在以后的发展过程中也会不断的提炼。
就说到这吧，反正这就是我的一点理解，相信很多大神们都有自己的意见，因为在这个方面没有一个标准的答案，也许很多同行看到这篇文章，会给出一词“一毛不值”，呵，现在我也不管那么多了，只想着用这篇文章来做一个抛砖引玉，也想多学习一下各种更好的重构手法。
重构这个话题从概念上来说挺好理解，即重新整理自己以前写过的代码，重构的好处不言而喻，它有助于代码的可读性，可维护性，也有利于代码的可调试性，那什么时候该重构，什么样的代码值得重构呢，以及怎样去重构这些代码，这里我谈一下我的看法。
在开发一个系统时，随着代码的不断增长，也为了完成上面布置下来的进度，对于代码的结构上考虑的可能相对就少了点，也许此时问题慢慢的出现了，但因为还能继续下去，所以也只是在心里预算，在以后留下一段时间来专门的做重构，这样是对的吗，我想这确实绝不能算错的，因为这也算是敏捷开发当中的一个思想吧，可很多时候真得到了一定的时候才去重构吗，其实我倒觉得重构应该是无时不在的，当你在要增加一个功能，找到相对应代码时，如果你觉得它对于你增加的这个简单功能需要配置多个地方，或者说在以后增加类似功能时，又不得不写很多相同代码，还有就是你觉得如果你修正了这段代码后，能让代码结构性更清晰，更好的调试，那也许此时你可以考虑重构了，当然对于重构我觉得很多时候还是不能一个人拿主意，因为你必须考虑到你是团队中的一员，所以你更应该与写这段代码的程序员共同商量，因为有些时候，这段代码可能不需要重构，只是因为与你的思维习惯有点不同（很多时候，争论也是因此而产生），如果说，那个程序员在听了你的意见后，也觉得有道理，重构此段代码是对以后的扩展有好处，而且能更好的管理，那这样你还说什么呢，开始重构吧。
什么样的代码需要重构，我想这点很多时候，是可能跟一个程序员的经验来判断的，很多有经验的程序员，在阅读某段代码时，可能很快就可以嗅出这段代码里面的异味，如程序里面大量的充斥着SWITCH语句，代码里面大量的重复代码，大量的临时变量，一个函数从头到结尾几百行，一个CLASS里面完成的功能太多等等，碰到这些代码，我觉得你也可以拿起重构这个武器，对它进行手术般的修整了。
看到需要重构的代码，以及跟团队成员讨论确定可以重构，那此时就可以开始重构了，那怎么才能去重构呢，这也许又是一个问题了，拿我自己来说，我觉得以面向对象的思想去重构可以很好的解决这个问题，面向对象最精髓的就是“抽象”，把一个大的东西以一个模块来对待， 再在大模块里面区分出各个小模块，彼此理清各此的继承关系，以及清楚各个小模块各自的功能，如果可以还可以在小模块里面再划分，只要保证以下几个原则，可维护，可扩展，可复用。 下面我来说一下我遇到的一个案例，以及最后我采取的重构方法（挺简单的，但很有针对性）
我们现在在开发一个系统，里面牵涉到很多的报表，当时也因为工期的问题，对于代码的结构性上面考虑的较少，所以后来准备推翻重来，只是这次重来需要保证几个问题，也就是上面提到的，可扩展，可维护，以及对于特定报表的修改不至于影响到整体报表，考虑到以上几个问题，再具体的查看了以前的代码（虽说以前的代码不具重用性，但可以从中获取这些报表的一些共通点），在仔细查阅后，我发现这些报表可以分为很多种类，而且这些类型的报表都有一个共同点，就是模板里面上部分显示图表，下部分是显示数据。基于这些特点，我开始准备重新设计，首先我确信这些报表应该是可以构成一个模块的概念，而这个大的模块又可以分类成各种报表类型的模块，各种类型的模块呢还可以再分特定的报表，这样结构就可以一下子清晰了，再抽象，上面说了，所有的报表是由两部分组成，即图表与数据两部分，这样我们就可以抽象出基类，只包含两个方法，所有的报表类型都继承于它，所有的特定报表再继承上一层所属的报表类型，这样整个结构 就出来了，文件结构也按照此种思想，新建了一个报表文件夹，里面包含各种类型的文件夹，各个类型文件夹里面又包含了各个具体的报表文件，再通过继承关系，把它们组织起来，最终在外部调用他们，只需要封装一个类，用于专门获取具体的报表对象，然后再对具体的报表对象进行操作，这样就解决了上面提到的几个要求，下面是比较新老两个版本
在旧版本里面，所有的具体报表都是通过SWITCH来判断，各个分支等于处理一个报表，而当时又因为想共用数据部分，最终他们调用的都是同一个获取的数据方法，而因为在页面显示时，数据组织形式又相当的复杂，最后搞得整个MODEL无法查阅，要想再添加一个报表，那简直是不可能的
新版本里面，各个具体的报表操作自己的文件，数据调用也是调用自己的数据模型，数据模型里面只负责数据的取操作，所有的逻辑操作都在具体的报表里面完成，而最外层的调用，也只是调用，不处理任何的逻辑操作，这样等于修改一个报表或者说增加一个报表时，就很有针对性的修改与增加了，再怎么变，再怎么增加也不会影响到其余的报表，当然这个结构可能也只是暂时的适应这个时候，在以后的发展过程中也会不断的提炼。
就说到这吧，反正这就是我的一点理解，相信很多大神们都有自己的意见，因为在这个方面没有一个标准的答案，也许很多同行看到这篇文章，会给出一词“一毛不值”，呵，现在我也不管那么多了，只想着用这篇文章来做一个抛砖引玉，也想多学习一下各种更好的重构手法。
————————————————————————————————
基于CSDN论坛提供的插件扩展功能，自己做了个签名档工具，分享给大家，欢迎技术交流 :)