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

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

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

为何要有规范

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

对于公司内部来讲，规范可以让质量和指望不偏离正常水平，是支持多人协做的基石。同时，某些约定有奇特的魔力，可以让配合井井有理。

规范会限定鬼才的发挥，但会提升庸才的产出。规范的目的就是让全部人用正常的思惟理解正常的东西。

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

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

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

规范制定的数据来源

环境

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

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

一、都在忙需求，没人理规范。 不管从软件管理的角度来讲，仍是公司的前途来讲，听任需求膨胀、代码腐烂的管理人员都是不合格的。这种状况一般发生在小公司。

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

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

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

数据来源

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

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

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

规范的切入点

怎么评估规范实施状况

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

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

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

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

**四、效果反馈。**通常，规范可以在效率上、协做上、质量上推动你的工做。一些“最佳实践“可以很好的鼓舞整个演进流程。

人工review

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

自动化工具检测

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

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

规范和研发文化的推动

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

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

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

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

范例

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

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

jar包依赖

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

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

jar包升级

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

**1、**不容许修改所提供的字段的类型，好比由int改为String

**2、**不容许删除和变动字段，好比修改字段的大小写

**3、**服务提供方需处理某些参数为空的状况，作到向下兼容

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

**5、**不容许使用多态对接口进行扩展，请提供不一样的名称！

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

**7、**接口变动，必须提供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开发规范了，你本身的代码都烂透了，还真觉得有通吃的规范啊。