前言
关于设计模式和代码规范问题，有一些内容值得分享。
正文
设计模式究竟是什么？
主流的说法大致如此：设计模式是解决可在许多不同情况下使用的问题的描述或模板，一般在 OOP 中作为最佳实践的解决方案。
最佳实践一词笔者在几处介绍设计模式的地方都有看到。但是设计模式真的就是 OOP 中业务开发的最佳实践吗？
首先声明笔者的观点，我是如何理解设计模式的：
设计模式是一种代码规范，不同于空格、缩进这类容易被插件检测的入门规范，是一种中级代码规范，不宜被入门者理解，不易被插件所检测。
所以笔者认为设计模式是属于代码规范级别的，能不能成为最佳实践，也要看使用者。
设计模式在常规业务开发的存在感
常常在网上能看到，很多人晒自己碰到的'祖传代码'，'龟派气功式代码'，'屎山代码'等等。
我们不是有设计模式吗？不是有代码规范吗？
幸存者偏差是一部分原因，只有烂代码才会被挂出来让人吐槽。
综合来看这种情况还是很多，那么是如何造成这种局面的，难道是这届程序员水平不行？
代码规范性或使用设计模式的痛点
笔者首先复盘了一些在业务开发中为什么不能很好应用设计模式的 factors。
性能
在极端的考虑下，例如 Java 语言，设计模式面临着更多的类文件以及更多的代码。
在类加载和内存使用上的成本，自然是略微高于不使用设计模式。
但是也不能一概而论，有些设计模式（如：单例模式，享元模式等）就是为了提高性能或节约资源成本而出现的。
以及大多数情况下，良好的代码维护性优点要远远大于这点微小的性能开销，所以性能用了删除线。
类爆炸
虽然网上已经有各种设计模式的小 Demo 代码，但是还是可能会出现设计存在缺陷，过度设计等情况。
复杂的设计模式，需要依靠业务建模，并不能拿来即用，甚至'生抄硬套'。
设计缺陷和过度设计，两者对开发人员都是一样痛苦的，会出现'不该用设计模式而用'，或者单纯为了'迎合缺陷的设计模式'，写出对应逻辑复杂的代码，这样类爆炸不可避免。
而且，就算正常使用的设计模式在业务复杂情况，类爆炸也不可避免。比如策略模式，如果业务情况就是有很多，你也必须把每个情况实现类写出来。
这就对开发的时间成本有一些细微的影响了。
甚至据笔者所知，有些传统公司，或者对日项目，几乎一个类要有一个 Excel 文档，详细说明类和其中元素的作用。
你可能和我想的一样，找个 javadoc 的 api，逆向从注释生成 Excel 不就完了吗？
但实际上这类公司大多数还是靠人力完成这些工作的，类的数量多了起来，对维护文档的人也是巨大挑战。
团队成员编码水平
在传统的软件公司，出于节约成本考虑，很难做到人员全部'高配'并且能够有自驱动的精神。
通常都是 1 拖 N 的人员配备，想让薪资寥寥的初级工程师就有'高内聚，低耦合，以及开闭原则为代表的设计模式六大原则等'这类的设计思想，也是有点难为情。
此处说句题外话，
而且很多初级工程师其实对框架很'有适应性'的，当然并非真正的适应性。
比如：如果代码里没有统一异常处理，那么时间长了你就会发现，到处都是自己的 try catch。
再比如，项目里没有引入工具类库，那么时间长了你就会发现，到处都是网上奇怪的 util 类，甚至每个类中都有重复的工具方法。
这些不能算是初级工程师的问题，要归结于技术负责人，比如观察到了项目中还没有工具库，那么是不是应该先去公司内部的二方库中寻找，如果没有是不是应该引入 commons-lang3，hutool，guava 这类的第三方优秀库等等。
项目大环境
我们生存在一个高度架构为主的流量时代。高并发，大流量，各种微服务，以及中间件建设等等已经是主流趋势。
那么代码层面的设计模式以及代码规范性的地位，就有些微妙了。
笔者也见过不少项目，架构师只去考虑是不是该'加机器，加中间件，加配置'等上层建设。由于团队成员水平断档，对代码的要求几乎为 0，也没有 review 等规则，能实现即可。
时间成本与敏捷开发
在敏捷开发场景，业务频繁变动，项目快速迭代，这当然也是因素之一。
比如常说的可以优化 if else 的策略模式，如果初期只有一个分支，你会用设计模式吗？那么需求变动加了一个呢？如果又加了一个呢？
