重构原则

何谓重构

 

1. 重构(名词)

对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本

2. 重构(动词)

使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

 

为何重构

 

1. 改进软件设计

越难看出代码所代表的设计意图，就越难保护其中设计，于是该设计就腐败的越快。

经常性的重构可以帮助代码维持自己该有的形态。

重复代码越多，可能的修改就越困难，所有事物和行为在代码中只表述一次，这是优秀设计的根本。

2. 重构使软件更容易理解

一开始我所做的重构都像这样停留在细枝末节上。随着代码渐趋简洁，我发现自己可以看到一些以前看不到的设计层面的东西。

3. 重构帮助找到bug

对代码的理解，可以帮助我找到bug。

4. 重构提高编程速度

如果没有良好设计，或许某一段时间内你的进展迅速，但恶劣的设计很快就让你的速度慢下来。

你会把时间花在调试上面，无法添加新功能。修改时间越来越长，因为你必须花越来越多的时间去理解系统、寻找重复代码。

良好设计是维持软件开发速度的根本。重构可以帮助你更快速地开发软件，因为它阻止系统腐败变质，它甚至还可以提高设计质量。

 

何时重构

 

1.三次法则——第三次做重复的事

2.添加功能时——新特性的添加困难时。重构使得，在更好的理解代码的同时，改变结构，使得，新特性的添加更快速、更流畅。这也是良好设计的要求。

3. 修补错误时——对代码的理解，可以帮助我找到bug。

4. 复审代码时——复审本身就可以改善开发状况，这和重构有部分相同的目的

 

是什么让程序如此难以修改?

眼下我能想起下述四个原因，它们是：

难以阅读的程序，难以修改；

逻辑重复的程序，难以修改；

添加新行为时需要修改已有代码的程序，难以修改；

带复杂条件逻辑的程序，难以修改。

因此，我们希望程序：

(1)容易阅读；

(2)所有逻辑都只在唯一地点指定；

(3)新的改动不会危及现有行为；

(4)尽可能简单表达条件逻辑。

 

重构的难题

 

1. 数据库

绝大多数商用程序都与它们背后的数据库结构紧密耦合在一起

2. 修改接口

过度强调代码所有权的团队常常会犯这种错误。发布接口很有用，但也有代价。这个代价就是修改的代价，太多的代码已经依赖你的接口。

不要过早发布接口。请修改你的代码所有权政策，使重构更顺畅。

3. 难以通过重构手法完成的设计改动

我们很难（但还是有可能）将不考虑安全性需求时构造起来的系统重构为具备良好安全性系统。

4. 何时不该重构

现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。

如果项目已近最后期限，你也应该避免重构。

 

重构与设计

 

如同前面总结的，它和设计彼此互补。

 

重构与性能

 

先重构，优化阶段再进行性能调优

 

重构起源

 

。。。。。。

 

完。