架构师负责订规范，你负责执行！

男娘i 2021-10-18 23:34 277阅读 0赞

心意相通的研发之间，本不需要BB这BB那搞些约束。但宁教我心徒枉然，不教银光惹尘埃。过分的放纵爱自由，那就是一去不复返了。

本文系稍成点系统的碎碎语，如有共鸣，拍掌！

# 为什么要有规范 #

规范是一种束缚，是腾飞前的最后一步加速。大公司免费开源复杂的软件，有一个非常重要的目的就是想要占据特殊解决方案的标准制定，想要一个话语权；一项技术趋向成熟的一个标志也是标准、规范的制定。

对于公司内部来说，规范能够让质量和期望不偏离正常水平，是支持多人协作的基石。同时，某些`约定`有奇特的魔力，能够让配合井然有序。

规范会限定鬼才的发挥，但会提高庸才的产出。规范的目的就是让所有人用正常的思维理解正常的东西。

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzM0MTYzMS1jNWE1MDU4MWQ5MzQ0ZmY2LmpwZw][]

没错，规范就是把你变成一个钉子。无论你是纹钉还是自攻螺钉，都会用一把锤子给敲下去！规范是一种对功能的阉割和重排序。

> 臭名昭著的阿里钉钉，钉钉的意思明白了吧。

你即使再牛逼，也给规范按到地，给的工资也就那熊样！打工很难致富，我想这就是原因。

# 规范制定的数据来源 #

## 环境 ##

不落地的规范，设计的再好，也是废物。

规范的制定需要一定的公司环境支持，你改变的可能是核心人员的习惯，抵触肯定是有的。在某些公司里，你的规范可能会遇到很多阻力，你需要慢慢改变，东京不是一天热起来的。

**1、都在忙需求，没人理规范。** 无论从软件管理的角度来说，还是公司的前途来说，放任需求膨胀、代码腐烂的管理人员都是不合格的。这种情况通常发生在小公司。

\*\*2、风险暴露期，故障复盘会议不断。\*\*公司的第一代或者第二代程序员已经功成身退，留下的坑变成了你现在的工作。要给系统量身定制一套合适的规范，很难，要考虑兼容。

\*\*3、垂直部门太多，各自为政。\*\*每个部门都觉得自己的规范牛X，你成为许多撕逼场景的火药集中地。暗中观察，故障驱动。

\*\*4、外包。\*\*还要个锤子规范，都是甲方给你订的。尾款别要了直接跑路吧。

## 数据来源 ##

只有深入业务开发，才有资格进行规范的制定。自以为是、闭门造车是不可取的。即使你的思路再怎么好，可能到了另外一个公司就会水土不服。

公司内的开发最讨厌的就是“我们XX大厂就是这么干的”。不好意思，我们水浅王八多，到处是大哥，不吃你这一套。

你需要评估一个规范影响的范围。比如你搞个编码规范，对象是最底层逆来顺受的码农，影响就小了点；但如果你做的是后端、前端、测试的统一规范，你就需要承受三方的唾沫。所以温水煮青蛙，不要打着规范的名义出规范，不积硅步无以至千里，咱们来日方长，细水长流。

# 怎么评估规范实施情况 #

其实，规范这个东西，一个自上而下的强制性措施是比较好的。规范的review应该逐渐形成文化，或者流程中的一部分。但要结合以下特征进行规范的修正。

\*\*1、实施难度。\*\*你的规范是否过于繁杂，不好记忆和实施，占据了研发大量的时间。

\*\*2、实施数量。\*\*有多少的项目已经合规，你需要维护一个大体的进度表，评估整个实施周期。

\*\*3、反对意见。\*\*规范会动一部分人的奶酪，或者守旧派的抵制。你需要找出一个折衷点，不能过分混淆视听，也需要照顾反对者的情绪。通常，将他们的项目排在最后实施，是通过百分比推动的一种简单方式。

\*\*4、效果反馈。\*\*一般，规范能够在效率上、协作上、质量上推进你的工作。一些“最佳实践“能够很好的鼓舞整个演进流程。

## 人工review ##

经常组织项目review会议，通过不断的重复达到你的目的。提前找出项目中的典型案例，对不合规的代码指出建设性的改进。注意一定要提前了解项目，半吊子的review只会让别人对规范的正确性产生怀疑。

## 自动化工具检测 ##

将规范抽象成一系列工作流，使用支撑工具进行过滤。通过不断的负反馈进行推进。比如，某些jar包的冲突检测、命名方式，都可以在持续集成系统中进行判断。研发只要错上一两次，这种约定就基本上在脑海中了。

基础运维和基础架构是做这些自动化工具最佳的场所。这也是哪怕某个开源方案再成熟，也要封装上一层的原因：你可以针对约定和规范编程。

## 规范和研发文化的推进 ##

