代码规范&设计模式落地之路

以你之姓@ 2022-09-09 09:19 145阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”
    
    回复“PDF”获取独家整理的学习资料！

![638de7421150343abf1a1d497e9d089b.png][]

![1891d8a5f03586aee9457d4c26277f29.png][]

![96c119461807da4ed54bc2380e941e4a.png][]

长按扫描上方一元购买

![8f5bfad7cbf1be8510e503525b09e353.png][]

# 来源：https://juejin.cn/post/6844904142960328718 #

# **|** **前言** #

刚刚与同事开了一个分享会，笔者分享了一些了代码**设计模式**相关的内容。

以及复盘了一下项目中有些复杂的业务场景，为什么没有很好的应用到**设计模式**。

业务虽然肯定保密的，但是抛开**项目**，**业务**层面，纵观回顾了一下笔者以往的项目，关于**设计模式**和**代码规范**问题还是有一些内容还是值得落笔和大家分享的。

# **|** **正文** #

## **设计模式究竟是什么？** ##

主流的说法，大致如此：

*设计模式是解决可在许多不同情况下使用的问题的描述或模板，一般在OOP中最作为最佳实践的解决方案。*

最佳实践一词笔者在几处介绍设计模式的地方，都有看到。  
但是设计模式真的就是OOP中，业务开发的最佳实践吗？

首先声明笔者的观点，我是如何理解设计模式的：

设计模式是一种代码规范，不同于**空格**，**缩进**这类容易被插件检测的入门规范，是一种**中级代码规范**，不宜被入门者理解，不易被插件所检测。

所以笔者认为**设计模式**是属于**代码规范**级别的，能不能成为**最佳实践**，也要看使用者。

## **设计模式在常规业务开发的存在感** ##

常常在网上能看到，很多人晒自己碰到的“祖传代码”，“龟派气功式代码”，“shǐ山代码”等等。

我们不是有设计模式吗？不是有代码规范吗？

![e29e276eca681b8453bfaa9f1164077f.png][]

幸存者偏差是一部分原因，只有烂代码才会被挂出来让人吐槽。

综合来看这种情况还是很多，那么是如何造成这种局面的，难道是这届程序员水平不行？

## **代码规范性或使用设计模式的痛点** ##

笔者首先复盘了一些在**业务开发**中为什么**不能很好应用设计模式**的因素。

### **性能** ###

在极端的考虑下，例如Java语言，设计模式面临着**更多的类文件**以及**更多的代码**。

在类加载和内存使用上的成本，自然是略微高于不使用设计模式。

但是也不**能一概而论**，有些设计模式(如：单例模式，享元模式等)就是为了**提高性能**或**节约资源**成本而出现的。

以及大多数情况下，良好的代码维护性优点要远远大于这点微小的性能开销，所以性能用了删除线。

### **类爆炸** ###

虽然网上已经有各种设计模式的小Demo代码，但是还是可能会出现**设计存在缺陷**，**过度设计**等情况。

复杂的设计模式，需要依靠业务建模，并不能拿来即用，甚至“**生抄硬套**”。

设计缺陷和过度设计，两者对开发人员都是一样痛苦的，会出现“**不该用设计模式而用**”，或者单纯为了”**迎合缺陷的设计模式**”，写出对应逻辑复杂的代码，这样类爆炸不可避免。

而且，就算正常使用的设计模式在业务复杂情况，类爆炸也不可避免。比如策略模式，如果业务情况就是有很多，你也必须把每个情况实现类写出来。

这就对开发的时间成本有一些细微的影响了。

甚至据笔者所知，有些**传统公司**，或者对日项目，几乎一个类要有一个Excel文档，详细说明类和其中元素的作用。

你可能和我想的一样，找个javadoc的api，逆向从注释生成Excel不就完了吗？

但实际上这类公司大多数还是靠**人力**完成这些工作的，类的数量多了起来，对维护文档的人也是巨大挑战。

### **团队成员编码水平** ###

在传统的软件公司，出于节约成本考虑，很难做到人员全部“高配”并且能够有自驱动的精神。

通常都是1拖N的人员配备，想让薪资寥寥的初级工程师就有“**高内聚**，**低耦合**，以及**开闭原则**为代表的设计模式六大原则等”这类的设计思想，也是有点难为情。

此处说句题外话，

而且很多初级工程师其实对框架很“**有适应性**”的，当然**并非真正的适应性**。

比如：如果代码里没有**统一异常处理**，那么时间长了你就会发现，到处都是自己的try catch。

再比如，项目里没有引入工具类库，那么时间长了你就会发现，到处都是网上奇怪的util类，甚至每个类中都有重复的工具方法。

这些不能算是初级工程师的问题，要归结于**技术负责人**，比如观察到了项目中还没有工具库，那么是不是应该先去公司内部的**二方库**中寻找，如果没有是不是应该引入commons-lang3，hutool，guava这类的第三方优秀库等等。

### **项目大环境** ###

我们生存在一个**高度架构**为主的**流量时代**。高并发，大流量，各种微服务，以及中间件建设等等已经是主流趋势。

