《重构》读书笔记（十二）——第十二章 大型重构

       这场游戏的特点 

       在大型重构中，情况有很多变化，我们无法告诉你准确的重构步骤。如果没有看到实际情况，任谁都无法准确知道该怎么做（所以，不要妄想得到放之四海皆准的重构方法）。（而在实际项目中，经常遇到的就是大型重构。因为在项目初期，都会有很紧的进度压力，而此时由于刚开始编码，代码的腐坏程度也可能还没有到达你无法容忍的程度。而到了项目中期，代码的可扩展性和可维护性已经严重影响了你的生产力。）

        当你为某个函数添加参数时，做法可以很仔细而清楚，因为重构范围很清楚；但是当你分解一个继承体系时，由于每个继承体系都是不同的，所以我们无法告诉你准确的重构步骤。

        另外，对于这些大型重构，还有一件事需要注意：它们会耗费相当长的时间。第6~11章所介绍的重构手法，都可以在几分钟（至多一个小时）内完成。但是对于一些大型重构，可能需要花上数月甚至几年的时间。现实状况是，我们不可能停止下来花几个月或几年来重构一个系统。我们只能一点一点的工作，今天一点点，明天一点点。

       在这个过程中，你应该根据需要安排自己的工作，只在需要添加新功能或修补错误时才进行重构。你不必一开始就完成整个系统的重构，重构程度只要能满足其他任务的需要就行了。反正明天还可以回来重构。

       由于大型重构可能需要花费相当长的时间，因此它们并不像其他章节介绍的重构那样，能够立刻让人满意。你必须要有那么一点点信仰：你每天都在使你自己的程序世界更安全。

      进行大规模重构时，有必要为整个开发团队建立共识，这是小型重构所不需要的。大型重构为许许多多的修改指定了方向。整个团队都必须意识到：有一个大型重构正在进行，每个人都应该相应的安排自己的行动。

    大型重构的重要性

     如果我们只是重复的进行第6~11章所述的重构，那么我们会发现：我们投入了大把时间学习重构，在实际工作中却无法获得实在的利益。这对我们来说是非常槽糕的，我们不能容忍这种事情发生。

    更重要的是，你之所以需要重构，绝不会因为是重构好玩，而是因为你希望它能对你的程序有所帮助，让你能做一些重构之前无法做的事情。

     很多时候，我们处于这样的困境：由于之前对需求的理解不够充分，所作出的设计决策很不完善，甚至到了后期，这样的设计决策迅速蔓延，以至于程序的结构相当混乱，仅仅通过小型重构手法不可能得到灵活可扩展的结构。如果程序错误遍地，不能正确的工作，你应该果断的重写，相信你有之前的失败经验，你的重写工作会更快，结果更好。 但如果程序还能正确执行，实际情况也不允许你重写，这时，你需要对程序进行大规模重构。

     四个大型重构

一、梳理并分解继承体系（Tease Apart Inheritance）

二、将过程式设计转化为对象式设计（Convert Procedural Design to Objects）

三、将领域和表述分离（Separate Domain From Presentation）

四、提炼继承体系（Extract Inheritance）