关于系统重构
其实对于系统重构，首先应该分清重写和重构的区别。
重构：在现有基础上进行扩展整合和代码及业务流程梳理。
重写：顾明思议，重新进行一个全新系统的开发。
##为什么要进行系统重构
- 过于复杂的代码结构满足不了新的需求。
- 生产力开始受到明显的影响。
- 系统维护性降低。
##什么时候开始重构
引用老外的话说，当你的代码出现badsmell时就应该启动重构。
重复的代码。
如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将他们合二为一。
过长的函数。
越短的函数会存活的时间更长，存活的更好。
过长的类。
如果想利用单一的类做很多的事情，那么该类的内部会出现很多的instance变量，重复代码就要接踵而至了。
过长的参数列。
太长的参数列难以理解，太多的参数会造成前后不一致，不易使用，一旦你需要更多的数据，就不得不修改它。
发散式变化。
一旦我修改软件，我希望只在一处修改就好，如果不能做到这点，该坏味道就出现了。
烟雾弹式修改。
一旦软件进行修改，你必须去对多个类的内部做小修改，该坏味道出现了。
依恋情结。
函数对某个类的兴趣高过对自己所处之host类的兴趣，坏味道出现了。
重构的含义：
重构（名词）：对软件内部结构的一种调整，目的是在不改变“软件之可观察行为”的前提下，提高其可理解性，降低其修改成本。重构之前，首先检查自己是否有一套可靠的测试机制。
——Martin Fowler，《重构》
重构并不是万金油
重构并不能解决所有的问题，到了一定的阶段，不可避免的要进行系统重写。
关于系统重写
系统重写，也就是将软件的实现重写一遍。
为什么是重写而不是重构与什么时候开始重写
- 将原先一个无安全需求的系统改造为安全性良好的系统。大多数情况下重构解决不了问题。
- 现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。
- 新需求的开发成本会超过开发一个新的软件的成本，这时候旧软件该寿终正寝了。
- 系统存在很多奇点，一个不可用导致整个系统不可用。
- 整个架构存在问题。
吐槽
中国当前的真个IT大环境和社会一样浮躁，架构师在推动重构和重写时基本无法推动，因为绝大部分公司老板不了解重构与重写带来的变化，只要听到要延长进度，基本不会允许，所以这在绝大多数情况下是软件本身质量和软件产生经济价值的权衡，“既然能用，为什么要花费更多的时间来重构甚至重写呢？！”其实每个程序猿，每个架构师都希望做出完美的系统，然而现实是骨感的，所以很多架构师和程序猿总是从一个坑跳到另一个坑。当然如果你现处于一个开发的架构不错，拥有开发规范，从上而下推动codereview的一个公司，恭喜你，你所在的公司其实非常不错了。