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