重构一

在这里记下阅读《重构：改善既有代码的设计》一书的心得。

重构的第一步

让环境不断发生变化，以此来考验代码框架的承受力。

我们假设原来的代码框架是基于一个理想的环境而做的设计。

现在这个环境开始变的恶劣起来，突然来了飓风。那么这个框架是否能保证不被刮走呢？而做到这一点，又需要做出多大的改动？

环境继续变的糟糕，洪水开始肆虐。可能框架已经岌岌可危，跟原来的框架比起来已经发生了太多的变化。

当最后一根稻草压过来的时候，失败也紧随而至。

 重构是什么

【引用原文】对软件内部结构的一种调整，在不改变其需求及功能结构的情况下，提高其可理解性，降低其修改成本。

 重构的方向

消除重复代码

【引用原文】如果消除代码，可以确定代码将所有事物和行为都只表述一次，这正是优秀设计的根本。

让代码更具可读性

如果

 何时重构

添加功能时

【引用原文】如果我用某种方式去设计，那么添加特性会简单的多。

修补BUG时

【引用原文】看来是代码不够清晰，使你不能一眼就能发现错误。

代码审查时

【引用原文】直接展示代码并不是一个好的主意，使用UML展现设计，CRC卡展示软件情节。

为什么重构有用

【引用原文】程序有两面价值，【今天它可以为你做什么】和【明天它可以为你做什么】。

如果你无法认识到当下的价值只是整个故事的一部分，那么你无法长期从事编程工作。

但是你了解你今天的工作，却不一定知道明天需要什么。

程序为什么如此难以相与？

1、难以阅读的程序。

2、逻辑重复的程序。

3、添加新行为时需要修改既有代码者。

4、带复杂条件逻辑的程序。

因此，我们希望程序：

1、容易阅读。

2、所有逻辑只在唯一地点指定。

3、新的改动不会危及现有行为。

4、尽可能表达条件逻辑。

  重构就是在目前一个可运行的程序上进行，企图在不改变程序行为的情况下赋予上诉美好性质。

使我们能保持高速开发，增加程序的价值。

 重构与设计

没有重构

【引用原文】过去未曾运用重构时，总是力求得到灵活的解决方案。任何一个需求都让我提心吊胆的猜疑：

这个需求会导致怎样的变化？没有重构，就必须保证预先设计准确无误，这个压力太大。

有了重构后

你就可以用一条不同的途径去应付未来的变化。先设计出一个足够合理的解决方案，再考虑使用重构得到灵活的解决方案。

重构降低了设计的难度，减轻了设计的压力。