返回列表 发新帖

Java篇:手中无框架,心中有框架

[复制链接]
     

该用户从未签到

25

主题

25

帖子

79

积分

注册会员

Rank: 2

积分
79
发表于 2018-2-24 14:01:15  | 显示全部楼层 | 阅读模式

一提起框架,咱们平时用java开发的程序员一下就想起几个常用框架:Spring MVC、Spring、MyBatis、Hibernate等等,说起每个框架比较典型的特性滔滔不绝,了然于心,像Spring的IOC、DI、AOP,Spring MVC的数据绑定,MyBatis的一对多、多对一关系的处理等等,好像只有把这些内容挂在嘴边才能显得自己确实掌握了这些框架,并且可以成为聊天、面试的谈资,但当我问起IOC实现原理、核心思想、当初是为了解决什么问题才产生了这么个概念,得到的回答是:“这是控制反转,控制反转的意思就是……。”依然是在解释概念。并没有真正的回答问题。
再比如Spring MVC的数据绑定:
@RequestMapping(value="/method", method=RequestMethod.POST)
public String mothod(@RequestParam("a") String a, @RequestParam("b") String b)
类似这样的写法,可能有的小伙伴发现,在开发的时候,其实这样写也行:
@RequestMapping(value="/method", method=RequestMethod.POST)
public String mothod(String a,String b)
这样写,变量a和变量b也能准确的绑定数据,没发现这个现象倒也罢了,发现后竟然也不好奇:这是什么原理?因为很明显,如果Spring只是单纯的用反射,是达不到这个效果的,反射,是没有办法获取到【方法的参数名】的,所以通过反射,是不可能知道哪个参数变量是a,哪个参数变量是b,如果不加注解就没办法准确的把a和b的值分别绑定到这两个参数上,如果知道这个知识的小伙伴,依然对Spring的这个现象不好奇,那我真的要好奇了,我好奇这些小伙伴为什么不好奇。反正我确实在《Java SSM开发大众点评App后台》中表现出了我的好奇。反正我身边确实有不好奇的同事,我和他说完现象和原理后,他:呵呵,这时我TM深刻的体会了一把:聊天止于呵呵。

曾经在一档求职类节目上,竟然发现了同类,很是欣喜,就看看这位兄弟是怎么在现场发挥的,开场会放一段VCR,是他的自我介绍,我觉得挺有意思,大概的意思是:无论什么设计模式、第几范式、什么框架统统不在话下,项目到手,统统用上。当时我就感觉说的像是在糊墙,水泥沙浆尽管往上糊。当然,我没办法和这位兄弟继续讨论这个话题,但我想会有小伙伴和这位的想法是差不多的,用自己掌握了多少种技术来武装自己,在项目上堆砌自己掌握的技术来证明自己掌握了。最后导致项目除了他本人,其他人是很难接手维护的,然后为此而沾沾自喜,并且觉得是不是其他人的技术太薄弱了,所以才没办法接手自己的事情。

但其实我们是忘却了本来的目的,原本要解决的问题,只是单纯的、不停的修炼外功,而忘了静下心来思考,修炼内功。比如思考:要开发的系统需要解决的是什么问题才用的这个框架,这个框架用在这个系统上真的好吗?是不是只是听别人说这个框架好,其实我并不知道它好不好,别人说这个框架好是因为帮助他们解决了什么问题?而他们遇到的问题其实和我现在遇到的问题并不相同,所以他们的观点并不能代表我现在的情况。用了这么多种框架和技术在系统上,就是为了让系统更难维护?

那么如果只是单纯的修炼外功,我就称之为是手上、嘴上都是有框架的,但心中是无框架的。相当于佛家的人生三重境界中的第一重:看山是山,看水是水。在这里就是看技术是技术,看框架是框架。还依然是停留在框架的表面,只是单纯的使用框架,为了技术而技术,在努力的解释一些概念而不得要领。

当然,工作一段时间后,有些小伙伴渐渐意识到,应该通过官方文档、看源码或者其他形式去了解框架更深层次的东西,这时会发现其实框架的底层是充分的利用了java的特性来帮我们解决平时要解决的问题,比如分层、解耦、复用框架封装好的功能来减少开发成本,同时也是一种约定,一种规范,公认的流行框架,如何将框架应用在项目上,不同的人在这个上的理解应该是大致相同,减少学习与沟通的成本,进了一家新公司,如果这家公司用的是流行框架,那很快就能上手工作,如果是公司自己内部私有的框架,那还需要重新学习这个框架的使用方法、开发规范,需要入乡随俗。

渐渐你积累了一些框架源代码中体现出来的思想,明白框架是在解决什么问题,为了解决这些问题,运用了什么样的手段和java特性,框架整体的代码结构是不是在保持着高内聚、低耦合的风格,是不是尽量做到开闭原则,在应用设计模式的时候是不是也是出于这些目的,而不是像我们中的一些小伙伴无端的为了用设计模式而用设计模式,也就是说,框架不光提供了我们所需功能,同时它自己还得保持良好的代码结构与风格,因为它也是由人开发的,一样会有BUG,一样需要维护并升级版本,如果不讲究,那样庞大的代码量,基本上维护不了两次就得扔了。这里的“两次”只是个虚指,真的能维护2次我真的OZR了,维护如此体量的烂代码2次比开发1次良好代码的框架更让我佩服,这也正是我们看框架源码的价值所在。说到这个,目前为止还没有和大家一起真正的讨论过框架源码,之前都还是忙着分享框架在实战中的应用,最多是为了解决框架应用时出现的问题、或是为了去了解框架在应用java什么特性才去追踪的源码,这还不算是真正的“看”源码,因为分享实战其实对新手入门确实很有帮助,不可能指望新手可以对着框架源码指点江山,如果你是天才,别理我说的这句话。后面希望有机会和这些成长起来的、当初的新手、如今已入门的小伙伴们一起讨论“源码赏析”这样的事。

