简单设计的五句话

今天上午的一个收获吧，听老人家讲的Kent Beck简单设计的五句话。并且昨天老人家还介绍我看了《重构》那本书，结合上下文的话，今天这五句话仍是颇有点意思的。

话很少说，五句话摆出来：一、测试；二、重用性；三、设计意图明确；四、避免多余实体；五、以上各条，按重要顺序排列。

而后拓展一下这五句话，否则看起来太简单了，有点寒酸呀。

首先，测试。测试是重构的前提，是简单设计的前提，就是说不出多重要的重要。为何呢，能够说有了测试，有了完备的测试，才能放心的去重构你的code设计，提升的是confidence level。并且补充一个，昨天老人家跟我说，TDD，就是要先写测试，再写开发，若是你的方法须要其余类或者service的协助，则mock起来；虽然有的状况下，好比修改代码或者作spike，会先写出code，再添加测试，但仍然，写测试的时候，only keep in mind的是业务，绝对不是实现。孩子，记得哦，业务和实现必定要分开，就好像martin fowler说的两顶帽子，当年写code的时候带着一顶帽子，作重构的时候要带着另外一顶帽子，带着code帽子的时候就必定不修改原有代码，只添加新功能；带着refactor帽子的时候，就专一于refactor，对code的修改。同理，业务和实现也是两顶帽子。

 

第二，重用性。重用性就是为了不重复代码，由于代码越少，后来人对代码进行修改的时候就越容易理解，也越容易修改。另外一方面，为了更容易重用代码，就要用到单一职责的原则啦，这样的code才容易重用。duplicate code虽然对于编译器没有什么影响，或者对于效率也不会产生太大影响，可是嘛，code老是要修改的，不论是需求的变化，仍是避免代码腐坏，因此重用对编译器能够没有什么感受，可是对修改代码的咱们，就颇有feel啦。

 

第三，设计意图明确。这个也是为了后来人的，让人一看你的code就会很清晰你究竟想要作什么。这个包括code的设计，接口的设计，也包括最直观的变量方法命名，这个就是可读性啦，并且想起来很重要的一件事，你去作一件事情的时候，作事情的时间必定比你提早想清楚这件事情的时间长的多。想清楚。

 

第四，避免多余的实体。这个嘛，什么是多余的实体呢，老人家也给了他多年经验的总结，很给力的两条：第1、无重用，若是一个方法只在一个地方须要，那么就暂时没有必要将其提取到一个类中，而是做为私有方法存在于当前类；第2、无修改，若是一个方法可能有多种规则，须要变化，则也应该提取。举个例子吧，有一个processor类须要对数据进行process，可是在process以前须要作validation，那么这个validation若是只在这一个地方用到的话，就能够做为private validate方法存在，可是若是有其余类也须要validation，那么就能够提取validator类，或者不一样地方采起不一样的validation规则，那么能够定义validator接口，有不一样的实现方式，在用到validate的类中经过composition引入validation，而且经过spring依赖注入将选用的某种validator实现类注入进去。这个也是使用接口以及使用spring DI的好处啦，能够达到loose couple哦。

 

第五，以上各条按重要顺序排列。就是再次强调，测试，必定要有尽量高覆盖的测试；必定避免duplicate code而且坚守单一职责原则；注意你的思惟必定要是清晰的，而且把这种清晰体如今code中；对了，想起来昨天老人家跟我说的另一点，在写code的时候，必定要体现业务逻辑，用业务逻辑把实现细节包裹起来。

 

其实，还有不少想写的，可是考虑到单一职责原则，一篇博客只谈一个主题（不过貌似我中间没有收住，仍是多说了一些其余东西）。由于我发现，敏捷不仅是一种编码的东东，也是一种生活方式，重构也同样。不少思想，能够做为生活方式。不只仅是更快捷高效的编码，也是更快捷高效的生活！加油加油