本文探讨了重构的概念、目的及其在软件开发中的重要性。介绍了重构的原则、时机选择以及如何克服实施过程中的挑战，包括数据库、接口等问题。
Margin Flower给了两个重构的定义：
（1）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。从这条定义可以看出要进行重构的意义，不是为了添加新的功能，也不是为了提高软件的性能，重构的意义在于提高代码的可读性及可维护及升级性。
（2）：使用一系列重构手法，在不改变软件的可观察的前提下，调整其结构。同上一条相同，强调了不改变软件的可观察性，调整的是程序的整体的结构，貌似这一说法更偏重于程序的架构，但是程序的架构与程序的可读、可维护及可升级有着密切的关系。
2、为何重构
重构的定义已经回答了这个问题，重构的目的就是提高程序的可读、可维护及可升级特性。但是作者有给出了更详细的解释。
重构可以改进软件的设计，很多程序员在完全理解程序架构之前，为了短期的目的会对现有代码进行修改，如给某个类添加接口，或者暴露已经隐藏的接口，甚至直接引用已经隐藏的数据。这会导致程序的架构逐渐的腐败变质。通过重构可以是这些腐败变质的代码恢复到自己本应所在的架构位置。
重构使软件共容易理解，程序设计的目的是与计算机交互，但是用于与计算机交互的代码，却需要与别的程序员进行交互，因此代码的可读性，是关系到项目成败的关键。
但是很多程序员在编写代码的时候并没有考虑到与其交互，或者后期对这段代码进行维护的程序员。有些代码到了后期就连编著者本人都无法理解，就像网上那些经典的代码注释一样。我就曾经经历过这种情况，不要再提那时候的心情了。对这些代码进行重构是必须的，当然在编写代码的时候也要注意，尽量避免这种情况的发生。当然很多时候由于工期等情况的原因，这种事情时刻都在进行着，为了终结这种纠结的心情，进行重构吧。
重构帮助找到bug，很多人由于惯性思维，对自己写的东西基本失去了评判的能力。在进行重构的时候换一种更清晰的思路，对代码进行调整梳理，之前很多惯性思维不能发现的bug，在此时就会现身。
提高编程速度，我也很纠结，感觉重构确实会降低编程速度，因为要浪费编码的时间去进行重构。但是从全局及长期来看，成熟的重构手法却真的能够提高编程速度。试想一下面对一个腐败的架构，一堆堆不知所谓的代码，后期怎么进行维护、扩展以及升级。可能还没到维护、扩展、升级的时候，代码已经遭到了废弃。
3、何时重构
这是一个很重要的问题，不记得是谁说过，项目过早的时候进行重构，我猜想是因为项目此时还没有暴露过的的错误与腐败出来。但是什么时候才是重构的最好时机呢。作者给了一个“三次法则”：添加功能时重构、修补错误时重构、审核代码时重构。其实重构原则也是构建原则，在构建的时候也要注意这些事项（个人愚见）。
4、怎么让项目经理同意重构计划
这个问题很严重，并且不同的项目有不同的情况。发挥个人聪明才智把。
5、重构的难题
代码重构会面临很多难题，作者提了4个：数据库、接口、难以通过重构手法完成的设计改动及何时不进行重构。
数据库：大多数的商用程序都有一个背后紧耦合的数据库，这就是数据库结构难以修改的原因之一。还有一个原因就是数据迁移。在非面向对象的数据库中，在对象模型和数据库模型之间掺入一个分隔层可以解决这个问题。这个分隔层无需在一开始就加入，在发现对象模型变得不稳定时在引入即可。
接口：对于尚未发布的接口，只需要修改所有的调用者就可以了，虽然可能是各个庞大的任务，但是仔细认真，还是可以完成的。对于已经发布到接口，就需要保留原接口，并引入新的接口，让原接口调用新接口。
难以通过重构手法完成的设计改动：如有些架构设计错误，很难通过重构进行改动，这一点还没有理解。有待进一步挖掘。
何时不该重构：记得看设计模式的时候，经典的一句话就是，如果没有理解当前的设计模式，就乱套设计模式，还不如不用。重构应该也是这个道理。重写而不是重构：现有代码根本无法运行。代码中满是错误。重构的前提是程序稳定运行，因此此时不应重构而应该重写。如果程序到了最后的期限也尽量不要重构。
6、重构与设计的关系
重构与设计互补，如前所言重构可以将导致架构腐败的代码引领回他本该所在的位置。Alistair Cockburn说过：“有了设计，我可以思考的更快，但是其中充满了小的漏洞”。重构则可以填补这些小的漏洞。虽然重构在某些情况下能够取代设计，但是我认为必要的设计是不可或缺的。
7、重构与性能的关系
短期看，重构可能会让软件变慢，但是他使优化阶段的软件性能调整更容易，最终会取得好的效果。
8、重构起源何处
这个不太关心，没有仔细看。
扫一扫
2690
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