渐渐你积累了一些框架源代码中体现出来的思想,明白框架是在解决什么问题,为了解决这些问题,运用了什么样的手段和java特性,框架整体的代码结构是不是在保持着高内聚、低耦合的风格,是不是尽量做到开闭原则,在应用设计模式的时候是不是也是出于这些目的,而不是像我们中的一些小伙伴无端的为了用设计模式而用设计模式,也就是说,框架不光提供了我们所需功能,同时它自己还得保持良好的代码结构与风格,因为它也是由人开发的,一样会有BUG,一样需要维护并升级版本,如果不讲究,那样庞大的代码量,基本上维护不了两次就得扔了。这里的“两次”只是个虚指,真的能维护2次我真的OZR了,维护如此体量的烂代码2次比开发1次良好代码的框架更让我佩服,这也正是我们看框架源码的价值所在。说到这个,目前为止还没有和大家一起真正的讨论过框架源码,之前都还是忙着分享框架在实战中的应用,最多是为了解决框架应用时出现的问题、或是为了去了解框架在应用java什么特性才去追踪的源码,这还不算是真正的“看”源码,因为分享实战其实对新手入门确实很有帮助,不可能指望新手可以对着框架源码指点江山,如果你是天才,别理我说的这句话。后面希望有机会和这些成长起来的、当初的新手、如今已入门的小伙伴们一起讨论“源码赏析”这样的事。
再比如,MyBatis的一对多和多对一关系的配置,如果单纯从用的角度去看配置,那不过是在记忆一种配置规则,MyBatis要求我们这样配我们只能这样配,不然MyBatis不工作,记住这些不过是证明你用过,去公司可以立刻用这个框架上手干体力活了而已,而我们现在可以考虑的是:如果我们自己来实现MyBatis这个功能,为了将一个二维表的结果集映射成java对象来体现一对多、多对一的关系,我们可能也得要求使用者配这个参数,配那个参数,不然确实没办法映射,这个时候你再去看MyBatis所要求的配置,很顺眼、很合理,你一眼就看穿,配置这些内容将会起到什么作用,框架拿到这些配置大致会用来干嘛,然后为了证实自己的想法,还可以到源码里一探究竟。
这个时候,不再是那夸夸其谈表面概念的毛头小子,现在是手中有框架,心中也有框架,这时达到的是第二重境界:看山不是山,看水不是水。看技术不是技术,看框架不是框架,也就是说,这时你感觉到,你看框架和以前不太一样了,你看到的是框架背后的东西。
最难理解的是第三重境界:看山还是山,看水还是水。因为这一重人生境界不光难以企及,甚至难以理解。但我还是想在这一重境界再去看看框架,谈谈本人陋见。

这一重境界的人,再去看框架,不过就是框架,是用来解决问题的手段和工具,框架应为我所用,而我不应被其所累,深陷其中,工具顺手就用,也就是框架所能解决的问题,与面临的问题契合度很高,那就采用这个框架,如果工具不顺手,那就从工具箱里换一个顺手的,如果工具箱里没有合适的,完全有能力自己造一个,比如zTree,据zTree的作者自己介绍,他就是在工作中需要一个树插件,但没有特别吻合他需求的,这是个前端牛人,在这种情况下,一言不合就基于jQuery自己开发了zTree,随着不断的维护和完善,现在的功能已经非常强大,在本人分享定制大众点评的后台内容时,用zTree实现了相对较复杂的权限维护功能,就体现了zTree的强大。
我:
而在InfoQ独家发售的《聊聊架构》这本书的最后一章里,作者谈了对事务的看法,和咱们这里说的第三重境界是一个道理,我这里大体描述一下书中所表达的意思:人们对数据库事务过度的依赖,导致架构拆分的困难,文中以银行转账为例,A向B转账100元这一过程,A账户-100元,B账户+100元,我们平时利用数据库事务的做法,其实是把这种业务的完整性保证转嫁给了数据库,导致当A账户和B账户不在同一个数据库里时,感觉处理起来很困难,而数据库原本应该保证的只是单条数据的保存,过度的依赖数据库事务来保证业务上的事务,就会出现这种情况,看透这个本质后,不过就是保证“一手交钱,一手交货”而已,只不过这个时候不是由数据库来保证,而是由数据库服务的调用者自己来保证,这里指的就是软件自身。然后如何保证,那是更细节的问题,在这里就不讨论了,有兴趣的可以自己去看书里的阐述。这里只是拿这件事举个栗子,超越数据库事务的限制,和咱们这里超越框架的限制,这样的思维方式是不是一个道理?
那么第三重境界,在咱们这个话题里,我把它称为【手中无框架,心中有框架】,并不是说真的手上什么都没有,白手起家,而是说无论是用框架也罢,不用框架也罢,用流行框架也罢,用老的框架也罢,心里是有个无形的框架做为评判标准,以更好的解决问题为目的,如何选择不必纠结。框架------还是那个框架,而心------已更豁达。

回复

使用道具 举报

发表回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
关于我们
友情链接
联系我们
帮助中心
网友中心
购买须知
支付方式
服务支持
资源下载
售后服务
定制流程
关注我们
官方微博
官方空间
官方微信
快速回复 返回顶部 返回列表