前提:
最近在进行组件化的项目结构调整讨论,我提出引入RxJava+Retrofit。在深入讨论的时候,同事问了一句:为什么要引入Retrofit,现在的Volley不是用的好好的吗?而且从Volley切换到Retrofit,涉及代码迁移比较大,影响面也非常大。
为什么要引入RxJava:
从我本人的技术栈来看,响应式编程是一种非常好的技术思想,不局限于技术;我希望团队内的同学,不要把RxJava单纯看作某一个第三方依赖,而是看作一种解决问题的新思路。目前来说,RxJava在项目中的使用场景比较少,但是,我相信,随着后续大家对于RxJava的深入,能不断拓展出新的场景;同时,用尝试用它来解决一些我们原先存在的难题。期望:后续对pipeline机制以及函数式编程的理解,会带来一定的帮助。
为什么要引入Retrofit:
站在十字路口徘徊,我也在试着问自己:为什么要引入Retrofit?是因为网络上,大家都在用这个,就因为这个?还是为了尝试它的新特性?面对新技术,我开始迷茫了!我应该以什么样的态度来面对新技术?我认为自己进入了为了技术而技术的怪圈,并没有真正地去思考用什么技术解决什么问题。今天同事的问题,让我幡然醒悟。我会自己写一些app去尝试,体验一下。如果体验下来,的确在使用性上,设计上给人有惊艳的印象,那么我会去深入了解实现的原理(也就是俗称的拆轮子)。再对比原有的技术方案,看看有什么差异,各有什么优劣,有没有替换的价值。
最后自己的观点
我认为技术是为问题服务的,所有的技术都是为解决问题而诞生的,这一点应该毋庸置疑。作为一名软件工程师,你有好奇心,去了解新的技术,这不是坏事。但是,新技术与原有技术对比,对于同一问题的解决,是否有突破?新奇的地方到底是什么?我们不应该停留在API的层面,应该更深入的去了解他们是怎么设计的?怎么解决问题的?对于新技术,自己玩,怎么玩都可以,但是引入的项目中,这个就需要慎重了。因为业务之复杂,涉及改动的代码(也就是影响面)之多,在没有有效手段保证的情况下(测试的回归测试这种手段,个人认为有点low了),不要草率得决定替换。
参考文章:
http://coolshell.cn/articles/...
http://coolshell.cn/articles/...
http://coolshell.cn/articles/...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。