那么代码层面的**设计模式**以及代码规范性的地位，就有些微妙了。

笔者也见过不少项目，架构师只去考虑是不是该“加机器，加中间件，加配置”等上层建设。由于团队成员水平断档，对代码的要求几乎为**0**，也没有review等规则，能实现即可。

### **时间成本与敏捷开发** ###

在敏捷开发场景，业务频繁变动，项目快速迭代，这当然也是因素之一。

比如常说的可以优化if else的**策略模式**，如果初期只有一个分支，你会用设计模式吗？那么需求变动加了一个呢？如果又加了一个呢？

什么时间点选择使用**设计模式**优化代码，或者用**不用优化**，以及**有没有时间优化**都是个问题。

通常有经验的工程师，一般不会说出“*这不就一行代码嘛，一分钟改完*”这样的话。

毕竟修改代码，要思考**全局性**(是否其它代码也有相同修改需求)，**正确性**，以及**分支影响性**(是否影响其他逻辑的执行)。

甚至也有公司对**覆盖率**和**测试类**有要求，所以用打字速度判定需求落地速度，并不是业内人士的经验之谈。

这样时间成本也成为了一个因素。

### **人员流动** ###

人员流动在互联网不是一个稀奇的事情。

一方面是**公司原因**，随着改革春风吹满地，已经到了遍地“老板”的年代，一些公司，要求不合理，甚至条款都是违fa行为导致人才流失。

二是**个人原因**，水平高为高薪所走，水平低被低薪劝退。

那么不管那种原因，在人员频繁流动下，代码质量要想做好，对管理上也是一种挑战。

毕竟如果你接手一个逻辑复杂的**龟派气功代码**，业务逻辑还没完全清晰的场景下，大多数人会老老实实的添加if else以完成需求。

## **|** **分析** ##

## **代码规范&设计模式重要吗？** ##

上文列举了一些，在项目开发中**代码规范**，以及**使用设计模式**上的一些痛点。

之所以称之为**痛点**而不是**缺点**，原因就像上文有些场景，代码都不是重要的一环，代码规范更不值一提，何来缺点一说。

所以重不重要，综合上文来看，除了主观因素，团队因素，甚至还有团队管理者的原因。毕竟的确在一些场景，只是对开发人员友好，对KPI来讲毫无用处，导致了不重视。

## **如何持续做好代码规范** ##

如果我们是有**geek精神**的团队，或者要设计长时间维护的产品，还是建议做好代码规范和设计模式的落地。

那么就不妨从笔者总结的痛点上，结合自己当下场景逐条分析，取得一个“**平衡**”点。

笔者也大致总结了几点，以应对上面的措施，但每个人都有每个人的情况，和**设计模式**本身一样，不能“生抄硬套”。

*  深入理解业务，**做好****业务预判**，这样就为了底层设计打出良好基础。
 *  在保障人力成本的情况下，自驱性的成员在当今也不在少数，要给予信心一起**做好基础建设**。
 *  复杂的业务点频繁迭代某个**早期时刻**，技术负责人需要切入，衡量工时分析业务，以便断定是否需要重构，或者出代码设计方案。
 *  人员频繁流动下，工作要尽量形成文档，不能以“走形式”为主，不仅要良好交接代码，还要良好交接业务。
 *  传统项目，对日项目要充分利用自动化工具，尽量多多代替人工的文档维护。

当然了，本文提到的痛点，在中小公司最不难发现，更不是三言两语就能解决，所以尽力做到平衡就非常好了。

如果不存在这些痛点，人员自驱性强，基础建设良好等。大概率是足够优秀的企业了，如果你是这样企业的员工，还坚持看到这里，那就当了解一下中小企业的小问题。

# **|** **结尾** #

刚入行时，笔者也曾看着历史代码发出笑声，“这么乱的代码，怕是喝了散装假酒”。

时过境迁，随着工作年限的增长，看问题的角度也在不断发生变化，现在不仅不会发出嘲笑了，还总结了乱代码出现的原因。

关于**设计模式**和**代码规范**方面的思考也有了新的理解，也如上文所说，碰巧与同事开会提到了，所以整理成文。

文章的标签设置为阅读下的“代码规范”，因为本文没有技术干货，算是经验分享，希望对你有所帮助。

#       #

![05237895135cc76253a47f17496890c6.png][]

[638de7421150343abf1a1d497e9d089b.png]: /images/20220829/c3a1b9b10549426694abee5a36af33ac.png
[1891d8a5f03586aee9457d4c26277f29.png]: /images/20220829/314e427829fe412abc7dd385b78ad22b.png
[96c119461807da4ed54bc2380e941e4a.png]: /images/20220829/3e8805f196ac482498c64f016781de4d.png
[8f5bfad7cbf1be8510e503525b09e353.png]: /images/20220829/5adf5c1563f842a98f94442b4eb304b2.png
[e29e276eca681b8453bfaa9f1164077f.png]: /images/20220829/0609f3a14b034978b0eef4f29763cc5b.png
[05237895135cc76253a47f17496890c6.png]: /images/20220829/a333a56ea7cb4f8d90eb45ad629e978b.png