代码重构（英语：Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。
目前创新互联已为1000+的企业提供了网站建设、域名、雅安服务器托管、网站托管维护、企业网站设计、汉中网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：
1、去除已知bug。
2、提高程序运行效率。
3、增加新的功能。
重构举例：（简化代码、提升效率）
重构前：
if(list != null list.size() 0){
for(int i = 0; i list.size(); i++){
//skip...
}
}
重构后
if(list != null){
for(int i = 0, len = list.size(); i len; i++){
//skip...
}
}
何时着手重构（Refactoring）
新官上任三把火，开始一个全新??、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢？"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。
Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是"队伍变形"的强烈信号：
·代码中存在重复的代码
中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。
程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法
过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改
当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。
·类之间需要过多的通讯
A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链
"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。
·各立山头干革命
如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计
在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。
·缺少必要的注释
虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。
在“代码的坏味道”中，代码冗余是其中的一条。而应对代码冗余最基本的方法就是代码重用，并且在面向对象中，重用也是一种基本的思路。
当面向对象设计成为主流时，“重用”曾经被吹捧为面向对象的主要优点之一。为了实现“重用”，教科书总是告诉我们，应该找到已有的东西，用派生类的形式对其进行小幅修改，或加入新的特性，实现代码的“重用”。所以现在一提到面向对象的代码重用，大多数程序员想到的是面向对象的“继承”。真的是这样的吗？我们可以看看下面的一个例子：
现在有一个项目：对动物的不同特征建模。项目的需求如下：
1、 每种动物都有数量不同的腿；
2、 动物对象必须能够记住并获取这一信息；
3、 每种动物的移动方式不同（考虑行走和飞行两种情况）；
4、 对于给定的地形类型，动物对象必须能够返回从一个地方移动到另外一个地方所花费的时间。
处理“腿数”这个变化，很简单，也很典型，就是用一个数据成员存放这个值，并且设置该值的读取和赋值方法（在Java中也称为getter/setter方法）。但在处理动物移动方式上，通常有两种方法：第一种是用一个数据成员说明动物对象拥有哪种移动方式（即开关变量，在本文中暂不讨论开关变量的问题）；第二种是用两种不同类型的Animal类（都派生自Animal基类），因为Animal的大部分特性是相同的，仅移动方式不同而已，为了代码的重用，用继承来处理不同的部分，如下UML图：
到目前为止，该设计没有暴露出任何问题。但现在，需求发生改变了（这在软件开发是无时无刻不在发生的事情），不仅要考虑动物的移动方式，还有考虑动物的食物属性（肉食动物、草食动物、杂食动物）时，问题就会变得非常的复杂，因为有会飞的肉食动物（老鹰）、有会行走的肉食动物（狮子、老虎）、也有会飞的草食动物（麻雀）、会行走的草食动物（牛），甚至还有行走的杂食动物（乌龟），那么在之前的设计上继续使用继承来实现代码的重用，那么会得到如下的设计UML图：
现在我看发现，子类的数量爆炸性的出现（这里还没有考虑杂食动物的情况），如果继续有动物的特性需要被考虑进来，那么，这个继承关系将会更加复杂，子类数量将巨大，给后期维护带来巨大的麻烦。
采用继承来实现代码重用，它能够这次凑效，但是无法次次凑效。诸如此类的反复特化，要么会使代码变得无法理解，要么产生冗余。特化技术最终会产生太深的继承层次。糟糕的是继承层次太深导致程序难以理解（弱内聚）、存在冗余、难以测试而且多个概念耦合在一起。无怪乎许多人认为面向对象有些言过其实——尤其是这一切都是因为遵循了面向对象“重用”要求。
那么我们真的束手无策吗？《设计模式》的大师们的话仿佛又在耳边回荡：“考虑设计中什么应该是可变的”、“对变化的概念进行封装”，并且最重要的是“优先使用对象聚集（组合），而不是类继承”。大师的话仿佛给了我们很好的提示：寻找设计中的变化，并封装在一个类中；将这个类包含在另外一个类中。
我们还是考虑上面的那个例子。什么是变化的：动物的腿数、动物的行动方式、动物的食物属性，这些是变化的。找到了变化，下一步就是进行封装了，动物的腿数我们已经得到了很好的处理。那么来考虑动物的行动方式和动物的食物属性。可以考验下面的设计：
将动物的行动方式和动物的食物属性分别封装在AnimalMovement和AnimalFood这个两个类中，它们的变化体现在各种的子类中，这样，动物的行动方式和动物的食物属性就不会方法任何的关联（其实它们之间本来就没有关联关系），在Aimal类中，持有AnimalMovement和AimalFood的引用，当AnimalMovement和AimalFood发生变化时，也不会影响到Aimal类。
我们现在再反过头来看看动物的腿数的这个属性，其实这个也是一个变化，好像我们对它进行特殊的处理，但是仔细想想，我们也是将其封装在了int中，只是这是一个数据变量。但是真正的面向对象语言中，万事万物皆对象，甚至内置的数据成员也是对象（如果我们将int换成Integer，或许更容易理解一点）。
其实重用并不是使用面向对象方法的原因。降低维护成本和使代码更加灵活，更容易扩展，才是更重要的考虑因素。使用正确的面向对象技术当然可以实现重用，但并不是通过直接使用该对象，然后由它派生新的变体对其重用即可达到的。这样做的结果是产生难以维护的代码。所以：对象的真正威力并不在于继承，而是来自于封装行为。但我们往往错误的使用前者而忽略了后者。
那么被面向对象“鼓吹”的继承就没有作用吗？其实不是，反而相反，继承拥有很大的作用，没有继承就没有多态，没有多态，那么上面的第二个设计方案也无法实现。继承本身并不是什么特别难的技巧，但是要能够把继承运用的好却是很难的。那么继承该用在什么地方呢？让我们在来聆听一下大师的教诲：在OO的学习中，继承占有很重要的地位，但这并不是说可以到处滥用。相反，运用继承的时候，应该尽可能的保守，只有在它能带来很明显好处的时候，才能使用。在判断该使用合成还是继承的时候，有一个最简单的办法，就是问一下自己，是不是会把子类向上转型为基类。如果必须转型，那么继承就是必须的，如果不是，那么就该看看是不是不该使用继承。
“优先使用对象聚集（组合），而不是类继承”，请永远记住这句话，并将其运用到实际项目中。继承和合成都能让你在已有类的基础上创建新类。但通常情况下，合成是把已有的类当作新类底层实现的一部分来复用，而继承则是复用其接口。尽管面向对象的编程会反复强调继承，但是当你着手设计的时候，通常情况下还是应该先考虑合成，只有在必要的时候才使用继承。合成会更灵活。
参考资料：
《Java编程思想》
《设计模式解析》
《重构——改善现有代码的设计》
《设计模式：可复用面向对象软件的基础》
原因可能为：
1、运行的用户数过多，对服务器造成的压力过大，服务器无法响应，则报HTTP500错误。减小用户数或者场景持续时间，问题得到解决。
2、该做关联的地方没有去做关联，则报HTTP500错误。进行手工或者自动关联，问题得到解决。
3、录制时请求的页面、图片等，在回放的时候服务器找不到，则报HTTP500错误，若该页 面无关紧要，则可以在脚本中注释掉，问题将会得到解决。例如：有验证码的情况下，尽 管测试时已经屏蔽了，但是录制的时候提交了请求，但回放的时候不存在响应。
4、参数化时的取值有问题，则报HTTP500错误。可将参数化列表中的数值，拿到实际应用系统中进行测试，可排除问题。
5、更换了应用服务器（中间件的更换，如tomcat、websphere、jboss等），还是利用原先录制的脚本去运行，则很可能报HTTP500错误。因为各种应用服务器处理的机制不一样，所录制的脚本也不一样，解决办法只有重新录制脚本。
6、Windows xp2 与ISS组件不兼容，则有可能导致HTTP500错误。对ISS组件进行调整后问题解决。
7、系统开发程序写的有问题，则报HTTP500错误。例如有些指针问题没有处理好的，有空指针情况的存在。修改程序后问题解决。
8、如果测试中所进行的操作需要向数据库中插入数据，若大数据量的情况下导致数据库中表空间已满，或 缓冲池较小无法满足数据的存取等，都有可能导致HTTP500错误。调整数据库、修改连接池大小，问题解决。
500错误出现的原因太多了，对于我来说，出现500错误很都情况下都是代码里有些关联没有做，然后导致出错，当然还有一小部分是有时候不注意，服务器开的时间过长，导致服务器崩溃，总之，很多地方都需要注意
1_代码重构漫画.jpeg
项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。
造成这样的原因往往有以下几点：
对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。
重构一书的作者Martin Fowler对重构的定义：
根据重构的规模可以大致分为大型重构和小型重构：
大型重构 ：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。
小型重构 ：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。
2_代码常见问题.png
代码重复
方法过长
过大的类
逻辑分散
严重的情结依恋
数据泥团/基本类型偏执
不合理的继承体系
过多的条件判断
过长的参数列
临时变量过多
令人迷惑的暂时字段
纯数据类
不恰当的命名
过多的注释
3_代码质量如何衡量.jpg
代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。
要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。
4_SOLID原则.png
一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。
添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。
开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。
很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。
子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
子类可以扩展父类的功能，但不能改变父类原有的功能
调用方不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
一个对象应该对其他对象保持最少的了解
尽量使用合成/聚合的方式，而不是使用继承。
单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
image.png
模块结构说明
代码开发要遵守各层的规范，并注意层级之间的依赖关系。
多个方法代码重复、方法中代码过长或者方法中的语句不在一个抽象层级。
方法是代码复用的最小粒度，方法过长不利于复用，可读性低，提炼方法往往是重构工作的第一步。
意图导向编程 ：把处理某件事的流程和具体做事的实现方式分开。
将函数放进一个单独对象中，如此一来局部变量就变成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。
方法参数比较多时，将参数封装为参数对象
任何有返回值的方法，都不应该有副作用
临时变量仅使用一次或者取值逻辑成本很低的情况下
将复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途
把复杂的条件表达式拆分成多个条件表达式，减少嵌套。嵌套了好几层的if - then-else语句，转换为多个if语句
当出现大量类型检查和判断时，if else（或switch）语句的体积会比较臃肿，这无疑降低了代码的可读性。 另外，if else（或switch）本身就是一个“变化点”，当需要扩展新的类型时，我们不得不追加if else（或switch）语句块，以及相应的逻辑，这无疑降低了程序的可扩展性，也违反了面向对象的开闭原则。
非正常业务状态的处理，使用抛出异常的方式代替返回错误码
某一段代码需要对程序状态做出某种假设，以断言明确表现这种假设。
当使用一个方法返回的对象时，而这个对象可能为空，这个时候需要对这个对象进行操作前，需要进行判空，否则就会报空指针。当这种判断频繁的出现在各处代码之中，就会影响代码的美观程度和可读性，甚至增加Bug的几率。
空引用的问题在Java中无法避免，但可以通过代码编程技巧（引入空对象）来改善这一问题。
根据单一职责原则，一个类应该有明确的责任边界。但在实际工作中，类会不断的扩展。当给某个类添加一项新责任时，你会觉得不值得分离出一个单独的类。于是，随着责任不断增加，这个类包含了大量的数据和函数，逻辑复杂不易理解。
此时你需要考虑将哪些部分分离到一个单独的类中，可以依据高内聚低耦合的原则。如果某些数据和方法总是一起出现，或者某些数据经常同时变化，这就表明它们应该放到一个类中。另一种信号是类的子类化方式：如果你发现子类化只影响类的部分特性，或者类的特性需要以不同方式来子类化，这就意味着你需要分解原来的类。
继承使实现代码重用的有力手段，但这并非总是完成这项工作的最佳工具，使用不当会导致软件变得很脆弱。与方法调用不同的是，继承打破了封装性。子类依赖于其父类中特定功能的实现细节，如果父类的实现随着发行版本的不同而变化，子类可能会遭到破坏，即使他的代码完全没有改变。
举例说明，假设有一个程序使用HashSet，为了调优该程序的性能，需要统计HashSet自从它创建以来添加了多少个元素。为了提供该功能，我们编写一个HashSet的变体。
通过在新的类中增加一个私有域，它引用现有类的一个实例，这种设计被称为组合，因为现有的类变成了新类的一个组件。这样得到的类将会非常稳固，它不依赖现有类的实现细节。即使现有的类添加了新的方法，也不会影响新的类。许多设计模式使用就是这种套路，比如代理模式、装饰者模式
继承与组合如何取舍
Java提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。自从Java8为接口增加缺省方法（default method），这两种机制都允许为实例方法提供实现。主要区别在于，为了实现由抽象类定义的类型，类必须称为抽象类的一个子类。因为Java只允许单继承，所以用抽象类作为类型定义受到了限制。
接口相比于抽象类的优势：
接口虽然提供了缺省方法，但接口仍有有以下局限性：
接口缺省方法的设计目的和优势在于：
为了接口的演化
可以减少第三方工具类的创建
可以避免创建基类
由于接口的局限性和设计目的的不同，接口并不能完全替换抽象类。但是通过对接口提供一个抽象的骨架实现类，可以把接口和抽象类的优点结合起来。 接口负责定义类型，或许还提供一些缺省方法，而骨架实现类则负责实现除基本类型接口方法之外，剩下的非基本类型接口方法。扩展骨架实现占了实现接口之外的大部分工作。这就是模板方法（Template Method）设计模式。
Image [5].png
接口Protocol：定义了RPC协议层两个主要的方法，export暴露服务和refer引用服务
抽象类AbstractProtocol：封装了暴露服务之后的Exporter和引用服务之后的Invoker实例，并实现了服务销毁的逻辑
具体实现类XxxProtocol：实现export暴露服务和refer引用服务具体逻辑
由于为了保持Java代码的兼容性，支持和原生态类型转换，并使用擦除机制实现的泛型。但是使用原生态类型就会失去泛型的优势，会受到编译器警告。
每一条警告都表示可能在运行时抛出ClassCastException异常。要尽最大的努力去消除这些警告。如果无法消除但是可以证明引起警告的代码是安全的，就可以在尽可能小的范围中，使用＠SuppressWarnings("unchecked")注解来禁止警告，但是要把禁止的原因记录下来。
参数化类型不支持协变的，即对于任何两个不同的类型Type1和Type2而言，List既不是List的子类型，也不是它的超类。为了解决这个问题，提高灵活性，Java提供了一种特殊的参数化类型，称作有限制的通配符类型，即List? extends E和List? super E。使用原则是producer-extends，consumer-super（PECS）。如果即是生产者，又是消费者，就没有必要使用通配符了。
还有一种特殊的无限制通配符List?，表示某种类型但不确定。常用作泛型的引用，不可向其添加除Null以外的任何对象。
嵌套类（nested class）是指定义在另一个类的内部的类。 嵌套类存在的目的只是为了它的外部类提供服务，如果其他的环境也会用到的话，应该成为一个顶层类（top-level class）。 嵌套类有四种：静态成员类（static member class）、非静态成员类（nonstatic member class）、匿名类（anonymous class）和 局部类（local class）。除了第一种之外，其他三种都称为内部类（inner class）。
总而言之，这四种嵌套类都有自己的用途。假设这个嵌套类属于一个方法的内部，如果只需要在一个地方创建实例，并且已经有了一个预置的类型可以说明这个类的特征，就要把它做成匿名类。如果一个嵌套类需要在单个方法之外仍然可见，或者它太长了，不适合放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的，否则就做成静态的。
通过对常见场景的代码逻辑进行抽象封装，形成相应的模板工具类，可以大大减少重复代码，专注于业务逻辑，提高代码质量。
面向对象编程相对于面向过程，多了实例化这一步，而对象的创建必须要指定具体类型。我们常见的做法是“哪里用到，就在哪里创建”，使用实例和创建实例的是同一段代码。这似乎使代码更具有可读性，但是某些情况下造成了不必要的耦合。
对于顶层的（非嵌套的）类和接口，只有两种的访问级别：包级私有的（没有public修饰）和公有的（public修饰）。
对于成员（实例/域、方法、嵌套类和嵌套接口）由四种的访问级别，可访问性如下递增：
正确地使用这些修饰符对于实现信息隐藏是非常关键的，原则就是：尽可能地使每个类和成员不被外界访问（私有或包级私有）。这样好处就是在以后的发行版本中，可以对它进行修改、替换或者删除，而无须担心会影响现有的客户端程序。
不可变类是指其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例时提供，并在对象的整个生命周期内固定不变。不可变类好处就是简单易用、线程安全、可自由共享而不容易出错。Java平台类库中包含许多不可变的类，比如String、基本类型包装类、BigDecimal等。
为了使类成为不可变，要遵循下面五条规则：
可变性最小化的一些建议：
TDD的最终目标是整洁可用的代码（clean code that works）。大多数的开发者大部分时间无法得到整洁可用的代码。办法是分而治之。首先解决目标中的“可用”问题，然后再解决“代码的整洁”问题。这与体系结构驱动（architecture-driven）的开发相反。
采用TDD另一个好处就是让我们拥有一套伴随代码产生的详尽的自动化测试集。将来无论出于任何原因（需求、重构、性能改进）需要对代码进行维护时，在这套测试集的驱动下工作，我们代码将会一直是健壮的。
Image [6].png
添加一个测试 - 运行所有测试并检查测试结果 - 编写代码以通过测试 - 运行所有测试且全部通过 - 重构代码，以消除重复设计，优化设计结构
作者：VectorJin