架构师负责订规范，你负责执行！
心意相通的研发之间，本不需要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开发规范了，你自己的代码都烂透了，还真以为有通吃的规范啊。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
