第2章 重构原则.ppt

第2章 重构原则 2.1 概念 调整软件内部结构，在不改变软件行为前提下，提高其可理解性，降低修改成本。 2.2 重构目的 改进软件设计 2. 使软件更易被理解 3.有助找到缺陷（bug） 4.提高编程速度 2.3 何时重构 1. 添加功能时 修补错误时 复审代码时 2.4 重构的难题 1. 数据库 2. 修改接口 2.5 重构与设计 两个观点： 把设计看作软件开发的关键环节，而把编程看作只是机械式的低级劳动。 重构可以成为“预先设计”的替代品，根本不必做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型 2.6 重构与性能 时间预算法 通常只用于性能要求极高的实时系统。分解设计时要做好预算，给每个组件预先分配一定资源，包括时间和执行轨跡。每个组件绝对不能超出自己的预算，就算拥有可在不同组件之间调度预配时间的机制也不行。 这种方法高度重视性能，对于心律调节器一类的系统是必须的，因为在这样的系统中迟来的数据就是错误的数据。但对其他类系统（例如经常开发的企业信息系统）而言，不必如此追求高性能。 持续关切法 要求任何程序员在任何时间做任何事时，都要设法保持系统的高性能。 这种方式很常见，感觉上很有吸引力，但通常不会起太大作用。任何修改如果是为了提高性能，通常会使程序难以维护，因而减缓开发速度。如果最终得到的软件的确更快了，那么这点损失尚有所值，可惜通常事与愿违，因为性能改善一旦被分散到程序各角落，每次改善都只不过是从对程序行为的一个狭隘视角出发。 利用统计数据 据统计，代码中只有10%需要优化。在性能优化阶段中，首先运行一个量测工具监控程序，找出程序中哪些地方大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后集中关切这些点，并使用前述持续关切法中的优化手段来优化它们。由于把注意力都集中在少量点上，较少的工作量便可显现较好的成果。 * 重构使软件更容易被理解和修改。可以在软件内部做很多修改，但必须对软件可观察到的外部行为造成很小变化，或不造成变化。 和重构形成对比的是“性能优化”。性能优化通常不会改变组件的行为（除了执行速度），只会改变其内部结构。 两者出发点不同，性能优化往往使代码较难理解，但为了得到所需性能不得不那么做。 如果没有重构，程序的设计会变差。 当人们只为短期目的或者在完全理解整体设计之前，贸然修改代码，程序将逐渐失去自己的结构，程序员越来越难以通过阅读源码而理解原本设计。代码结构的流失是累积性的。越难看出代码所代表的设计意涵，就越难保护其中设计，于是该设计就腐败得愈快。 重构很像是在整理代码 ，所做的就是让所有东西回到应该的位置上。经常性的重构可以帮助代码维持自己该有的形态 。 同样完成一件事，设计不良的程序往往需要更多代码，这常常是因为代码在不同的地方使用完全相同的语句做同样的事。因此改进设计的一个重要方向就是消除重复代码。 这个动作的重要性着眼于未来。代码数量减少并不会使系统运行更快，然而会使未来可能的程序修改变得容易得多。代码愈多，就愈难正确修改，因为有更多代码需要理解。如果消除重复代码，就可以确定代码将所有事物和行为都只表述一次，这是优秀设计的根本。 一、使别人容易理解。 谓程序设计，便是与计算机交谈。编写代码告诉计算机做什么事，它的回应则是精确按照你的指示行动。除了计算机外，源码还有其他读者：数个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。 二、利用重构来协助理解不熟悉的代码。 看到不熟悉的代码，需试着理解它的用途。有了重构这个概念，就不会满足头脑中得到的一点体会。而是真正动手修改代码，让它更好地反映出我的理解，然后重新执行，看它是否仍然正常运作，以此检验我的理解是否正确。随著代码渐趋简洁，发现自己可以看到一些以前看不到的设计层面的东西，达到更高的理解层次。 如果对代码进行重构，就可以深入理解代码的作为，恰到好处地把新的理解反馈回去。搞清楚程序结构的同时，也清楚了自己所做的一些假设，从这个角度来说，从而非常容易的找出缺陷。 良好设计是快速软件开发的根本。拥有良好设计才可能达成快速的开发。如果没有良好设计，或许某一段时间内程序进展迅速，但恶劣的设计很快就让速度慢下来。程序员会把时间花在调试上面，无法添加新功能。修改时间愈来愈长，因为必须花愈来愈多的时间去