《重构》读书笔记（三）——第二章 重构原则

      第二章 重构原则

      这一章作者回答了“何谓重构？”“为何重构？”“何时重构？”等基本问题，并讲述了重构的难题和起源以及重构与设计，重构与性能的关系。

      何谓重构？

      重构（Refactoring）就是在不改变软件可观察行为的前提下，通过调整程序代码的结构，提高其可理解性，降低其修改成本。关于“重构”的定义，有过这样的讨论：

      重构的基本要求是“不改变软件的外在行为”，那么如何保证你得修改不改变软件的外在行为呢？很多人回答：单元测试。没错！于是很有人认为，在没有单元测试的保证下进行的所有代码调整和修改，都不是重构。

      我不这么认为！保证修改不改变软件的外在行为除了单元测试还有别的方法。例如手工做回归测试。因此，只要我们的目的是“在不改变软件的外在行为前提下对代码做出调整，以求提高其可理解性或使其区域更合理”，并通过了自动化或手动回归测试，那么这样的修改和调整都是重构。

       为何重构？

       重构能够改进软件设计， 使软件（代码）更容易理解，帮助开发者找到Bug，并提高编程速度。

      何时重构？      

     重构应该随时随地进行。你不应该为重构而重构，你之所以重构，是因为你想做别的事情，而重构可以帮助你把那些事做得更好更快。关于何时重构，有一个很重要的“三次法则”，即事不过三，三则重构。如果你未能保持你的代码整洁，那么复审代码时重构通常是你改善代码可读性的最好时机。

      重构的难题

      在实际的项目实践中，会有各种各样的情形影响重构的顺利进行。例如难于做单元测试的UI或图形组件，数据库，需要修改接口，等等。

      关于重构与设计

      现在很多人特别是敏捷开发的追随者，都提倡“怎么来方便就怎么来”，这本来是对“尽量保持简单”原则的不同表述。可是在很多情况下，却成了很多人不做设计的理由。因此，在很多项目中，你会看到，数据结构的定义非常随意，对象间关联耦合得非常紧密，单个类或类族不具有可测试性。变量和函数的命名混乱，并且各处不一致。函数和类冗长，职责过多或混乱。代码严重重复， 到处可见复制粘贴的痕迹，等等。一旦这样，项目代码很容易腐败变质并失控，一到项目中期，团队生产率严重下降，对付这样的代码，难于上青天。

      这是设计不足导致的问题。修改这样的代码，重构难度非常大。对付这样的遗留代码，作者给出了一个很有效的折中办法：将“大块头软件”重构为封装良好的小型组件。然后再对各个小型组件做出“重构或重建”的决定。

     现实中的重构 

     在现实中，很多人打着“重构”的旗号，却正在干着“重写”的勾当。关于这一点，见附件的链接文章《什么是重构，什么不是重构》 。

    全文见链接： http://blog.jobbole.com/19371/