第44页 Chapter 2 Principles in Refactoring

本章讲了重构的概念，原因以及重构的关键原则等

本文重构概念的两个关键点：
1.
to make the software easier to understand and modify.
  A good contrast is performance optimization.重构可能使软件速度变慢，但是如果软件是良好重构过的，最后优化性能阶段能够带来良好结果，反而使软件性能良好
2.
refactoring does not change the observable behavior of the software
Why Should You Refactor?
Refactoring Improves the Design of Software
Refactoring Makes Software Easier to Understand
Refactoring Helps You Find Bugs
Refactoring Helps You Program Faster
即使在开发过程中，当你发现重复或相似的代码时，也应该立刻重构；当变化发生时，如果该变化影响不止一处，重构就应该粉墨登场。经常的重构可以保证代码常拭常新，如利刃一般锋利。“不要容忍破窗户”

如果两个或更多的地方实现同一职责，则改变时会带来麻烦。所以要遵循DRY原则，单一职责。
When Should You Refactor?
The Rule of Three(Three strikes and you refactor)
Refactor When You Add Function
Refactor When You Need to Fix a Bug
Refactor As You Do a Code Review

The most common time to refactor is when I want to add a new feature to some software.
Reasons:1.refactoring helps me understand some code I need to modify.2.another driver of refactoring is a design that does not help me add a feature easily.

What is it that makes programs hard to work with?Four things I can think of as I am typing this are as follows:
1.Programs that are hard to read
2.Programs that have duplicated logic 
3.Programs that require additional behavior that requires you to change running code
4.Programs with complex conditional logic 

重构的问题：
1.数据库重构困难
2.当接口发布了之后重构会带来麻烦，所以可以采用类似java里的deprecated,标记其为废弃的，以及在旧的方法中引用新的方法新的接口
3.某些决策非常关键，无法在将来通过重构而改进。比如在数据非常不完整的情况下，比如将系统从没有任何安全需求的情况重构为有良好安全保障的系统
4.在只有从头写能解决问题的软件以及马上到发布日期的软件情况下不要重构。

重构可以一定程度上解决设计过度的问题。设计的时候要注重简洁性与灵活性的平衡。如果可以预见明确的变化，则应该考虑灵活性，否则尽可能保证程序简单。随着系统开发的深入，对系统的了解也逐渐加深，此时如果简洁无法保证灵活，则进行重构。

重构与性能优化
良好重构的系统可以使性能优化在合适的时间地点进行（项目的最后时期为优化期）。如果一直保持性能优化容易使精力浪费在不关键而且不需要用的90%代码上。

优秀的程序员也无法保证第一次写的代码就是非常好的，所以要经常重构。