第一次读《重构:改善既有代码的设计》时，我曾整理过一个简单的笔记。最近，因为参与一个重构项目，再一次温习了《重构:改善既有代码的设计》。过程中，萌发了认真总结、整理重构方法的冲动，于是有了这系列文字。 代码的坏味道还有几篇没有完稿，后面我会陆续补充。。。 “有病要早治，不要放弃…

代码重构是一个产品不断的功能迭代过程中，不可避免的一项工作。所谓重构，是在不改变程序的输入输出即保证现有功能的情况下，对内部实现进行优化和调整。 每个开发人员从业生涯中，或多或少的做过重构工作。小到重写一个功能函数、业务组件，大到重构一个复杂功能模块或整站重构。 重构是需要花费…

在日常项目开发中，被众人说烂了的重构到底是什么？在我见过的很多开发者的眼中，对重构的理解，就是推翻以前的软件，重新花时间设计架构一个和界面一模一样的东西！有这种想法我认为是很危险的，在效率为王的当今社会，这样的人力资源浪费是不被社会和商业所接受的，索性我们这次认真探讨一下到底什…

项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目最终无法维护。然而破解之法在于项目迭代中持续不断的重构。

经常听到周边的人抱怨没有时间重构，重构并不是单独抽出时间集中处理的，而是当你想要做某个功能时，随手把需要重构的地方安排了。 重复代码是最核心常见的预警信息，如果有两个及以上的重复逻辑，就应该考虑将其合并。比如同一类或不同类中的函数存在相同逻辑的部分，就应该把相同部分抽象为独立函…

代码重构原则：1 易读性优先 2 如果代码没有造成性能瓶颈，那么就不要为了性能而修改代码 3 复杂性守恒原则

之前也介绍过我们团队的前端项目从零开始经历8个月迭代业务代码10万行(仅为产品长期规划需求的20%)，至今仍然在不断迭代的过程。 PS: 不管对于何种语言，重构都是软件开发过程中不可或缺的一部分。如果已经了解重构的基础，可以直接跳往至文章后面的重构案例部分。 随着业务需求的不断…

从0->1一次性完成重构的理想场景只存在于理想中。如果真实存在，只能说明项目过小或者已经趋于稳定迭代很少，这种情况要考虑是否真的有重构的必要！！！ 重构不是软件开发的必要流程，而是现有代码的组织缺陷或不合理的补救方式。 必须通知业务方并说服业务方同意，让业务方做好准备上线后检查…

面试高频考点，“三次握手，四次挥手”讲解，不仅有精美的图解，还有生动形象的例子，保证看了之后你就忘不了。