来源：juejin.cn/post/6844904142960328718前言刚刚和同事开个分享会，作者分享了一些代码设计模式相关的内容。并回顾项目中一些复杂的业务场景，为什么没有很好的应用设计模式。虽然业务肯定是保密的，但是不管是项目还是业务层面，我回顾了笔者之前的项目，还是有一些关于设计模式和代码规范的内容值得写出来和大家分享的。究竟什么是设计模式？主流的说法，大致是这样的：设计模式是解决一个问题的描述或模板，可以在很多不同的情况下使用，通常最被认为是OOP中的最佳实践解决方案。术语最佳实践的作者在介绍设计模式的几个地方都看到过它。但是设计模式真的是OOP中业务开发的最佳实践吗？首先说一下笔者的观点，我是如何理解设计模式的：设计模式是一种代码规范，不同于空格、缩进等容易被插件检测到的东西。它是一个中间代码规范，初学者不应该理解，不容易被插件检测到。因此，笔者认为设计模式属于代码规范层面，能否成为最佳实践取决于用户。常规业务开发中设计模式的存在，在网上经常可以看到。很多人分享“祖传密码”、“游戏式气功密码”、“石山密码”等。我们没有设计模式吗？没有代码规范吗？幸存者偏见是部分原因，只有糟糕的代码才会被挂起和抱怨。总的来说，这样的情况还是很多的，那么这种情况是怎么产生的呢？难道是这个班的程序员水平不够？代码标准化或使用设计模式的痛点笔者首先回顾了设计模式在业务开发中不能很好应用的一些因素。在对性能的极端考量下，比如Java语言，设计模式面临的类文件和代码也更多。在类加载和内存使用上的成本自然会比不使用设计模式略高。但不能一概而论。一些设计模式（如：单例模式、享元模式等）的出现是为了提高性能或节省资源成本。并且在大多数情况下，良好的代码维护带来的好处远大于这点小小的性能开销，所以性能上使用了删除线。Classexplosion虽然网上已经有各种设计模式的小demo代码，但是仍然可能存在设计缺陷和过度设计。复杂的设计模式需要依赖业务建模，不能开箱即用，更不能“死记硬背”。设计缺陷和过度设计，对开发者来说都是同样痛苦的，都会出现“不应该使用设计模式”，或者干脆为“迎合缺陷的设计模式”编写逻辑复杂的代码。爆炸是不可避免的。而且，即使平时使用的设计模式在复杂的业务场景下，类爆炸也是不可避免的。比如在策略模式中，如果业务情况比较多，你也必须把每个情况的实现类都写出来。这对开发的时间成本有一些微妙的影响。甚至据笔者所知，在一些传统公司，或者日本的项目，几乎一个班级都必须有一个Excel文档，详细说明班级的作用和组成元素。你可能跟我想的一样，找个javadocapi，把评论反向生成Excel，不就完了吗？但实际上，这些企业中的大部分还是依靠人力来完成这些任务。类的数量增加了，这对维护文档的人来说也是一个巨大的挑战。团队成员的编码水平在传统软件公司。为了节约成本，很难实现全员“高配置”和自驾精神。通常是一对N的人员配置，让薪资微薄的初级工程师有“高内聚、低耦合、以开闭为代表的设计模式六大原则”这样的设计思想有点尴尬原则。”.这里说个题外话，很多初级工程师其实对框架是很“适应”的，当然不是真的适应。比如：如果代码中没有统一的异常处理，那么时间久了你会发现自己的trycatch到处都是。再比如，如果项目中没有引入工具类库，那么时间久了你会发现网上到处都是千奇百怪的util类，甚至每个类中都有重复的工具方法。这些问题不能算是初级工程师。他们应该归功于技术总监。比如你观察到项目中没有工具库，是不是应该先去公司内部的二方库找找？如果没有，是不是应该引入commons-lang3、hutool、guava等优秀的第三方库。项目环境我们生活在一个高度架构化的流量时代。高并发、大流量、各种微服务、中间件构建已经是主流趋势。那么代码层面的设计模式和代码规范的状态就有点微妙了。笔者也见过很多项目，架构师只考虑是否需要“加机器、加中间件、加配置”等上层建筑。因为组员水平脱档，对代码的要求几乎为0，没有review之类的规则，可以实现。时间成本与敏捷开发在敏捷开发场景下，频繁的业务变更和快速的项目迭代当然也是影响因素之一。比如常说的if-else策略模式可以优化。如果一开始只有一个分支，你会用设计模式吗？那么增加一个需求变化呢？如果再加一个呢？什么时候选择使用设计模式来优化代码，或者是否使用优化，有没有时间优化都是问题。通常有经验的工程师不会说“这只是一行代码，一分钟就能改完”之类的话。毕竟修改代码，要考虑全局性（其他代码是否有相同的修改要求）、正确性、分支影响（是否影响其他逻辑的执行）。甚至还有公司对覆盖率和测试品类有要求，所以用打字速度来判断需求执行速度并不是业内人士的经验。这个时间成本也成为一个因素。人员流动人员流动在互联网上并不是什么稀罕事。一方面是公司方面的原因。伴随着改革的春风，已经来到了遍地“老板”的时代。有的企业要求不合理，甚至条款不合法，导致人才流失。二是个人原因。级别高就跟着高薪，级别低就被低薪劝退。所以不管是什么原因，在人员频繁流动的情况下，代码质量要想做好，对管理也是一个挑战。毕竟如果接手一个逻辑复杂的龟派气功代码，业务逻辑又没有完全清晰，大部分人都会老老实实的加上ifelse来完成需求。分析代码规范和设计模式重要吗？以上列举了项目开发中的一些代码规范和设计模式使用中的一些痛点。之所以称为痛点而不是缺点，是因为在上面的一些场景中，代码并不是重要的部分，代码规范不值一提。所以重要与否，基于以上，除了主观因素，还有团队因素，甚至还有团队管理者。毕竟在某些场景下，只对开发者友好，对KPI无用，导致疏忽。如何继续做好代码规范如果我们是一个有极客精神的团队，或者我们想设计一个长期维护的产品，建议做好代码的实现规范和设计模式。那么不妨从笔者总结的痛点出发，结合自己当前的场景一一分析，得出一个“平衡”点。笔者也大致总结了一些应对上述措施的要点，但是每个人都有自己的情况，就像设计模式本身一样，不能“死记硬背”。对业务的深入理解和良好的业务预测，将为底层设计打下良好的基础。在保证用工成本的情况下，今天自发的成员不在少数，所以我们要拿出信心，共同做好基础设施建设。复杂的业务点在早期的某个时刻频繁迭代，需要技术负责人切入、测工时、分析业务，以确定是否需要重构，或者代码设计方案。在人员流动频繁的情况下，工作尽量做到有据可查，不能以“走手续”为依据。不仅代码要交好，业务也要交好。传统项目，日本项目应该充分利用自动化工具，尽可能替代人工文档维护。当然，本文提到的痛点在中小企业中是最不容易发现的，不是三言两语就能解决的，所以尽量做到平衡是非常好的。如果不存在这些痛点，人员自驱动，基础设施好。很有可能是一家足够优秀的公司。如果你是这样一家公司的员工，还坚持看到这个，那你就应该理解中小企业的小毛病了。最后，刚入行的时候，笔者曾看着历史代码笑道，“这么乱的代码，我怕散装喝假酒。”时光荏苒，随着工作年限的增加，看问题的角度也在不断变化。现在不仅不会有嘲讽，还总结了乱码的原因。对设计模式和代码规范的思考也有了新的认识。上面说到，刚好在和同事开会的时候提到，所以整理成文档。近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