每一种规范，对应着一种公司文化，或者代表公司的不同阶段。

趋向谨慎的公司，会选择复杂的流程规范，制约所有员工的活动，避免越轨操作。此类公司生产事故会比较少，因为战线拉的很长很长，使用普通员工的人海战术即可完成工作。

本性活泼的公司，流程规范会比较轻量，通过高质量的研发对约定的认同来演进产品。是创新的土壤，对新需求响应快速。

规范和研发文化相辅相成，伉俪情深。

# 范例 #

例子：Feign jar包的发布规范。

SpringCloud通过feign方式进行RPC调用，我们采用了发布`api` jar包的方式进行协作。但随着项目的增多，jar包的管理成为了显著的问题。为避免因版本升级、变更引起其他的线上问题，保持线上环境jar包的稳定性，特制定此规范。

## jar包依赖 ##

发布的api jar包应该尽量少的依赖其他资源。也就是`dependencies`部分应该越少越好。依赖必须加入`<scope>provided</scope>`，版本交由使用方说明。

jar包的名称和提供的内容，必须可读：能够根据字面意思猜测其功能。

## jar包升级 ##

jar包一旦发布，必须保证其**向下兼容**的特性，具体体现在：

\*\*一、\*\*不允许修改所提供的字段的类型，比如由int改成String

\*\*二、\*\*不允许删除和变更字段，比如修改字段的大小写

\*\*三、\*\*服务提供方需处理某些参数为空的情况，做到向下兼容

\*\*四、\*\*对于以上限制无法完成的更改，可提供新的接口和参数，对外暴露新的接口。老接口依然保持可用，直到确认无任何调用

\*\*五、\*\*不允许使用多态对接口进行扩展，请提供不同的名称！

\*\*六、\*\*提供清晰的接口参数，不允许万能接口（老项目可逐步迭代）

\*\*七、\*\*接口变更，必须提供wiki文档

## 版本号 ##

项目采用三段版本管理，如 2.8.15

<table> 
 <thead> 
  <tr> 
   <th>版本段</th> 
   <th>意义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>2</td> 
   <td>大版本迭代，一般是非常重要的技术升级或者业务重构</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>重要的bug修改和大版本迭代</td> 
  </tr> 
  <tr> 
   <td>15</td> 
   <td>大版本迭代中的bug修改，依次递增</td> 
  </tr> 
 </tbody> 
</table>

不接受非三段的版本号！jar包不接受覆盖式发布，需升版本号！

## jar包类型 ##

### 以SNAPSHOT结尾的jar包 ###

如 order-api-1.0.1-SNAPSHOT.jar ，`SNAPSHOT`为大写。

研发使用dev账号发布的jar包，以`SNAPSHOT`结尾，不带`SNAPSHOT`的无法发布到私服。

`SNAPSHOT`在非线上环境使用，供研发调试接口、测试功能，请在上线前去掉`SNAPSHOT`，并告知SRE发布正式jar包。

此种jar包所有人都有权限发布，依赖项目只拉取最新的jar包，各项目成员自行解决开发测试中的冲突问题。

> mvn dependency:tree 命令可以查看所有的jar包

### 不带SNAPSHOT的jar包 ###

如 order-api-1.0.1.jar

线上正式环境使用，使用`SNAPSHOT`结尾的jar包上线，会打包失败。

此种jar包仅SRE有权限发布。

## jar包信息维护 ##

由于jar包数量多，功能繁杂，需要维护jar包的变更信息。

目前使用wiki维护jar包的升级信息。

# 结尾 #

规范这东西，不能乱搬。小螺丝扣大螺母，和没套有啥区别？

嘿，说的就是你，先别搬什么阿里java开发规范了，你自己的代码都烂透了，还真以为有通吃的规范啊。

在此我向大家推荐一个架构学习交流圈。[点击加入交流圈][Link 1] 里面资深架构师会分享一些整理好的录制视频录像和BATJ面试题：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多。

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy85NzI3Mjc1LTk2MDBkM2ZjNDA3YmMyMjYucG5n][]

> 注：  
> 作者：小姐姐味道  
> 链接：[http://www.imooc.com/article/290442][http_www.imooc.com_article_290442]

[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzM0MTYzMS1jNWE1MDU4MWQ5MzQ0ZmY2LmpwZw]: /images/20211018/a4c29dc542e54c9b86af1df1e64a8f74.png
[Link 1]: https://links.jianshu.com/go?to=https%3A%2F%2Fjq.qq.com%2F%3F_wv%3D1027%26k%3D55dGrHe
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy85NzI3Mjc1LTk2MDBkM2ZjNDA3YmMyMjYucG5n]: /images/20211018/30002d27008b47dfafeb99a6508030d7.png
[http_www.imooc.com_article_290442]: http://www.imooc.com/article/290442