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

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

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

为什么要有规范

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

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

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

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

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

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

规范制定的数据来源

环境

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

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

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

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

不接受非三段的版本号！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开发规范了，你自己的代码都烂透了，还真以为有通吃的规范啊。