起源：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开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！