共计 3202 个字符，预计需要花费 9 分钟才能阅读完成。
起源：juejin.cn/post/6844904142960328718
前言
刚刚与共事开了一个分享会，笔者分享了一些了代码 设计模式 相干的内容。
以及复盘了一下我的项目中有些简单的业务场景，为什么没有很好的利用到 设计模式。
业务尽管必定窃密的，然而抛开 我的项目 ， 业务 层面，纵观回顾了一下笔者以往的我的项目，
对于 设计模式 和代码标准 问题还是有一些内容还是值得落笔和大家分享的。
设计模式到底是什么？
支流的说法，大抵如此：
设计模式是解决可在许多不同状况下应用的问题的形容或模板，个别在 OOP 中最作为最佳实际的解决方案。
最佳实际一词笔者再几处介绍设计模式的中央，都有看到。然而设计模式真的就是 OOP 中，业务开发的最佳实际吗？
首先申明笔者的观点，我是如何了解设计模式的：
设计模式是一种代码标准，不同于 空格 ， 缩进 这类容易被插件检测的入门标准，是一种 中级代码标准，不宜被入门者了解，不易被插件所检测。
所以笔者认为 设计模式 是属于 代码标准 级别的，能不能成为 最佳实际，也要看使用者。
设计模式在惯例业务开发的存在感
经常在网上能看到，很多人晒本人碰到的“祖传代码”，“龟派气功式代码”，“shǐ山代码”等等。
咱们不是有设计模式吗？不是有代码标准吗？
幸存者偏差是一部分起因，只有烂代码才会被挂进去让人吐槽。
综合来看这种状况还是很多，那么是如何造成这种场面的，难道是这届程序员程度不行？
代码规范性或应用设计模式的痛点
笔者首先复盘了一些在 业务开发 中为什么 不能很好利用设计模式 的因素。
性能
在极其的思考下，例如 Java 语言，设计模式面临着 更多的类文件 以及 更多的代码。
在类加载和内存应用上的老本，天然是稍微高于不应用设计模式。
然而也 不能一概而论 ，有些设计模式(如：单例模式，享元模式等) 就是为了 进步性能 或节约资源 老本而呈现的。
以及大多数状况下，良好的代码维护性长处要远远大于这点渺小的性能开销，所以性能用了删除线。
类爆炸
尽管网上曾经有各种设计模式的小 Demo 代码，然而还是可能会呈现 设计存在缺点 ， 适度设计 等状况。
简单的设计模式，须要依附业务建模，并不能拿来即用，甚至“生抄硬套”。
设计缺点和适度设计，两者对开发人员都是一样苦楚的，会呈现“不该用设计模式而用 ”，或者单纯为了” 投合缺点的设计模式”，写出对应逻辑简单的代码，这样类爆炸不可避免。
而且，就算失常应用的设计模式在业务简单状况，类爆炸也不可避免。比方策略模式，如果业务状况就是有很多，你也必须把每个状况实现类写进去。
这就对开发的工夫老本有一些轻微的影响了。
甚至据笔者所知，有些 传统公司 ，或者 对日我的项目，简直一个类要有一个 Excel 文档，具体阐明类和其中元素的作用。
你可能和我想的一样，找个 javadoc 的 api，逆向从正文生成 Excel 不就完了吗？
但实际上这类公司大多数还是靠 人力 实现这些工作的，类的数量多了起来，对保护文档的人也是微小挑战。
团队成员编码程度
在传统的软件公司，出于节约老本思考，很难做到人员全副“高配”并且可能有自驱动的精力。
通常都是 1 拖 N 的人员配备，想让薪资寥寥的高级工程师就有“高内聚，低耦合 ，以及 开闭准则 为代表的设计模式六大准则等”这类的设计思维，也是有点难为情。
此处说句题外话，
而且很多高级工程师其实对框架很“有适应性 ”的，当然 并非真正的适应性。
比方：如果代码里没有 对立异样解决，那么工夫长了你就会发现，到处都是本人的try catch。
再比方，我的项目里没有引入工具类库，那么工夫长了你就会发现，到处都是网上奇怪的 util 类，甚至每个类中都有反复的工具办法。
这些不能算是高级工程师的问题，要归纳于 技术负责人 ，比方察看到了我的项目中还没有工具库，那么是不是应该先去公司外部的 二方库 中寻找，如果没有是不是应该引入 commons-lang3，hutool，guava 这类的第三方优良库等等。
我的项目大环境
咱们生存在一个 高度架构 为主的 流量时代。高并发，大流量，各种微服务，以及中间件建设等等曾经是支流趋势。
那么代码层面的 设计模式 以及代码规范性的位置，就有些奥妙了。
笔者也见过不少我的项目，架构师只去思考是不是该“加机器，加中间件，加配置”等下层建设。因为团队成员程度断档，对代码的要求简直为0，也没有 review 等规定，能实现即可。
工夫老本与麻利开发
在麻利开发场景，业务频繁变动，我的项目疾速迭代，这当然也是因素之一。
比方常说的能够优化 if else 的策略模式，如果初期只有一个分支，你会用设计模式吗？那么需要变动加了一个呢？如果又加了一个呢？
什么时点抉择应用 设计模式 优化代码，或者 用不必优化 ，以及 有没有工夫优化 都是个问题。
通常有教训的工程师，个别不会说出“这不就一行代码嘛，一分钟改完”这样的话。
毕竟批改代码，要思考 全局性 (是否其它代码也有雷同批改需要)， 正确性 ，以及 分支影响性(是否影响其余逻辑的执行)。
甚至也有公司对 覆盖率 和测试类 有要求，所以用打字速度断定需要落地速度，并不是业内人士的经验之谈。
这样工夫老本也成为了一个因素。
人员流动
人员流动在互联网不是一个稀奇的事件。
一方面是 公司起因 ，随着改革春风吹满地，曾经到了遍地“老板”的年代，一些公司，要求不合理，甚至条款都是违 fa 行为导致人才流失。二是 集体起因，程度高为高薪所走，程度低被低薪劝退。
那么不论那种起因，在人员频繁流动下，代码品质要想做好，对治理上也是一种挑战。
毕竟如果你接手一个逻辑简单的 龟派气功代码 ，业务逻辑还没齐全清晰的场景下，大多数人会老老实实的增加if else 以实现需要。
剖析
代码标准 & 设计模式重要吗？
上文列举了一些，在我的项目开发中 代码标准 ，以及 应用设计模式 上的一些痛点。
之所以称之为 痛点 而不是 毛病，起因就像上文有些场景，代码都不是重要的一环，代码标准更不值一提，何来毛病一说。
所以重不重要，综合上文来看，除了主观因素，团队因素，甚至还有团队管理者的起因。毕竟确实在一些场景，只是对开发人员敌对，对 KPI 来讲毫无用处，导致了不器重。
如何继续做好代码标准
如果咱们是有 geek 精力 的团队，或者要设计长时间保护的产品，还是倡议做好代码标准和设计模式的落地。
那么就无妨从笔者总结的痛点上，联合本人当下场景逐条剖析，获得一个“均衡”点。
笔者也大抵总结了几点，以应答下面的措施，但每个人都有每个人的状况，和 设计模式 自身一样，不能“生抄硬套”。
- 深刻了解业务，做好 业务预判，这样就为了底层设计打出良好基础。
- 在保障人力老本的状况下，自驱性的成员在当今也不在少数，要给予信念一起 做好根底建设。
- 简单的业务点频繁迭代某个 晚期时刻，技术负责人须要切入，掂量工时剖析业务，以便判定是否须要重构，或者出代码设计方案。
- 人员频繁流动下，工作要尽量造成文档，不能以“走模式”为主，不仅要良好交接代码，还要良好交接业务。
- 传统我的项目，对日我的项目要充分利用自动化工具，尽量多多代替人工的文档保护。
当然了，本文提到的痛点，在中小公司最不难发现，更不是喋喋不休就能解决，所以尽力做到均衡就十分好了。
如果不存在这些痛点，人员自驱性强，根底建设良好等。大概率是足够优良的企业了，如果你是这样企业的员工，还保持看到这里，那就当理解一下中小企业的小问题。
结尾
刚入行时，笔者也曾看着历史代码收回笑声，“这么乱的代码，怕是喝了散装假酒”。
时过境迁，随着工作年限的增长，看问题的角度也在一直发生变化，当初不仅不会收回讥笑了，还总结了乱代码呈现的起因。
对于 设计模式 和代码标准 方面的思考也有了新的了解，也如上文所说，碰巧与共事散会提到了，所以整顿成文。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！