改编码格式_编码不规范,同事真的会两行泪?

43ac98e8eced56d40ffdb01a9fcea417.png

b2db986a12fb21ff043e6f2ab802bb2d.png

1b38bbac9908b4d520466aa30f3c1e15.png

b657ccc83e241acf29c0f98456810f85.png

8de605e94ab38f1fd6e074f983482caf.png

11aca9ce668dbcdf5f865d19beffd706.png

案发现场

我们在Dubbo中定义一个接口,这个接口采用上方说的欺骗性的命名方式,这个getFeiChaoInfo()中并没有返回值。

d2e3e335637f6d96f215e394ebd437be.png

0d155a607b3c9e6d9bcecd8cab5ca5c8.png

好了,然后我们将这个服务暴露,然后启动。按照肥朝之前的观念,命名不规范,无非是理解起来恶心了点,但是跑还是能跑的。结果一启动

3880da46412d522ab64b595484ac0e51.png

之前看过肥朝Dubbo源码解析的同学,对这个服务暴露再熟悉不过了,根据异常栈,我们很快定位到了关键位置。

2ab6748004715fe97e50567c3038d3d5.png

就算你连Dubbo都没用过也没关系,其实你从javassist和CannotCompileException这两个关键词就能猜到异常的原因。javassist常用于操作字节码,CannotCompileException根据我小学三年级的英语都知道是无法编译异常。那为什么出现没办法编译通过呢?我们把这段Dubbo拼接出来,准备要用javassist进行编译的代码格式化一下就一目了然了

a76f9de16c1bc1255df6affe84e6a848.png

格式化后就很明显可以看出,getFeiChaoInfo()这个方法没有返回值是编译不过去的。那么这个时候有同学就想说了,Dubbo这段拼接代码进行编译的逻辑有bug啊。鉴于公众号目前有小部分粉丝没用过Dubbo,我们先不讨论Dubbo为什么要这么做,我们反省一下自己,你这种欺骗性的方法名本身就有问题,再者,就算Dubbo把这个代码的容错性做好了又如何,你这种不规范的编码习惯,就算成功,也是偶然成功!,不信?肥朝带你再看一个案发现场。

又一起案发现场

在项目中,我们经常会遇到DTO、BO、DO等转换的问题,很多同学用的是Apache或者Spring的BeanUtils来做copy,我们来一组性能测试

9e3776af2042a473af5b5fd61fe7864d.png

另外肥朝给大家总结了一条结论

凡是和反射相关的操作,基本都是低性能的。凡是和字节码相关的操作,基本都是高性能的。

由此可见,在各种POJO间转化,最高性能的肯定是直接操作get/set,但是这样写,肯定不够优雅。从性能报告明显看出较优方案是使用cglib的BeanCopiers。BeanCopiers怎么使用这个自己搜索一下就知道了,那么我们再来看一起案发现场。为了使用建造者模式,我们有同事这么做

7b51b7a62addf118d987ad9dfb5acb75.png

25d9f66f47bc75fbf683f34da3d070e2.png

好了。然后跑一个简单的demo

f13b3565f440401b64bf7bcfc8cc734c.png

c306e1a5b5cfe791edc2539a9ccbd3b7.png

看到有异常一些同学就慌了,就产生了这个东西虽然性能高,但是感觉好像不稳定的样子错觉。其实并不是这东西不稳定,关键还是在于你会不会用。再说了,世界每天都在变,除了肥朝会稳定给大家输出原创之外,还有什么是稳定的呢?为此,肥朝给大家总结了以下几点使用上的常识

1.当源类和目标类的属性名称、类型都相同,拷贝结果棒棒哒。
2.当源对象和目标对象的属性名称相同、类型不同,那么名称相同而类型不同的属性不会被拷贝。另外注意,原始类型(int,short,char)和 他们的包装类型,在这里都被当成了不同类型。因此不会被拷贝。
3.源类或目标类的setter比getter少,拷贝没问题,此时setter多余,但是不会报错。
4.源类和目标类有相同的属性(两者的getter都存在),但是目标类的setter不存在,此时会抛出NullPointerException

关键是我们目标类FeiChaoBO的setter方法是存在的啊,那为什么还会出现这个异常?很明显,正常的set方法都是void的。然而这个案例中,set方法设置了返回值,存在一定的欺骗性。而且就算要用建造者模式也不是这么用的,再退一万步说,建造者模式一般也是build命名而不是改set方法。

你再注意观察一下这两个案发现场,有没有发现一些共同的特点?javassist和cglib,这两个框架最擅长的就是操作字节码,所以他们对set和get,都和如白纸版清纯的肥朝一样,非常的敏感!所以建议老司机也不要随便乱动。

57d9841c7a2dc8ebbf6effd24a2c18c2.png

另外,据肥朝了解到,这个cglib的这个bug在3.1以后的版本是修复了的,但是3.1版本,目前使用的基数还是很大。

56dc6984f247c26a70b6f7f6163fbe40.png

拓展思考

看过肥朝文章的粉丝都知道,肥朝反复强调要经过深度思考,开发中我们有无数的坑,不可能全部踩完的,关键是要经过一个坑,深度思考,提高编码意识!因此,按照老套路,看看根据这次经验,我们试着再压榨出一些有效信息。

比如阿里开发手册提到了,getter和setter方法中,不要增加逻辑。因为大家意识里面的getter和setter就是正常的获取属性,你如果加上了一定的逻辑,从一定程度上说,也存在欺骗性。

ea9e80cca23b6b4c1be3bffb881ffdec.png

我们再继续压榨,布尔类型的get方法有些工具会生成isXXX,这个其实也是有坑的,当然也不排除你项目正在处于肥朝口中的偶然成功状态。

7a8fd6e3aceb194d73f813d6c1e22986.png

由此可见,取名是一个很大的学问,规范的命名是非常重要的,比如肥朝这么见名知意又时尚的名字,明显是经过深度思考得来的。有时候我真的很羡慕大家,每天都有这么多丰富多彩的故事,不像我,一个简简单单的“肥”字竟然就贯穿了一生!

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java高级交流:787707172,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值