重构原则

• 何谓重构

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

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

两顶帽子：‘添加新功能’和‘重构’，在软件开发过程当中，你可能会发现本身常常变换帽子，但不管什么时候你都应该清楚本身戴的是哪一顶帽子。

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

• 为什么重构？

重构改进软件设计；

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

重构使软件更易被理解；

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

重构助你找到臭虫；

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

重构助你提升编程速度；

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

个人理解：这四点重构的缘由，都可归结到重构可维持良好设计这一点上，重构是方法准则，良好设计是重构的结果，这四点是良好设计需具有的条件。

• 什么时候重构

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

三次法则：

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

程序为何如此难与的四个缘由：

难以阅读的程序，难以修改；
逻辑重复的程序，难以修改；
添加新行为时须要修改既有代码者，难以修改；
带复杂条件逻辑的程序，难以修改；
所以，咱们但愿程序：

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

• 怎么对经理说？

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

个人理解：若是知足2.3的三次法则，重构行为随时随地进行，重构习惯融入到程序开发、修改、复审环节中，彷佛重构与否的问题没有理由让经理来面对，可是那只是理想状态，咱们有时不得不单独拿出时间来进行重构工做，因此这时候就作你认为该作的。

• 重构的难题

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

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

解决数据迁移的方案：

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

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

• 什么时候不应重构？

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

• 重构与设计

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

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

• 重构与性能

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

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

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

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

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

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