标签：
在不改变软件的外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更。——《重构 改善既有代码的设计》
说白了重构就是一系列的“等量变换”！
当我们遇到公司前人留下的烂代码时（很多时候我们也是留下“烂代码”的人），一般都是先开骂，其次就捉摸着干脆重做算了，一般都不愿意修改和重构，我们通常给出的理由是“代码太烂了，还不如重做”，这也就骗骗产品狗和老大罢了，真实的原因只有一个：里边埋坑太多，业务复杂，文档缺失，改坏了要承担后果。
所以重构有风险，重构需谨慎！
原则上如果你的老大不支持重构的话，你最好不要私自去做这件事，因为弄不好你改坏了就麻烦了，现在国内的互联网公司整天把事故什么的计入KPI，直接关系你的职业前程。
重构风险那么大，是不是说我们就不能做这件事了？如果我只是改了一个变量名，那应该不会有太大问题，还是有点不放心，那就干脆测试一下，事实证明本次重构百分百不会出什么幺蛾子。这就给了我们启示：“小步快跑” + “及时测试”，因为这样修改的代码量少，所用时间也少，每次只关注一个方面，从而极大地降低了重构的风险。如果你能遵从这个原则，重构就是So Easy的事情！
初步重构，我们可以：添加注释、调整顺序、重命名变量、进行分段，再进一步我们可以：抽取方法、抽取类、抽取接口等等，运用一些典型的设计模式，修改一些不合理的数据结构，优化算法，运用一些语言新特性改写老的代码，进行并行和异步编程等等 ，方法不一而论，但并不是说都用上了就牛逼，能够在以后的实际工作中学着实践应用其中一些典型的方法就已经难能可贵了。
互联网行业业务发展迅速，需求过多，程序员为了赶工期往往“不择手段”实现功能，乱七八槽但是却实现了功能，心想以后有时间了再去重构，真实的调调是往往不了了之。再加上很多时候我们对代码又缺乏有效的CodeReview，烂代码就会越来越多，越到后面维护这些代码越苦逼。与其以后高风险地重构，不如从一开始就注重代码的质量，所以请一开始就以重构的思想写代码，做好CodeReview，从公司的层面来讲如果能从长远利益和维护成本角度来思考问题的话，就会明白代码质量的重要性，高质量的代码避免了大量的重构，降低了软件的风险和公司的成本，无形中增加了公司的收益！
标签：
原文地址：http://www.cnblogs.com/WeiGe/p/5612757.html
