《重构：改善既有代码的设计》读书笔记一

一、重构原则

1、重构定义

重构：对软件内部结构的一种调整。目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

2、为何重构

在开始说为何重构之前，先说一下很多程序员为何不喜欢重构。

时间紧，一直忙着实现功能，觉得重构影响效率，而且重构不算绩效，简直吃力不讨好
觉得代码写完之后可能以后都不是自己维护了，只顾当时快速实现功能
重构有风险，它必须修改运作中的程序，这可能引入一些不易察觉的错误
对重构没有系统性、全局性的认识，面对一堆烂代码，没有重构技巧的指导，只能想到哪改到哪
接手别人写的代码时，代码已经腐化到无可救药了，重构成本极高

是的，对当时做完功能的程序员来说不重构确实相对痛快，但是有没有想过将来接手这块代码的人的感受？自己遇到烂代码时都经常吐槽之前的开发者，但自己有养成持续重构的习惯吗？难道你也想在将来被别人吐槽？是现在花几分钟重构的成本高，还是将来找一个bug花半天的时间成本高？当以后新来一个需求时，是不重构的改动成本高？还是重构之后的改动成本高？所以希望大家多平常了解一下重构相关知识，做一个有素养的工程师，这样大家都好。下面罗列了几个重构的原因：

重构改进软件设计
重构使软件更容易理解
重构帮助找到bug
重构提高编程速度

项目在演进，代码不停地在堆砌。如果没有人为代码的质量负责任，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。

每个软件模块都有三项职责。第一项职责是它运行时所完成的功能。第二项职责是它要应对变化，一个难以改变的模块是有问题的，即便能够工作，也需要对它进行修改。第三项职责是要和读者进行沟通。 ——《敏捷开发·纪念版》

3、何时重构

添加功能时重构
事不过三，三则重构（三次法则）
修补错误时重构
复审代码时重构

以上四点被称为重构时机的“增删改查”，目的是想及时通过最小的努力就能对我们的系统进行扩展和修改。注意，重构是持续的，不要总想着“憋大招”，等代码烂到一定程度再重构，有时候项目代码太多了，重构很难做得彻底，最后又搞出来一个“四不像的怪物”，这就更麻烦了！所以，寄希望于在代码烂到一定程度之后，集中重构解决所有问题是不现实的，我们必须探索一条可持续、可演进的方式。