refactoring（重构）是我们整天挂在嘴边的，也有很多我们自己写代码的技巧，而Refactoring improving the Design of Existing code这本书就是把我们那些技巧总结整理下来，归纳为方式方法，这本书里基本囊括了我们平时所有重构的技巧，看这本书当中我们会惊叹原来我们平时使用的这些在很早之前就有人整理出来了，大神就是大神。
以下我就列举几点典型的方法：
- Extract Method
额外的函数适合于重构过长的函数，把其分解成多个独立功能的函数，函数功能单一使人更容易理解，以及修改才更不容易出错。 - Move Method
移动函数适合于逻辑的理解，本质上一个函数式可以放在任何位置的，但我们要去思考这个函数的功能，以及这个函数放在什么位置更易于理解。 - Replace Temp With Query
临时变量往往引发问题，他们会导致大量参数被传来传去，这就导致我们有可能会改变变量的值，而这种改变通常是错误的，尤其是在很长的函数体内。
借用书中的话来描述重构的意义：任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。
TDD（测试驱动开发）是现在比较火的概念，貌似很高大上的概念什么的，让我们来看看测试驱动开发这本书是怎么描述的。
书中归纳为以下几个步骤：
- 快速新增一个测试
- 运行所有的测试，发现最新的测试不能通过
- 做一些小小的改动
- 运行所有的测试，并且全部通过
- 重构代码，以消除重复设计，优化设计结构
这里让当时的我感到最惊奇的是，做开发我们居然不是先写我们的程序运行代码，而是先写测试！甚至不是定义我们的api！对你没看错，就是先写测试。讲真，我看到这里是很怀疑的，因为这个不符合我们平时开发的流程，测试对于我的认知是检验程序运行状态的步骤，而不是开发的步骤。
当时的我们留了这样一道题目https://github.com/priyaaank/MarsRover，让我们按照TDD的模式开发。我相信，只要大家严格按照TDD开发，当我们做完之后会意识到TDD的优势的。
平时我们的开发会有很长时间的设计阶段，我们似乎也秉承着设计的重要性是大于coding的。这样的做法当然无可厚非，但是这样经常会带来另一种结果，就是过度的设计。其实现在使我们开发当中的通病，我们遇到了什么需求功能，就先在脑中过滤一遍设计模式，就恨不得把每个设计模式都做到我们的系统中。但这样反而是带来了我们前期开发和后期维护的重大无用成本。
用传统开发模式和TDD开发模式，对比结果你通常会发现，TDD的结果是更合理的，当下更优的实现方式。其实一个好的产品是演化过来的，我们并不需要在一开始就做很完备的产品。
贫血模型和富血模型（富血模型就是现在很火的领域驱动模型DDD的另一个称呼），网上讨论两者优劣势的文章很多。贫血模型很容易于我们程序员写代码，例如我们最常写的controller->service->dao->entity就是贫血模型，程序员可能不需要太理解为什么划分的这些层次，只需要知道在每一层写什么代码就好了。而富血模型就要求很高了，它要求我们需要很强的抽象能力，对每一个Domian领域对象都很很深的理解，这样我们划分的函数、业务才适用于我们的领域，否则那我们的程序将会是一场灾难。其实我们绝大多数的系统都没有复杂到必须使用富血模型的境地，只有一些业务非常复杂的系统才适合使用使用，一些CRUD系统是绝对不需要使用DDD的。这里https://mp.weixin.qq.com/s/9kTZqk5-gQd-SToqZw0Y4w有一个很不错的文章，可以参考。
TDD开发出来的程序，我们写出来的Domain对象很自然的就有其行为，这在某些方面和富血模型有些贴近，所以当我们觉得一个领域模型很难设计的时候，可以考虑使用TDD来做的。
