重构--改善既有代码的设计学习总结一

最近在维护旧系统的时候，发现旧系统的可读性和高重复性的众多问题。但是针对原有的系统在不维护的时候是满足用户的使用，也就可以说旧系统适合在维护前的那个阶段。任何系统都有那么一个阶段。没有什么系统开发完后就不需要去维护。因此就不多说可读性的问题了，这里主要根据重构进行总结。

  我相信很多IT界的朋友应该都或多或少有听说《重构》这本书。这里我也是根据读了这本书结合一些想法进行总结。

何谓重构？

引用

  1. 对软件内部结构的一种调整，目的是在不改变(软件之可察行为)前提下，提高其可理解性，降低其修改成本。
  2. 使用一系列重构准则，在不改变(软件之可察行为)前提下，调整其结构。

以上是重构书上根据重构为“名词”和“动词”来进行定义。
根据上面的定义，我给出个人的理解：
既然是不改变其行为，提高其可读性和理解性，那么这个是否和基础数学上的“化简”类似呢？比如"50/100"="1/2" 其50是共同因数或者也就解释为提取公因数。例外根据多项式的中提取公因式更类似。

观点： 将程序代码重复出现的提出出来，也就是瘦身。让代码块瘦，瘦到上面程度呢？瘦到最简，也就是功能单一，专注力加强。同时也便于测试。


什么时候进行重构？
根据”事不过三的原则“，进行确定是否要进行重构。

观点： 重构这个绝对不是从0开始，因为重构至少大于2次。因此希望编写代码的时候要带有重构的思维(重构的思维可以从0开始，就相当于你在脑海里知道要将结果化简为最简一样)，当你感觉又写了类似的代码的时候，这说明你可以要进行重构了，当你发现写这段代码有烦的感觉的时候，那么请你想想重构吧！

分析哪些症状代码有需要重构

引用

1. 重复代码
2. 方法过大
3. 类过大
4. 参数过多
5. Divergent Change
6. Shotgun Surgery
7. Feature Envy
8. Data Clumps
9. Primitive Obsession
10. Switch Statements
11. Parallel Inheritance Hibernarchies
12. Lazy Class
13. Speculative Generality
14. Temporary Field
15. Message Chains
16. Middle Man
17. Inappropriate Intimacy
18. Alternative Classes With Different Interfaces
19. Incomplete Library Class
20. Data Class
21. Refused Bequest
22. Comments

以上22条是重构书中的代码的坏味道中的观点。本人现阶段只对：1，2，3，4，11，12，10，20，22尝试过。不过1，2，3，4是最为基本的。这里就得一些理论性进行总结，下次将结合实例来进行总结。