为了账号安全,请及时绑定邮箱和手机立即绑定
手记 \ 手中无框架,心中有框架

手中无框架,心中有框架 原创

2017-05-24 14:45:13 9474浏览 17评论

源生活

JAVA开发工程师 Java web工程师,js组件、流行Java框架、工作流、图形报表与数字报表等等领域都有本人的足迹,最擅长的还是用Java代码解决问题。针对客户的频繁需求变更有一套解决方案与敏捷式开发平台。

一提起框架,咱们平时用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的这些特性,来探索框架背后的故事,比如MyBatis的接口式编程,是利用java的动态代理,这个我在《通过自动回复机器人学Mybatis---加强版》里仔细的和大家一起玩了一把。

再比如,MyBatis的一对多和多对一关系的配置,如果单纯从用的角度去看配置,那不过是在记忆一种配置规则,MyBatis要求我们这样配我们只能这样配,不然MyBatis不工作,记住这些不过是证明你用过,去公司可以立刻用这个框架上手干体力活了而已,而我们现在可以考虑的是:如果我们自己来实现MyBatis这个功能,为了将一个二维表的结果集映射成java对象来体现一对多、多对一的关系,我们可能也得要求使用者配这个参数,配那个参数,不然确实没办法映射,这个时候你再去看MyBatis所要求的配置,很顺眼、很合理,你一眼就看穿,配置这些内容将会起到什么作用,框架拿到这些配置大致会用来干嘛,然后为了证实自己的想法,还可以到源码里一探究竟。

这个时候,不再是那夸夸其谈表面概念的毛头小子,现在是手中有框架,心中也有框架,这时达到的是第二重境界:看山不是山,看水不是水。看技术不是技术,看框架不是框架,也就是说,这时你感觉到,你看框架和以前不太一样了,你看到的是框架背后的东西。

最难理解的是第三重境界:看山还是山,看水还是水。因为这一重人生境界不光难以企及,甚至难以理解。但我还是想在这一重境界再去看看框架,谈谈本人陋见。

这一重境界的人,再去看框架,不过就是框架,是用来解决问题的手段和工具,框架应为我所用,而我不应被其所累,深陷其中,工具顺手就用,也就是框架所能解决的问题,与面临的问题契合度很高,那就采用这个框架,如果工具不顺手,那就从工具箱里换一个顺手的,如果工具箱里没有合适的,完全有能力自己造一个,比如zTree,据zTree的作者自己介绍,他就是在工作中需要一个树插件,但没有特别吻合他需求的,这是个前端牛人,在这种情况下,一言不合就基于jQuery自己开发了zTree,随着不断的维护和完善,现在的功能已经非常强大,在本人分享定制大众点评的后台内容时,用zTree实现了相对较复杂的权限维护功能,就体现了zTree的强大。

而在InfoQ独家发售的《聊聊架构》这本书的最后一章里,作者谈了对事务的看法,和咱们这里说的第三重境界是一个道理,我这里大体描述一下书中所表达的意思:人们对数据库事务过度的依赖,导致架构拆分的困难,文中以银行转账为例,A向B转账100元这一过程,A账户-100元,B账户+100元,我们平时利用数据库事务的做法,其实是把这种业务的完整性保证转嫁给了数据库,导致当A账户和B账户不在同一个数据库里时,感觉处理起来很困难,而数据库原本应该保证的只是单条数据的保存,过度的依赖数据库事务来保证业务上的事务,就会出现这种情况,看透这个本质后,不过就是保证“一手交钱,一手交货”而已,只不过这个时候不是由数据库来保证,而是由数据库服务的调用者自己来保证,这里指的就是软件自身。然后如何保证,那是更细节的问题,在这里就不讨论了,有兴趣的可以自己去看书里的阐述。这里只是拿这件事举个栗子,超越数据库事务的限制,和咱们这里超越框架的限制,这样的思维方式是不是一个道理?

通过上述的例子来看看达到这一境界的人们,是何等的淡定从容,这不光是技术能力的问题,这需要居高临下的看待问题,明白技术和框架到底是为什么而服务。而如果把掌握的技术和框架当成炫耀的资本,不停的在项目上采用新的框架,却没有达成任何目的,没有丝毫解决问题的价值,那就算是有这个技术能力,也不大可能编写出造福程序员的工具,而更有可能制造出伤人的武器,因为这其实无论在人生的境界还是软件的境界,都是停留在第二重境界的表现,而且表现的还有点极端:看什么都不对劲,就自己最牛。在这种情况下让我去理解“看山不是山,看水不是水”,真的一下就联想到“鼻子不是鼻子脸不是脸”,身边的人都没自己懂框架,好像只有自己是唯一的一眼看穿框架的人。我这里为什么要强调一下人生的境界,因为软件的世界是来源于生活,是人生的一种折射,人们打牌时经常会说:牌品如人品,其实在软件上的表现,又何尝不是呢?这里给自己的名字打个广告:刚刚这些观点正是我叫【源生活】的原因,而且不光是来源于生活,同时也离不开生活,在这里顺便感谢一下家人在生活上的照顾和对我工作的支持,而我又利用在工作中的思考,提高工作效率而节省下时间,用来多去陪陪家人,相辅相成,好~~~~收!还是回到框架这件事上来。

这里没有贬低框架和技术的意思,只是可能没必要把框架供奉的高高在上,离开框架就寸步难行,因为再优秀的框架也不是包治百病可以解决所有问题,每个人面临的问题都各不相同,框架不过是解决了共性的问题,可能还有个性的问题需要解决,某个框架不过是其中一个备选方案,框架,就真的只是个框架。用人生的三重境界来比喻对框架的态度只是一时兴起、一家之言,每个人心里都有自己的一套解读方式,欢迎大家来交流有趣的想法。

那么第三重境界,在咱们这个话题里,我把它称为【手中无框架,心中有框架】,并不是说真的手上什么都没有,白手起家,而是说无论是用框架也罢,不用框架也罢,用流行框架也罢,用老的框架也罢,心里是有个无形的框架做为评判标准,以更好的解决问题为目的,如何选择不必纠结。框架------还是那个框架,而心------已更豁达。

相关标签: JAVA

本文原创发布于慕课网 ,转载请注明出处,谢谢合作!

183 推荐
    意见反馈 常见问题 APP下载
    官方微信