重构原则

• 何谓重构

重构的两种定义，一种名词形式，一种是动词形式：
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件之可察行为前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构准则（手法），在不改变软件之可察行为前提下，调整其结构。

重构不仅仅是整理代码，它提供了一种更高效且受控的代码整理技术。

两顶帽子：‘添加新功能’和‘重构’，在软件开发过程中，你可能会发现自己经常变换帽子，但无论何时你都应该清楚自己戴的是哪一顶帽子。

我的理解：重构是种约束性的软件结构调整行为，它有一系列准则，其约束性是不改变软件之可察行为。

• 为何重构？

重构改进软件设计；

可以改善腐败变质的程序，你所作的就是让所有东西回到应该的位置上；消除重复代码，你可以确定代码将所有事物和行为都只表述一次，唯一一次，这正是优秀设计的根本。

重构使软件更易被理解；

编程模式的核心就是“准确说出吾人所欲”。    

重构助你找到臭虫；

搞清楚程序结构的同时，也清楚了所做的一些假设，从这个角度说，不找到臭虫都难矣。

重构助你提高编程速度；

重构可提高软件质量（改善设计、提升可读性、减少错误），良好设计是快速软件开发的根本。

我的理解：这四点重构的原因，均可归结到重构可维持良好设计这一点上，重构是方法准则，良好设计是重构的结果，这四点是良好设计需具备的条件。

• 何时重构

重构本来就不是一件特别拨出时间做的事情，重构应该随时随地进行。

三次法则：

添加功能时一并重构；
修补错误时一并重构；
复审代码时一并重构；
为什么重构有用？
程序有两面价值：‘今天可以为你做什么’和‘明天可以为你做什么’。
对于今天的工作，我了解的很充分；对于明天的工作，我了解的不够充分。但如果我纯粹只是为今天的工作，明天我将完全无法工作。

程序为什么如此难与的四个原因：

难以阅读的程序，难以修改；
逻辑重复的程序，难以修改；
添加新行为时需要修改既有代码者，难以修改；
带复杂条件逻辑的程序，难以修改；
因此，我们希望程序：

容易阅读；
所有逻辑都只在唯一地点制定；
新的改动不会危及现有行为；
尽可能简单表达条件逻辑。
重构是这样一个过程：它在一个目前运行的程序上进行，企图在不改变程序行为的情况下赋予上述美好性质，是我们能够继续保持告诉开发。

• 怎么对经理说？

经理的角度：经常嘴巴上说自己是‘质量驱动’，其实更多的是‘进度驱动’。对于这种情况，作者则给了一个较有争议的建议：不要告诉经理。

我的理解：如果满足2.3的三次法则，重构行为随时随地进行，重构习惯融入到程序开发、修改、复审环节中，似乎重构与否的问题没有理由让经理来面对，但是那只是理想状态，我们有时不得不单独拿出时间来进行重构工作，所以这时候就做你认为该做的。

• 重构的难题

数据库程序难以重构的两个方面：

程序与它们背后的数据表格结构紧密耦合，难以修改；
数据迁移。
解决方法程序与数据表耦合的方案：在对象模型和数据库模型之间插入一个分隔层，这就可以隔离两个模型各自的变化，升级某一个模型时无需同时升级另一模型，只需升级上述的分隔层。这样分隔层会增加系统复杂度，但可以给你很大的灵活度。无需一开始就插入分隔层，可以在发现对象模型变得不稳定时再产生它。

解决数据迁移的方案：

对象数据库提供不同版本的对象之间的自动迁移功能；
无自动功能，在数据尚未被转移钱先运用访问函数造成数据已转移的假象，一旦确定知道数据应该在何处时，就可以一次性地将数据迁移过去，这时唯一需要修改的只有访问函数。
重构了修改了已发布接口的解决方案：

让就接口调用新接口，当你要修改某个函数名称时，请留下就函数，让他调用新函数。千万不要拷贝函数实现码，那会让你陷入重复代码的泥沼中难以自拔；
除非真有必要，不要发布接口，团队内改变代码拥有权观念，让每个人都可以修改别人的代码。
总结：不要过早发布接口。请修改你的代码拥有全政策，使重构更顺畅。

• 何时不该重构？

既有代码是在太混乱，重构它还不如重新写一个来得简单；
现有代码根本不能正常运作；
如果项目已近最后期限，你也应该避免重构。
文中经典比喻：把重构工作比做成债务，把过于复杂的代码造成的‘维护和扩展的额外开销’比作成要付的利息，你可以承受一定程度的利息，但如果利息太高你就会被压垮，你应该随时通过重构来偿还一部分债务。

• 重构与设计

重构可以成为预先设计的替代品，极限编程的支持者提倡这种方法，但只运用重构也能收到效果，但不是最有效途径，xp爱好者也会进行预先设计，使用crc卡类似的东西检验想法，然后得到一个可被接受的方案，然后开始编码，然后才能重构。

重构改变了预先设计的角色，不必保证预先设计的准确无误，只需要得到一个足够合理的解决方案就够了。

• 重构与性能

编写快速软件的秘密就是首先写出可调软件，然后调整它以获得足够速度。

编写快速软件的三种方法：

时间预算法——这通常只用于性能要求极高的实时系统。如果使用这种方法，分解你的设计时就要做好预算，给每个组件预先分配一定资源，包括时间和执行轨迹。每个组件绝对不能超出自己的预算，就算拥有可在不同组件之间调度预配时间的机制也不行；
持续关切法——这种方法要求程序员在任何时间做任何事时，都要设法保持系统的高性能；
90%统计数据——以一种良好的分解方式来建造自己的程序,不对性能投以任何关切，直至进入性能优化阶段，进入该阶段再按照某个特定程序来调整程序性能。
性能优化阶段的优化过程：首先应该以一个量测工具监控程序的运行，由它得知程序大量消耗时间和空间的位置，这样可以找出性能热点（hot spot）所在的一小段代码，对该性能热点，使用持续关切法中的优化手段。应该小幅度进行修改，每走一步都需要编译、测试、再次量测。如果没有调高性能，你应该继续这个“发现热点、去除热点”的过程。

一个被良好分解的程序可从两方面帮助此种优化形式：

它让你有比较充裕的时间进行性能调整；
它让你在进行性能分析时便有较细的粒度。

转自：http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html