设计模式是一种非常有用的设计参照，基本上每次去读设计模式的内容总是会获得新的体会。但是有没有新的模式呢？我想，这个大概是有的，不过新的模式产生估计会非常困难。
在编码一段时间之后，大概在一年或者两年之后，我们一般都在想，可不可以把编码做的更好一些，让别人更加容易阅读，更加好维护，更加好修改。怀着这种简单的想法，我开始学习怎么去改良代码。设计模式引领我从纯粹的实现到技术设计方面的思考，也同时非常感谢设计模式提供了很多的设计范例，让我在设计方面有了最基础的积累，让我明白了，一个好的设计并不是那么容易的，同理，一个好设计的实现是更加不容易的。好的设计就和好的算法一样，需要针对具体的实际情况，甚至是实际的情况稍有变动，设计的结构就要发生变化。
在工作中，第一个层次的设计是比较浅显易懂的，它是基于一个业务功能，不考虑与其他部分的依赖关系。这个大部分都做过，例如我们要在某个业务模块内对一些业务功能做一些白名单验证。具备这个层次需要思考的就是做一个通用的类似filter一样的验证，验证必须对不验证的业务做一些默认设置，对进行验证的业务设置具体的验证内容。发生从不验证的业务变更到需要验证，只需要加入对应的数据载入和白名单内容配置。同理从验证到不验证也只需要删除配置数据和对应的数据载入。这样的功能性设计是设计模式所推崇的，基于纯粹功能上的设计，对业务很少牵扯。做到这一步通常也是不容易的，要做到熟读设计模式，然后忘记其具体内容，根据实际情况去组合用到的设计模式，甚至是直接抛弃掉设计模式，用最简单的代码去实现。
第二个层次的设计是某一个系统级的设计，这种情况要更加的复杂，这个是项目级的设计。这些通常是基于某个业务系统，例如XXX车贷项目。这种设计要求人们具备更加高层次的目光，要明确外部的依赖关系，也要明确依赖关系中出现异常或者错误的具体提示信息应该怎么去设定。外部的依赖明确之后，本系统的设计应该怎么去设计，怎么去分析本系统的基础功能和应用功能，基础功能需要怎么去设计才可以保证整个系统的业务访问要求，对异常或者错误怎么去设计等等，这个部分是重点，要求是通用功能要设计良好，同时有文档支持，还要有高易用性。在我的工作中，看到很多的底层设计，不过这个做起来真的非常难。难在需要根据个人的经验去判断，而且易用性的标准在不同的人眼里是不一样的，只能用一些具体的业务指标去确认。工期越是紧急的项目，对项目的基础功能设计和实现要求越高，这个是项目工期的关键。
第三个层次是分布式系统的设计，这个是现在大多数基于网络的项目。例如现在银行的系统都是分布式的系统，系统的网络组织结构是网状的结构。核心系统在系统中占据少数的几个节点，其次是一些做数据整合和封装的数据整合节点，这些节点的数目稍微多一些，最多的节点是外围的渠道节点。渠道节点均算作银行系统的外围数据输入输出显示节点。这种分布式系统的关键在于数据的一致性、传输限时性、信息的安全性。每一个出现在这种系统当中的问题都是需要连接多个节点进行排查和修复的。
我们在与这些内容打交道的时候，对个层面都要有足够多的积累，即便这些积累是被别人使用过的，都要仔细的去分析和研究。重复不是问题，问题是只知道复制，不知道复制过来的符不符合我们的需要。虽然现在大家都在喊创新，不过全新的创新是罕见的，更多的是基于一些经典的设计或者案例进行调整，包括但是不限于代码。
Note:不要打着重用的名义去复制，要以改良的名义去重用。