架构师负责订规范,你负责执行!

心意相通的研发之间,本不需要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开发规范了,你自己的代码都烂透了,还真以为有通吃的规范啊。

架构师负责订规范,你负责执行!

原文 

https://juejin.im/post/5c356a39f265da613e226d33

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 架构师负责订规范,你负责执行!

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址