摘要： 作为优秀开发人员，重构应当成为一种习惯，自然而然地运用重构的开发模式，自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式，就是“小步快跑”的开发模式，运用“两顶帽子”的设计顺序，去开发我们的程序。但作为重构初学者来说，这并不容易，即使你已经从业很多年。 阅读全文

摘要： 下面我们来盘点一下系统重构工具箱里都有什么，也就是看一看系统重构到底都有哪些方法。系统重构总是在不同层次上调整我们的代码，因此重构方法也就分为了多个层次。从总体上看，重构方法分为以下几个层次：方法的重构、对象的重构、对象间的重构、继承体系间的重构、组织数据的重构与体系架构的重构。 阅读全文

摘要： 系统重构要求我们对代码的每一步修改，都不能改变软件的外部行为，因此在系统重构中的所有方法，都是一种代码的等量变换。重构的过程，就好像在做数学题，一步一步地进行算式的等量变换。经过一系列等量变换，最终的结果虽然在形式上与原式不一样，但通过计算可以得到与原式完全相同的结果。 这种等量变换对于重构来说非常重要，它使得我们进行重构以后，程序还是那些程序，代码还是那些代码。但是，等量变换不等于原地踏步。正如矩阵通过等量变换可以得到方程组的解，微积分可以通过等量变换计算最终的结果，重构通过等量变换，在保证代码正确的同时，可以使程序结构得到优化。 阅读全文

摘要： 经过前面的一番讲解，相信你已经对系统重构有了一些初步的认识了。一切的一切仿佛在告诉我们，系统重构总是与需求变更无关。但此时，我不得不告诉你这是真实的谎言。 我们的软件系统总是处于一种变化之中，并且往往是一种由浅入深、由易到难的过程。但是，当系统复杂程度发生变化时，我们应当及时调整我们的设计，来适应新的变化。然而我们没有做到这一点，所以我们的系统维护变得越来越困难。要解决我们的问题必须通过系统重构去优化我们的程序，使之重新适应业务需求。毫无疑问，需求变更才是我们去重构的主要动因。 然而...... 阅读全文

摘要： 软件，自从被我们开发出来并交付使用以后，如果它运行得好好的，我们是不会去修改它的。我们要修改软件，万变不离其宗，无非就是四种动机： 增加新功能； 原有功能有BUG； 改善原有程序的结构； 优化原有系统的性能[1]。 第一种和第二种动机，都是源于客户的功能需求，而第四种是源于客户的非功能需求。 阅读全文

摘要： 以往我们在重新设计一个系统时，总是喜欢大布局。全面地整理系统需求，全面地分析系统功能，再全面地设计系统、开发、测试。这样一个过程往往会持续数月，花费大量的工作量。但是，不到最后设计出来，谁都不知道会不会存在问题。这就是“大布局”的弊病。 正因为如此，软件大师在讲述系统重构时总是强调，系统重构应当避免大设计，而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。 阅读全文

摘要： 当我们开始系统重构的时候，不是着手去修改代码，而是首先建立测试机制。不论什么程序，只要是被我们修改了，理论上就可能引入BUG，因此我们就必须要进行测试。与以往的代码修改不同，重构没有引入任何新的需求，系统原来什么功能，重构以后还是这些功能。因此，重构的测试标准就只有一个，就是与之前的功能完全保持一致，仅此而已。 阅读全文

摘要： 前面我们提到了，面对软件工业时代的到来，我们的软件企业陷入了一种更深的迷茫之中，一种“后有追兵，前有悬崖，进退两难”的境地。后有追兵：面对维护了数十年之久的大型遗留系统，我们到底改还是不改？不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后；面对越来越多的竞争者，使我们面临着被市场淘汰的风险。前有悬崖：原本运行得好好的软件系统，凑合一下还可以运行几年。一不小心改出问题了，企业立马就歇菜儿了，面对大量的用户投诉，企业四处救火，竞争对手趁火打劫，这是任何软件企业都不能承受的巨大风险。难倒真的“熊掌和鱼不能兼得”吗？真的没有一种方法，能够既保证我们系统可以技术改造，又能有效地避免改造过程的风险吗？有，那就是系统重构。 阅读全文

摘要： 我常常感到幸运，我们现在所处的是一个令人振奋的时代，我们进入了软件工业时代。在这个时代里，我们进行软件开发已经不再是一个一个的小作坊，我们在进行着集团化的大规模开发。我们开发的软件不再是为某个车间、某个工序设计的辅助工具，它从某个单位走向整个集团，走向整个行业，甚至整个社会，发挥着越来越重要的作用。一套软件所起到的作用与影响有多大，已经远远超越了所有人的想象，成为一个地区、一个社会，乃至整个国家不可或缺的组成部分。慢慢地，人们已经难以想象没有某某软件或系统的生活和工作会是怎样的。这就是软件工业时代的重要时代特征。 阅读全文

摘要： 《大话重构》这本书是我写的第一本书，从今天起我将通过连载的形式逐渐跟大家分享。 阅读全文